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

Re: PROPOSAL: Core size reduction "bug day"

On Sat, 2004-07-24 at 23:36, Havoc Pennington wrote:
> On Sat, 2004-07-24 at 21:57, Toshio wrote:
> > * Fedora Extras
> >   - We need to have Extras officially "in place" (so we can see how it
> > interacts with Core.)
> >   - Define Red Hat's relationship:
> >     + Oversight.  Red Hat pretty much controls Core.  What about Extras?
> >     + Resources.  Red Hat is committing hardware to Core (and I believe
> > Extras) but what about personnel?  Does movement of packages from Core
> > to Extras mean the packaging burden shifts to community support or will
> > RH pay employees to maintain packages in Extras?
> Note that there are already some half-answers here:
> http://fedora.redhat.com/participate/terminology.html
Yes.  Just re-read it.  It seems like the relationship of a mission
statement to an action plan, though.  There's an idea of overarching
goals but not enough commitment to see who is responsible for each piece
of the puzzle or even what each piece's goals are.

This could be because people in charge want to get something shipping
that does something and build on that but in that case, I think talking
about trimming Core (redefining that piece's goals) is pretty
non-sensical.  We need to talk about Core in context with the rest of
the Fedora Project.  If the rest of the project is going to remain
undefined until there's physical resources set up at Red Hat, then
saying we can leave it out of Core because Extras is the ideal place for
it is like saying, let's get rid of tech support because the people in
Redmond assure us the next version of the software will be so good
anyone can use it without help.

> Addressing some of your questions:
> What we will pay people to work on - roughly speaking, I would say we
> need an internal maintainer for any package found in Red Hat Enterprise
> Linux. We don't have to be the primary/only maintainer on all packages
> included in RHEL, but we have to pay relatively close attention to any
> package included in RHEL so someone at Red Hat will be assigned to watch
> each package.
> If we defined Core as "stuff that's in RHEL" then it would map closely
> to what Red Hat people will be looking at. Although people who happen to
> work at Red Hat will probably be touching a lot of other things just
> because of personal interest.
> However, I'm not convinced this "Core = RHEL" idea makes any sense.
> There's stuff in RHEL that could do well with a primary maintainer
> that's external. Also, the "what's in RHEL" discussions will always be
> internal-only and so Core boundaries would move around mysteriously.
I agree with all of this as far as it goes.  My main question is how far
is that?  I hope that one day Fedora Core will have quite a number of
outside maintainers in it -- and Extras will have quite a number of Red
Hat employees (paid to be) involved.  In this world, Core would be what
makes a great standalone distro [carefully not defined here :-], Extras
would be useful packages that just aren't in Core (but have maintainers
able to rebuild and test for the new Core releases), and RHEL would be
drawn out of the collective Core + Extras packages as befitted the RHEL

But that's not the only way things could work and attempting to form an
opinion on whether a smaller Core might be good without knowing what the
intended direction is seems pretty irresponsible.

What is Red Hat's ideal dream for the Fedora Project?  What are the
goals?  Good PR?  Free labour?  Previewing new technologies? 
Introducing users to the philosophies of a Red Hat Distribution so every
other OS/distro seems strange and alien when they're forced to use
them?  Get these written down in order of importance and then we can
discuss the merits and flaws of a smaller Core or anything else. 
Without these, we're just stating opinions in light of our own,
conflicting goals (which may have nothing to do with the person who
holds the checkbook.)

Even better, state that there's going to be discussion of Michael
Tiemann's Strawman for X weeks, followed by Y number of drafts with
discussion, and then the Steering Committee is going to lay down a final
map of how the pieces are going to work together subject to revision
after the systems are actually implemented.

> What we'll provide hosting resources for - all of Core, Extras,
> Alternatives. These three are really intended to be in the same
> infrastructure. Extras is not on the main ISOs, and Alternatives
> conflict with stuff in Core/Extras. An example of Alternatives type
> packages would be Ximian GNOME. An example of Extras would be any random
> package we don't include in Core.
> > * Distribution of add-on releases
> >   - Since using FC, I've realized the time-saving benefits of
> > bittorrent.  If I have to download 500MB-1GB of packages to replace what
> > was left out of Core, will I be able to get it as fast?
> >   - How are we going to choose what should be on Extras CDs?  If we
> > think it's hard choosing what should be in and what should be out of
> > Core right now, how are we going to feel about choosing what should be
> > in an Extra Server CD?  An Extra Desktop CD?  A KDE CD?  Can there be
> > overlap? 
> >   - What type of schedule are we going to propose for Extras CDs?
> >   - Will Extras be rebuilt along with Core _before_ a FC release (so
> > Extras software can be updated simultaneously.)
> >   - When installing Core, will loading of Extras/3rd party CDs be
> > supported?
> >   - What technical hurdles can stop packages from being upgraded without
> > help from anaconda (and therefore need to remain in Core)?
> I would say the goal here should be to make Extras as close to Core as
> possible in the user-visible ways. The Core/Extras split has more to do
> with who is doing the organization. The Fedora Project core team
> (whatever that is - steering committee or whatever) manages the Core
> release, tracks showstoppers, sets schedules, etc. etc.
> The Extras releases on the other hand are done by other teams, the
> example on http://fedora.redhat.com/participate/terminology.html
> is a "Fedora Extras HPC" release, presumably there's a group of people
> into HPC providing that.

Makes sense but seems to contradict what Warren has been saying is the
eventual "status" of Extras.  What I get from reading Warren's postings
is that fedora.us _is_ Extras but not officially.  This means one
project which hosts a saner, more organized, higher quality
contrib.redhat.com....  The idea I see expressed in terminology.html
(and Michael Tiemann's post) is that Extras is a meta-project which
encompasses numerous other (possibly overlapping) sub-projects to add
(and subtract) from Fedora to make it more suitable for niche

These aren't irreconcilable -- but there are multiple ways in which they
can be combined with very different rights and responsibilities given to
the contributers.  All I want is clarity.

> I guess you could say that Core is supposed to be the base Linux
> distribution open source project, and Extras is supposed to be a
> collection of add-on projects. By "project" I mean a group of people
> maintaining a group of packages.
> Some people seem to feel Core should be the most-stripped-down-possible
> set of packages, I think that's more of a technical split that belongs
> in the comps file, I would define Core more by the organization.
I hope that Core receives more of a definition than "Created by Red
Hat".  But I agree that it needs to be a solid base distribution rather
than "Just enough to pull in the rest of the OS from the network".  Like
I said, I'm all for a big distribution (my only real criterion is
quality.)  If Core can find a way to transparently handle add-on Extras
projects' releases rather than itself grow huge, also an alternative.

> >   - Red Hat "justifies" Core as a testing ground for RHEL.  How does
> > this requirement affect what can be moved out of Core into Extras?
> It's a bit inconvenient for us if stuff in RHEL isn't in Core, for sure.
> I don't know if it's impossible.
Hmmm...  It seems that not having RHEL stuff in Core would kind of hurt
the goal of testing how packages interact in Core before pushing them
into RHEL.  That implies there's a rather large set of packages (those 
being tested to go into future versions of RHEL) that simply can't be
moved out of Core.

-Toshio"who just wants to know the landscape so he doesn't bring a
winter coat for a walk through the desert"Kuratomi
  t  o  s  h  i  o  +  t  i  k  i  -  l  o  u  n  g  e  .  c  o  m
                                                          GA->ME 1999

Attachment: signature.asc
Description: This is a digitally signed message part

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