Core BrainStorm

[Bill Nottingham]

Greg DeKoenigsberg (gdk at redhat.com) said: 
> > - seamlessly allow Extras to be everywhere that Core is from an
> >   installation path - anaconda, yum, pup, system-config-packages, etc.
> >
> >   This is done for yum and pup, but not yet for the others.
> 
> But we're working on it, right?  I mean, this *is* the future, right?

Yes. However, in the case of system-config-packages, this gets messy -
if you're spinning various CD groups of Extras, how does it know
about these CDs to know what you need? Do you duplicate any CD-related
metadata in internet-connect repository data? Do you have it scan
CDs for options of what to install? Something else?

> > - Extras and Core have differing release models, generally. Core
> >   has a Release, plus Updates. Extras has a more rolling release
> >   model.
> 
> 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.

Well, packages are much more likely to be added in Extras then
in Core post release - someone will import something new for all
the FC releases currently in play. Packages very very rarely
get added to Core in updates.

There's also Seth's favorite - multilib. :)

> > - With the more rolling release model of Extras, how does that fit
> >   in with building CD images, or grouping of packages? Do we
> >   offer services that build Extras CDs on-the-fly? Do we have
> >   generated Extras isos at Core release time, and never afterwards?
> >   Do we allow third-parties to make their own Extras isos with
> >   scripts (or infrastructure) that we provide? (Cue the Trademark
> >   policy!)
> 
> 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.  In the long term, we allow anyone to
> create their own collections as well, perhaps using the tools and rules
> that we end up developing to maintain the favorite collections.

The problem I see is we need the trademark ducks in a row before
we can do much of this, as it was a barrier to Extras CDs in the past.
Perhaps I'm missing something important that changed this.

> > - Support for languages not deemed as being fully supported (whether
> >   by average translation percentage, or some other metric) would
> >   exist solely in Extras.
> >   
> >   Frankly, I think this is a bad idea, but I know that others
> >   disagree with me.
> 
> Why do you think it's a bad idea?

If you don't have support for your language at install time, how
do you read the screen to install it later? :)

More seriously, I think this needs to at least block on anaconda/etc.
installing from secondary repositories, as it's something that *would*
be wanted at install time in most cases.

> > I suspect we could come up with some significant reducutions in
> > Core if we tried hard. Looking over a report of all the leaf nodes
> > in the distribution would produce lists of smaller packages that
> > could be removed...
> 
> Any chance we could automatically generate for every Core release the RPM
> dependency graph that Adrian Likins used to build?  That would be a
> *perfect* mechanism to respond to the "hey, let's just remove package X"  
> arguments.

Lack of space for 50x50 page postscript documents?

> > Comments? Flames? Not at all what you were looking for?
> 
> One more thing: What about "Fedora Commons" instead of "Fedora Extras"?  I 
> realize that it then overloads the FC acronym, but "Extras" seems wrong to 
> me now, especially since we're going to be relying so much upon Extras 
> over time.

Contrib! *ducks*

Would Commons get confused with a patent commons?

Bill