← Back to team overview

ubuntu-phone team mailing list archive

Re: Landing process, restoring "trunk" for development

 

I agree with Alberto

Working is several different branches causes a lot of work. During
these last days at some point I had more then 15 branches pending to
merge (due the releasing block). It consume a lot of work to keep
these branches working without conflict. And the problems was that
they are already approved but due the release problems I could not
merge they, and since I did not stop to work, I create more and  more
branches.

I would love to have the trunk back to way it was in the past, with
all approved MR merged and always use that as my base code to start a
new feature or bug fix.

This would cause confusion for the community it they want to
contribute to the project, since the trunk is not up-to-date they will
need to find which branch to use to start developing, otherwise they
will get a lot of conflicts as soon as the blocked branches start to
get merged.

My suggestion is have ppa with packages from trunk, and if we ant to
release some specific we can cherry pick the commits.

BR,
Renato


On Tue, Apr 8, 2014 at 11:49 AM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> 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
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp


Follow ups

References