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