On Thu, 29 Jul 2004 12:30:35 +0200, Matthias Saou <thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net&gt; wrote: Funnily, I recently saw an arcade machine running Tuxracer .. presumably the arcade hardware maker (and the place's propietor) thought it was going to pay for itself. I quite agree though, they could be safely moved to Extras. When I was using Mandrake the game I played most was BzFlag, not either of the two above. - Michel

I don't have any objections, but I think this is pretty useless, its not like this is goign to free up a whole lott of cdromspace. My 2 cents: 1) RH badly needs to get an actual / intergrated Extras, for starters just move the entire fedora.us tree there, this includes the internet enabled FCx end user being able to install packages from extras from a GUI without having to tinker with sources/yum.conf/whatever 2) Once 1) is in place then stuff can be moved to extras. I think it is best if RH first discusses where to draw the line internally, and then comes with a list saying this is what we are going todo, if this contains drastic measures like putting kde in Extras explain why. Lett us burn down the list on fedora-devel for a week and no longer! Then make a definitive list based on the feedback an just do it. We are all tlaking way to much and thus not being productive! Regards, Hans Warren Togami wrote: -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es

On Thu, Jul 29, 2004 at 12:23:04AM -1000, Warren Togami wrote: Your selection policies get odder every day Warren. It's not constantly improving because its -finished-. If you want to remove stuff that hasn't improved for years and is large you could start with TeX - which is also finished. Chromium probably could go. Tuxracer I'd be inclined to keep as its a very good 3D demo and its very Linux. Its also very small compared to a lot of the newer games. Alan

Actually, I just gave my 5 year old daughter a tour of the FC2 screensavers, and her favorite, by far, was boxed. Her 2nd favorite was the cows. Just a datapoint ;-) M On Thu, 2004-07-29 at 09:59, Jeff Spaleta wrote:

I'm of the considered opinion that defining "Core" and "Extras" was a bad idea. It makes the problem too binary. We should perhaps consider the issue as a tree and define several trees, each path being a possible install. Currently Core and Extras have become emotionally loaded political words and, as such, have lost any rational meaning. We need, instead, to define a set of target endpoints (e.g. administrative assistant, programmer, grandmother, email-browser, luser, etc). Then someone becomes the designated "maintainer" for the endpoint and their word is law. The maintainers can mark the packages with their badge and the build system can make a "grandmother core". This can be done downstream. The maintainers all report to a god-like figure (i'm unavailable) similiar in role to a Linus. So the "newbie" maintainer can have tuxracer. The "sysadmin" maintainer can have the registry. The "free" maintainer can have religion. And we all can have peace. kumbuya. Tim Daly

On Thu, 29 Jul 2004 10:36:23 -0400, Michael Tiemann <tiemann(a)redhat.com&gt; wrote: The real trick to a continuum of collections are: 1)making sure the install media sets for the collection continuum (hereby called the C continuum) gets appropriate testing. ...raise your hand if you honestly think having more install media sets besides just Core isn't going to reveal more packaging and installer problems. And it only gets worse if you allow the use of an alternative installer for targets where anaconda doesn't make sense (ie low end hardware targets where rule makes a lot of sense as an installer) 2)A way to ask the system for information about which continuum member media set was used to do the last install/upgrade to reduce the effort required to confirm and track down reported problems and prevent even more bugzilla pollution. Related to (1). 3)making sure that the C continuum install media sets ALL come with tools that understand how to use Core and Extras to get updates AND additional software, not just from the internet but also from media. If Core+Extras makes up the full range of packages and the other media sets in the continuum are just different mixes of all the things that are available in the Fedora repos, making sure vendors/lugs can continue to offer additional software media sets(not necessarily bootable media) has to be a requirement. -jef

On Thu, Jul 29, 2004 at 10:30:52AM -0400, Tim Daly wrote: I don't think you can make it go away. I know some people would like to. What happens beyond the Fedora name is intentionally not Fedora business. It can't be because as you rightly say Core + Extras will never meet everyones needs. Some repositories may also be proprietary (eg the macromedia flash packages or the nvidia drivers wrapped in rpm format) and are thus outside of 'Fedora' and the Fedora goals but are still very very useful to some users. When you have too mnany repositories especially of critical stuff you end up in a gigantic dependancy disaster. That is one reason core has to be well controlled and why extras is defined in terms of building on core and extras only. This at least pulls the core libraries into a single place and form. Equally the original definition recognized people would want to do things that broke compatibility with core components and that users should be able to tell this would happen - Fedora Alternatives being the tag name we used for such packages. That might be as mundane as a gnome-libs variant with new features or as significant as using the FreeBSD kernel or Hurd as the core kernel. There does seem to be an O(N^lots) co-ordination requirement between main repositories and we must be careful of that. Maybe Conary will, once half of it has stopped being armwaved, solve that. Alan

