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 direction. 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 applications. 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 -- _______S________U________B________L________I________M________E_______ 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
