← Back to team overview

ubuntu-phone team mailing list archive

Re: ANN: Changes to our Upstream Landing and Merge Review Practices in January

 

Le 08/01/2014 20:38, Robert Park a écrit :
On Wed, Jan 8, 2014 at 11:28 AM, Barry Warsaw <barry@xxxxxxxxxx> wrote:
     "Note that some people are merging the packaging branch into the upstream
     trunk. Both have pros and cons. I'm not attached to any particular form as
     debian/changelog is already the history of a package. But before merging,
     you should revert all generated files (modified or new)."

Will the new process require stronger language here?

Uh, yes, there are two possible ways of doing the merge, but there is
no ambiguity about the fact that debian/ directory must live within
trunk.


The idea is really about consistency and ease of use.

Historically, we had different approach in our internal development and everyone had its own set. This created some issues like, if you jump for a small patch in another project, questions like "where is trunk", "where is the packaging, I need to make a change here", "oh, this packaging is totally different from what I know" have happened.

So, the idea that we enforced from this process are quite simple:
- source package name == project name. So, if you have "foo" source package in Ubuntu where we are upstream for, you know that you can confidently bzr branch lp:foo and that's what is in the latest development version of ubuntu. (I wish we can enforce maintenance branch around lp:foo/<distro_version>, but I guess I'll save the debate for later ;)) - inline packaging: You know and are sure that the packaging is . We also sanitize and try to standardize the packaging to have the effect of no surprise. You know the package is going to use dh9, debian/rules will be structured that way, we are use --fail-missing to avoid new files not being shipped without noticing…

This really helped upstream in multiple ways: consistency is key. For people not being really in packaging, they have been able to make the general changes themselves. Finally, the packaging changes are synced with the code change (/me remembers old days with "oh, you need to push now the packaging change to the packaging branch as I'm going to merge that branch which renames some files…" which was a nightmare).

Does this make sense on the general goal? You can keep one word to sum that up: consistency (to avoid surprises and so moving faster without hunting) ;)
Cheers,
Didier


Follow ups

References