On 12/10/05, Greg DeKoenigsberg <gdk@xxxxxxxxxx> wrote: > I'm not sure how true this actually is. It's only sorta rolling; we did > end up rebuilding the Extras world right before FC4 came out, and I > suspect we'll do the same for FC5. No Extras is very much "rolling" and this is going to lead to problems if we get to the point where this project supports or encourages Extras media for networkless install time use. If Fedora is in the future going to support media based install/updates that include Extras in the mix... then either Extras is going to have to have point releases that work with the Core isos. Do you know how difficult its going to be for Vendors to roll "install media" for Extras even if Fedora provides the scripts.. if the package set in the Extras tree is built against Core updates? These sort of media will not work with the official Core isos that are spun up for Core release. Or is the Core release team prepared to start releasing timestamped Core media that includes the Core update packages AND the associated level of bugreport activity that goes along with doing installable media respins? This request has come up in the past and has been shotdown. I don't see a change in that wind coming with regard to the issue of offering official respins. The easiest solution to the "install media" problem is to have a point release tree for Extras that works with the official isos for Core instead of the current rolling model. > It's as practical as we make it. It doesn't need to be a grand > production; in Extras-land, it could be as simple as "putting an > *advisory* text tag into a changelog means an 'advisory' email gets sent > to the right list." The problems are deeper than that. If you want Extras to be "release managed" then there needs to be much mroe structure to Extras. Extras as a collection is going to have to grow some simblance of 'freeze' points around which 'release managers' can start looking over the Extras tree and freeze out releases that work. As long as Extras is a contiual rolling mudball you will give anyone the time to actually do high level release engineering for "favorites." The Extras process must make the time. Point releases that track Core's point release and a development framework in which "freexes" happen to aid the "release managers" > My take: we figure out favorite collections and build ISOs for each of > them. Making sure they all "work" in conjunction with Core could be > tricky -- but we could perhaps ask prominent community folks to "release > manage" their favorite collections. Anyone who signs up to "release manage" collections inside Extras rolling framework is certifiably insane. Be prepared to see HIGH turnover here, these brave people will be fighting against the structure of Extras continually to produce something timely and worthwhile. Unless Extras moves to point release with some "freeze" points for the tree, making a call for these sort of volunteerism is unreasonable and unwise. Take a moment and ask the experts inside the fenceline how difficult it would be if there were timeframes and 'freezes' for the release trees that exist now. -jef
