Hi Steve & Scott, If it does slow down the development, it's fine to stop freezing Ubuntu Desktop in our Alpha releases. However, we hope there are several frozen days for our Beta releases.
-- Regards, Jack Yu UbuntuKylin Team At 2013-09-06 12:37:15,"Scott Kitterman" <[email protected]> wrote: >On Thursday, September 05, 2013 20:31:19 Steve Langasek wrote: >> Hi Scott, >> >> On Thu, Sep 05, 2013 at 06:25:28PM -0400, Scott Kitterman wrote: >> > > Finally, there's one other point that I think we should discuss >> > > regarding >> > > the opt-in freezes. The current model for opt-in milestones is that we >> > > freeze all those packages which are used by any of the opting flavors. >> > > I >> > > don't think this is in the spirit of the original compromise that was >> > > proposed, however - particularly since two of the flavors that have been >> > > doing opt-in milestones, UbuntuKylin and Edubuntu, are deriving directly >> > > from the ubuntu desktop seed, with the result that for beta-1, all of >> > > Ubuntu Desktop was frozen. I don't think this is a reasonable outcome; >> > > the Ubuntu Desktop team are explicitly *not* participating in these >> > > milestones in order to maintain development velocity, and it's not fair >> > > to them to have flavors that are "downstream" of them imposing a freeze >> > > on their work. >> > > >> > > I think it's fine for Edubuntu and UbuntuKylin to participate in the >> > > opt-in >> > > milestones, but we shouldn't freeze the Ubuntu Desktop packages for >> > > this. >> > > They can choose to freeze the packages that are part of their overlay, >> > > but >> > > where the Ubuntu Desktop packages are concerned, there should be a level >> > > of >> > > trust in the CI methodologies that we have put in place for the Ubuntu >> > > Desktop itself, instead of freezes whose effect is to reduce alignment >> > > between Ubuntu and the other flavors. >> > >> > I guess a lot of that revolves around the question of how people feel >> > about >> > releasing install media with obsolete packages on them. We've gotten more >> > relaxed about that in recent cycles without any problems I'm aware of. >> > >> > OTOH, part of the reason for uploading to proposed was to allow teams to >> > continue to work through these things. I don't understand how two days of >> > not migrating has any significant affect on development velocity. AIUI, >> > the benefit for non-participating flavors is that developers don't need to >> > stop their normal work and test/fix issues associated with the milestone. >> > The larger effect on velocity comes from what people spend their time on >> > and not on if a package migrates from -proposed or not. >> >> Having packages frozen in -proposed still negatively impacts velocity, >> because nothing in -proposed is being used by the developers and other >> users; a full development iteration means the changes need to reach the >> release pocket, where they can be used by developers and other users, >> incorporated into images, and subjected to additional image-based >> integration testing. >> >> It certainly helps to be able to upload to -proposed instead of not being >> able to upload at all, but the milestone freeze does still slow down >> development. And in this context, I think it's an unnecessary slowdown. > >Perhaps. For those packages that are part of the CI environment, it might >make sense to whitelist them from the block process. I think this won't be a >problem again until the Alpha series for "T", so there is some time to >determine which packages or the criteria for selction to be exempt. > >At the very least, I think there should be some agreement among the affected >products about the relevant package list. > >This is probably a good topic to flesh out at the next UDS. > >Scott K > >-- >Ubuntu-release mailing list >[email protected] >Modify settings or unsubscribe at: >https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
