Re: Core BrainStorm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux