ubuntu-phone team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

On 04/08/2014 05:15 PM, Dimitri John Ledkov wrote:
> Imho that will still get us into a state where trunk has gazillion of
> changes and is not releasable.

"gazillion of changes" -> "not releasable"
is a non sequitur: yes, there might be more changes being planned for
landing at the same time, but that doesn't imply that trunk wouldn't be
releasable.  If trunk is buggy, it will have to be fixed.
Note that this is not different from what we do now anyway: when we get
a silo, we prepare a branch with all the changes which we want to land
into it. If we find some issues when testing the silo, we stack more
changes (fixes) into that branch.

> And one would have to pick the trunk apart into a landing.

Only when landing to the LTS or another non-development distro (which
happens rarely, and is fully manageable as we did in the past), because
we are already used to keep the trunk in a releasable state anyway: we
would not merge into it something which we don't want to get released.

> A better approach is to still keep trunk match the archive, however
> have multiple staging branches e.g:
> lp:project (trunk - matches the archive)
> ~team/project/next-landing
> ~team/project/landing+1 (includes next-landing)
> ~team/project/landing+2 (includes landing+1)
> ...

I really want to have a *single* development branch. And I want to make
it so, that when someone submits a MP which I approve, that this will be
merged into the development branch so that it will get eventually
released. By keeping things in separate branches I forget about them,
and in some projects 2 days is sufficient to have a branch bitrot and
require more work to be updated.

Ciao,
  Alberto