On Thu, Jul 29, 2004 at 11:19:37AM -0400, Tim Daly wrote: You end up in a horrible mess very rapidly. I build ncurses with libc6 you build it with glibc, I want to install a package using each ncurses and now I'm already stuck You'll see those anyway, at least until there is a working Extras and there is a policy written. In a sense you can already do this. Just put whatever you like in yum.conf and make subset repositories. Does mean duplicate disk usage so its not the final way to do it I grant. Disagree. If computational mathematics clashes with childrens packages over a library both pulled from different 3rd party locations with differing configuration options where do you want to assign blame ? The kernel is a bit different to a distribution - the model mostly works in kernel space due to a lot of communication and massive modularity. Plus its cheap to go "whoops, I'll fix that". A look at out of kernel device collections will also tell you we have most definitely *not* solved the problem space.

On Thu, Jul 29, 2004 at 11:56:57AM -0400, Alan Cox wrote: I think Conary is a wonderful idea, but until dependency handling is factored in, we have no way of knowing whether the model that is working for the kernel will scale up to the level of a distribution. I think much of it will depend on the actual depth of the graph of real-world dependencies. Currently, the interfaces of both kernel and libc are fairly static, and care is taken to maintain compatibility, so things like Andrew Morton's -mm tree, which now includes plenty of other changes by reference, actually results in a working system. But when we take that into the realm of something like GNOME, it is quickly apparent that one may need to have many versions of libraries, config files, etc. Just moving from the stable to the development branch of an application like Gnumeric is a headache, involving numerous library upgrades. (Efficient) virtual environments like Linux Vserver that provide isolation are garnering attention not simply to run hosting services, but because they offer interesting management possibilities, like the the ability to install and test new versions of a complex cluster of applications (say Apache Tomcat/Jakarta, bugzilla, gforge, etc.) on the same host with the old versions. Perhaps coupled with something like Conary, this would provide an efficient mechanism for reducing risk while staying close to current. It would be nice to see vserver-like functionality accepted upstream, and the completion of Al Viro's namespace work, including per-mountpoint flags, partial namespace sharing, union mount, unionfs, etc. Regards, Bill Rugolsky

On Thu, Jul 29, 2004 at 02:04:36PM -0400, Alan Cox wrote: Good to know, as I've been working my way through a stack of patches and vserver is in the pile. Xen 2.0 certainly looks interesting, and it is hard to quarrel with the performance figures. There is the little issue of device drivers ... I guess that leaves private namespaces/chroot plus SELinux for isolation on a single kernel instance, along with cowlinks or something similar for sharing. Bill

On Thu, 29 Jul 2004 10:30:52 -0400, Tim Daly <daly(a)rio.sci.ccny.cuny.edu&gt; wrote: I didn't say it wasn't their job. I'm saying these are the harder issues in the set. And not necessarily the obvious ones. Becuase Core as one installable distribution in the continuum is going to drive the release and testing cycle for Fedora development, simply becuase its the one installable distribution that Red Hat has primary interest in, and Red Hat makes the final say. Core isn't gone, a rose by any other name....still has thorns. Red Hat's compelling interest are going to be embodied in something akin to what is called Core now even in the contiuum model. The volunteer efforts of red hat employees to maintain other installable collections inside Fedora aside, the compelling business interests at Red Hat, are still going to be focused on one specific point in the continuum. That one point in the continuum is going to drive the release and testing cycles. Call it core, or whatever, it will be a singularity in the continuum and it will carry weight beyond which other continuum distributions have when its time to think about delays in the development cycle. Vendors... as in people selling install media to users who do not have the network connectivity to do online installs or upgrades. Fedora.redhat.com has a whole page dedicated to a list of these entities. Its not so much that vendors care, but that people care about being able to get access to media sets to install from, media sets with a small finite number of discs. Are you suggesting that other points in the continuum are not going to be synced with the 6month-ish release cycle that Core (or whatever you want to call it that Fedora development tree is patterned to release against). I really don't think any debian based downstream distribution example is a good example for the types of problems any fedora downstream distribution is going to face. Fedora development moves FAST. If other points in the continuum can not sync'd to that fast pace, thats going to be a problem, if the intent is to have all points in the Fedora continuum trying to use the same package updates that live inside Fedora's package set. If each point in the continuum is just going to end up having its own release cycle and its own set of package updates...they might as well just fork and be seperate distributions and not even try to use the fedora build system or use the fedora name, they will diverge quickly. Debian's glacial release cycle gives something like Quantian a lot of leeway to upgrade packages as needed without conflicting with the debian base from which its derived. Trying to base anything of Fedora with its quicker time-based 'Core' release cycle pretty much demands that releases of a Fedora collection be in sync with the Fedora base time cycle. If knoppix and quantian had to deal with a stable debian branch that churned every 6 months... they'd fork and maintain seperate development of packages completely. this assume anaconda will be the installer for all points in the continuum, this isnt going to be the case. There has already been repeated gnashing of teeth about making room in Fedora for non-anaconda based install media using something like rule. member from the installer means you have to have ALL fedora packages on hand on media. That's just not practical. Every continuum member will need its own set of install media to be practical, to prevent people from having to have 17 cdroms on hand during media based installs. No one is going to want to have their point in the continuum need stuff off of disk 17 to do a media based anaconda install. Pretty sure this comment comes from a misunderstand of what i meant by vendor. Let me just point out.. since you brought up the kernel development as a model. "downstream" maintainership of the kernel is something fedora development has explicitly working to avoid becuase of its burdens. I'm not sure encouraging a "downstream" distribution maintainership model inside fedora makes for a consistent world view when "upstream upstream upstream!!!!" is such a frequently heard chant. I think its a bit misleading to setup a system that expects volunteer downstream maintainers to build a distribution as an achievable goal, when upstream is where fedora developer's place their efforts. Yes... advoocacy IS volunterring. But, its one must not encourage volunteers to tackle tasks that we know are beyond reasonable efforts to accomplish, becuase that is the best way to have volunteers burn out and cripple the volunteer efforts completely. I'm not sure you have heard my rant about the lack of planning and management of volunteers that fedora continues to not have a solution for, I'll gladly rant about that to you if you want. But for now let me just restate that your kernel development analogy you used has a darker intepretation concerning the burden of "downstream" maintainership versus "upstream." And if the fedora developers know better and they know "upstream" maintainership is prefered, we should not as a matter of policy build a system inside fedora where "downstream" maintainership of alternative package collections is encouraged if we know "downstream" maintainership leads to significant burdens. The conspiracy theorist in me, would say that such a system would only serve to shut volunteers up by encouraging them to toil on an unaccomplishable task. I definitely want to see someone inside the fenceline at Red Hat use this "downstream" maintainership model long enough to see 2 or 3 'Core' releases to gauge the robustness of the "downstream" distribution focus, before encouraging any bright shiny new volunteer to attempt this. -jef"about as bright and shiny as a 1902 penny, dug up from an unused new york sewer pipe"spaleta

