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 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. 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. 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. > * Packages already in Core and those in RHEL: > - How will we deal with dependencies that are unmet by a smaller Core? > - 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. Havoc
