ubuntu-phone team mailing list archive

[Gustavo Boiko <gustavo.boiko@xxxxxxxxxxxxx>]

Hi


On Thu, Mar 20, 2014 at 2:51 PM, Sebastien Bacher <seb128@xxxxxxxxxx> wrote:

> Le 20/03/2014 18:38, Bill Filler a écrit :
>
>  we block changes from getting into our proposed images quite frequently
>> which seems wrong because we are so concerned about promoting it to released
>>
>
> Hey Bill,
>
> I agree with part of what you are saying. On one hand it feels like we are
> sometime too careful about landing new features/changesets on the proposed
> image. On the other hand, when we land a feature we need to make sure the
> focus is on getting that feature fully ready/polished, so we can promote an
> image that includes it. That often means blocking other work/changes from
> landing, to avoid risking 'drifting away and never being able to get back'.
>
> What you suggest with your "land feature, promote on regular cadence"
> seems to be close from what is current happening? We just had quite some
> big changesets recently (android 4.4, qt 5.2, ...). Like we landed qt 5.2
> and we are current in the "small cycle" focussed on getting that feature
> promoted. While we focus on that one we limit disruption/other features.
> Once qt 5.2 is promoted I guess we should be able to land another feature,
> drive it to promotion, and iterate again.
>

The only problem is that this doesn't scale. While one big feature lands
(say, Qt 5.2), there are at least five or more others being developed and
maybe even proposed. So we pick one of those to land, and then while we are
in the "small cycle" for that one, there are already four other in the
wait, and more being developed. It takes way too much time to get
everything in, which means features get released much later than they
could, which in turn means they will have less testing time in the end.

Cheers

Boiko