Core BrainStorm

[Greg DeKoenigsberg]

Wow.  Thoughtful note, Bill.  Thanks.  My own comments inline.

On Sat, 10 Dec 2005, Bill Nottingham wrote:

<snipping a bunch of good stuff>
 
> What needs to happen, in my opinion, is that the idea of functionality
> being in packages in Extras shouldn't be seen as a bad thing, or
> as a barrier to entry.

+1.
 
> There are various ways to accomplish this:
> 
> - brand the universe of Core + Extras as Fedora, and generally refer
>   to that, as opposed to Fedora Core and Fedora Extras
>   
>   This could have ramifications on other projects, though - as
>   how does this relate to things such as Fedora Directory Server,
>   or other future Fedora Projects?

I think we'll need to figure out how to brand (Core+Extras) and build 
brand usage policies around that entity.  Jesse Keating and I talked 
this week about precisely that.  But I don't think that just calling it 
"Fedora" will work, for precisely the reason you point out.

As frustrating as the name game is, the names "Fedora Core" and "Fedora
Extras" have sorta-kinda-worked because they're basically descriptive.  

Apache is an instructive example.  They've got "Apache," which is
technically called "HTTP Server" now... but they've also got Apache
Tomcat, and Apache Ant, and Apache Directory!  And I suspect that we're in
for exactly that kind of taxonomy ourselves down the road.

> - 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?
 
> - allow functionality grouping of packages for download and ISO
>   creation, and potentially do this for Extras
> 
>   I've posted about this before - I think it simplifies the user
>   experience if you have things like Fedora Office, Fedora Java -
>   plus, it allows people to easily see what they would need to
>   download for what they want.

+1.
  
>   Alternatively, we could push DVD isos everywhere. But then
>   we'd probably overflow those. (Fedora Blu-Ray!)

I don't think it's an either-or.  I think we can and should do both.
 
> Once we accomplish these things, we can then reexamine the
> package contents of Fedora Core as it stands now, and potentially
> rearrange things significantly.
> 
> However, this does bring up issues:
> 
> - 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.

>   It could be possible to move Extras to be released more like Core,
>   complete with Updates and advisorys. However, I don't know if
>   that's practical or wanted - it requires more discussion.

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."

If we start to split out current Core packages into Extras, then it'll be
important to figure out *some* way to do this.  It may be a matter of 
providing a dead-simple mechanism for the conscientious maintainers -- and 
then if, over time, it appears that the majority of Extras packagers can 
handle the security burden, we consider making it a mandate.  But baby 
steps first, I think.

> - 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.

> There are probably other issues I'm missing in this 20000 foot view.

Doubtless -- and if you don't see them, I'm not likely to.  :)

> While we're here, we could think of new criteria that we'd use,
> and new polcies we could implement as part of this. Examples
> would be:
> 
> - Compatibility libraries - All compatiblity libraries exist
>   solely in Extras (unless they are required by Core
>   packages - this should be minimized, of course.) Compatiblity
>   libraries could exist in Extras for a period of time that is
>   at the discretion of the maintainer, or we could have specific
>   policy (one release? two releases?)
>   
>   This is something we could start implementing today.

+1

> - 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?
 
> 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.

> ...while reexaming the entirety of Core based on these criteria could
> remove various larger things. Examples of the former could include
> things like privoxy or dtach; examples of the latter could include
> larger things ranging from Jonas to KDE to Ruby.

Obviously, the "favorite collections" idea must be rock-solid before we 
can even consider the notion of "Kedora".
 
> However, it's my opinion that a lot of implementation of the latter
> category should wait until we have install-time support for multiple
> repostiories, and potentially support for CD grouping of the same.
> Perhaps we should go down this road and start listing such things
> that we would move in the release notes, in preparation for FC6/FE6.

+1.  This is the right roadmap for F6, IMHO.

> 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.

--g

_____________________  ____________________________________________
  Greg DeKoenigsberg ] [ the future masters of technology will have
 Community Relations ] [ to be lighthearted and intelligent.  the
             Red Hat ] [ machine easily masters the grim and the 
                     ] [ dumb.  --mcluhan