Request for Comments: Proposed changes to Fedora development cycle

Hans de Goede j.w.r.degoede at hhs.nl
Tue Oct 16 15:05:51 UTC 2007


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




More information about the fedora-devel-list mailing list