Request for Comments: Proposed changes to Fedora development cycle

[Thorsten Leemhuis]

On 16.10.2007 16:24, Jesse Keating wrote:
> Please read through 
> http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal
> and follow up on this thread with any questions comments. [...]

In general: looks nice, some steps in the right direction IMHO. But not
enough IMHO. Quoted some parts of the proposal below, some other ideas
and the end of the mail:

> = Proposed Development Process Changes for Fedora 9 =
> [...]
> == Proposed Solution ==
> Move to an Alpha/Beta/RC/Final release method.

Hmmm, even after reading the proposal three times now it got a bit of an
"use different names for what we had already with some small
modifications" feeling

>  Limit collection wide
> blocking freezes to one for a Beta release and a continual one for the
> RC/Final release.

+1

>  Allow early branching of CVS and mass branch earlier.

+1

> === Alpha ===
> The Alpha release would mostly be used as a starting platform for
> somebody wanting to develop a feature for the given release.  It would
> have many of the post-release updates done to the previous release plus
> some start of new features for the current release.  Mostly what the
> project cares about this release is that it is installable and can get
> updates after the fact.

I think having a "it is installable" as defined goal way more often
would be good. Every Friday maybe?

Further: both Opensuse and Ubuntu have way more betas/rcs. I don't think
we should follow that model completely, but maybe we can steal ideas
from it? A installable rawhide snapshot every two weeks maybe (as ISO or
as second dir (files hardlinked to rawhide) on the servers?)

Just thinking aloud.

> [...]
> === Release Candidate and Final release ===
> In order to prepare the release candidate(s) and the final release a
> final freeze is needed.  It is at this point that we would block rawhide
> once again.  It is extremely important that we have as many eyes on the
> bits as possible to make our release as best as we can.  This freeze
> point is also the point in which we would create any remaining needed
> branches in CVS for the release.  Any builds from the branch would be
> held in an updates candidate tag to be potential updates for after the
> release, or to be pulled in to the release by request.  Builds from
> devel/ would be tagged for the next release tag to show up in rawhide
> once the next development cycle starts. 

Sounds to complicated and much of a "to much of a slowdown/next to full
stop" to me. New stuff can't be tested, as rawhide stands still (I
assume it's not pushed to the servers?). Normal, non-critical updates
for the release (once it happens) stay updates candidates and thus don't
get much tested either.

Some packagers will thus likely just push their updates into the current
release without testing them in rawhide first. That's bad in general
already; but it's even more bad here, as it also create EVR-update
troubles once the release is done.

> In order to accommodate a
> release candidate set plus the final release creation the freeze point
> for this should happen between the current Test3 dates and the final
> deep freeze dates.

This proposal would IMHO be a bit easier to understand if you could
write a potential F9 schedule with release, freeze and branching dates.

> === CVS Branching ===
> At some point in the tail end of development, either right after Beta
> release or sometime between Beta and RC release, we allow for early
> branching of software.  This allows developers to check in new features
> and otherwise unstable changes that would not be suitable to introduce
> to the current release.  At Release Candidate / Final freeze time all
> unbranched packages will be branched.

I'd say we should split up rawhide and way to final release a bit
earlier. See below.

> == Discussion ==
> Questions or comments regarding this proposed change should be directed
> to the [https://www.redhat.com/mailman/listinfo/fedora-devel-list
> fedora-devel-list] mailing list.  The ReleaseEngineering team is driving
> this proposal.

Thx again for this.

What I further like to see: get test-releases (and maybe also the
releases itself) out more quickly; currently we release only on Tuesday,
Wednesday and Thursday; the target being a Thursday. That afaics lead to
a delay of multiple days sometimes -- e.g. release was targeted for
Thursday but was delayed by one day due to problem; that meant a five
day delay till next Tuesday to get that release out to the testers --
way to long IMHO...

IOW: if a test-release is ready wait max. 24 hours and then get that
thing out. Maybe even release new test-versions as bittorrent only the
first 24 hours and then open the normal mirrors?

Yes, sure, I know out mirrors are important, but not that important to
delay the release that 5 days when the test window is four weeks (the
usual cycle we had between test releases up to now).


Further: I know multiple people that don't run rawhide because we always
tell everyone "once rawhide always rawhide" and "rawhide easts babies".
That' IMHO are our biggest problems. Thus i suggest:

- work hard to make rawhide not eat babies and kill kittens in the 5
weeks approaching a release. Tell the developers so they are more
careful during that timeframe (e.g. as careful as they would be for a
update for a released version) and send ninjas if they are not.

- we need a way for testers that want to test the release that they want
to continue to run afterwards without reinstalling it. Two ideas follow,
I think we should do both:

(1.) support and document the "rawhide -> stable" way -- e.g. at the
point where rawhide on the servers becomes targeting the next Fedora
version give users the choice "Do you want to continue using rawhide or
stick to the release that is happening now?".

(2.) create a "Fedora <N> Early Adapters Release (EAR)"  which uses the
final directory structure and a Release for "early adapters". E.g. what
I mean is something like this:

T-30 days before official release
 * publish a test3 (or call it RC if you like)
 * hard free for rawhide -- just like the two/three lasts week before
the release now

T-18 days before official release
 * branch rawhide and release;
 * create the final directory structure on the servers with what's in
rawhide
 * create and publish "Fedora <N> Early Adapters Release (EAR)" from
that tree; its yum  configs point to that tree and not to rawhide
 * open rawhide for release +1 -- rawhide users had enough time to
report bugs; they won't find any new bugs anymore, thus we need a
different kind of testers now which we get with that Fedora <N> EAR

T-18 until T-7 days
* fix important stuff only like we in the past often did in the first
ten days after a Fedora release; ship that as updates

T-7 days
* respin the tree  on the servers, including all updates that happened
over the past 10 days

T-4 days
* prepare the final release

T-0
* release

= EOF =

Just my 2 cent.

Cu
knurd