Jesse Keating wrote:
The rel-eng team in conjunction with FESCo has developed a proposal for changing the development cycle of Fedora. The goals are to disrupt development less frequently, make it easier for maintainers to get fixes in, and make it easier for future work to happen without risking disruption of a release in progress. Please read through http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal and follow up on this thread with any questions comments. I'd like to potentially hold a "town meeting" type of IRC meeting to discuss this proposal with interested parties and address questions/concerns. However I will delay scheduling such a meeting until discussion has happened here.
As someone who has been pretty vocal in complaining about some of the previous process changes I would like to say I think it is good that this is being worked on. But ... I'm not a big fan of the idea of builds for the release which is under development going to updates-candidates. I think the current model where one can requestan early branch todo disrupting stuff, while normal builds go straight into rawhide / the release is a very good model, as there are no hoops to jump through (as in request tagging into rawhide / relase + writing motivation for this).
Doing early mass branching might even make this better as then people will need to think actively in which branch (destined for release, or devel) their work can best be done, where as now they might think, hmm this might be a bit dangerous, but I don't feel like asking for an early branch (aka a hoop to jump through), so lets just put it in.
Any time you raise artificial barriers like explicit requesting tagging for inclusion, fixes will not make the release which could have otherwise made it just fine. People may forgot to send the tag request, tag requests currently have no tracker and sometimes fall through the cracks, and if its a (safe) small fix a developer may think its not worth the trouble at all.
As for the tagging request avoiding people braking things late in the game: 1) we don't need barriers, we need to educate people 2) if someone really wants to get an update in he will most likely succeed as he knows his package best and can probably convince rel-eng of the necessity of the update. So all in all: -calling it alpha / beta / release candidate instead of test# +1 -no freeze for alpha +1 -early branching (I would say a week for the RC) +1 -making builds in the release branch goto updates-testing after branching -1 (esp combined with early branching) Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