On Thu, 2004-07-29 at 23:50, Alan Cox wrote: True, I'd keep Tuxracer around. We should also think about users of FC3 whom are going to be demoing the machine (I do this frequently) - sometimes, setting up demo machines happen, and people don't have Internet access while this is being done, so getting stuff from Extras is hard And digressing, we have no definition of what stays in Core or Extras. Also, we just lack an Extras (or Alternatives for the matter) currently. So this has to be well defined first, and at some stage, my vote will go to Extras also making CD (or DVD) ISOs, so that if folk wan't complete "Fedora" sets, they might get seven CDs, 4 of which might be Core, and 3 of which are Extras/Alternatives Keeping in mind again, not everyone is (fast) Internet connected /me speaks from the 3rd world country POV -- Colin Charles, byte(a)aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi

Stan, On Fri, 2004-07-30 at 17:52, Stan Bubrouski wrote: Needless to say that 3D/OpenGL software isn't supported on non-3D-accelerated drivers (nv) and that nobody in his right mind can support the binary only nvidia drivers (unless working at nVidia, if you have problems with their drivers, they might help you). Nevertheless, I could get all the 3D stuff I happened to throw at my laptop working with it. What you describe is what I think of as "Fedora Hardcore" ;-), at least for my definition of "essential". No updates doesn't automatically mean "unmaintained". I've yet to see that the problems you describe are really in tuxracer and not some driver issue. Nils -- Nils Philippsen / Red Hat / nphilipp(a)redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

On Sat, 2004-07-31 at 01:52, Stan Bubrouski wrote: As others like Alan and Nils have stated, 2+ years with no updates doesn't mean unmaintained. The software is "complete" This is an issue with your nVidia drivers Stan, not a tuxracer one. Works fine here on my ATI card, even on PPC How do we define "non-essential". People can be cheeky and say, essential means to get a system started and running. What constitutes OpenOffice.org being essential, when Abiword, Gnumeric and Magicpoint are also included? When coming to trimming down things, we should be careful to keep in mind that we still want to make a complete and useful distribution -- Colin Charles, byte(a)aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi

Well, i found myself some days ago, thinking "...fedora is increasing the packages, from time to time someone, ask's for a new software to be included., but where this will lead too. 2 DVD's??" And my conclusion, is that some must go out, and i thinked in the games. There must be a "clean up" in the games list. To free some space, needed for the essencial packages.. So i agreed with your proposal, and some more games could be included also. Nando Warren Togami wrote:

On Sat, 31 Jul 2004, Russell Coker wrote: Ok since CVS hasnt happened yet, and Extras isnt happening until after CVS.. maybe the FC3 development plan could change a bit. Mark everything in the core that is to be moved to Extras when the glorious day of CVS (or wahtever) occurs as deprecated, but ship it in FC3 as non-installed cd's. IE they are still there.. but make Cdrom 3/4 not part of the general install but in firstboot when other packages as asked to be installed. When Extras repository can be brought up and maintained (FC4/5 ?) then you can drop those cdroms and just focus on the core items. -- Stephen John Smoogen smoogen(a)lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- "We cannot have a free government without elections; and if the -- rebellion could force us to forgo, or postpone, a national election, -- it might fairly claim to have already conquered us." Abraham Lincoln