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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
