ubuntu-phone team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

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