On Tue, 5 Apr 2005 16:14:41 -0400, Gregory Maxwell wrote: > Here are some reasons that if I were a package, I might not want to be > in extras: > > 1. Much smaller audience (lots of people do install everything in > core, but not so with extras today) Moot point, as laziness is the primary reason why Joe User chooses an everything-install in the fear that manual selection of packages would be to complicated or time consuming. Despite the availability of tools like Yum, it's still considered too inconvenient to add missing pieces after installation (and system-config-packages is a dead end with regard to adding software to an up-to-date FC). And do those people only install everything, or do they also use everything? Where is the benefit of users who install everything but use only a fraction of the packages? For most of the Extras users it makes no sense to install every package from Extras. > 2. More difficult distribution model (if someone burns me the DVD ISO > redhat provides it has all of core, but none of extras) Does the same "someone" also burn complete Fedora Core Updates onto a separate DVD? That could also be done with a mirrored snapshot of Fedora Extras today. But as pointed out above, Joe User most likely doesn't want another DVD of packages from which to use only a few. > 3. 'Less reliable'source: When I get a distro from redhat, I'm getting > it from people I trust.. When I get extras it's coming from a bunch of > people on the internet I dont know. Now it's probably true that core > doesn't have that much more redhat oversight on low profile packages, > but it's a perception issue. That's why fedora.us started with a mandatory QA process which included reviews and approvals by two different persons after verification of source tarball checksums and the recommendation that they are to be compared with packages from big/well-known distributions, too. But I agree, unless a packager follows the source code changes done by the upstream project with every release, there is the risk that an upstream developer goes wild and tries to introduce malicious code if it's not done by a hacker who breaks into a download server and manages to fool the packagers and the community. If you believe in threats like that, you belong to the target group of Fedora Extras commits-list, where you can observe CVS commits. > 4. If a package is broken in core is known broken it has some > potential for holding up a release. Not so for extras, so there is > more incentive to fix a package. Well, in a community project, anyone who has strong interest in a package, which is found to be broken, can volunteer as the one who provides a quick fix. > 4. Almost no build synchronization. When is a package in extras > guaranteed to build on a new version of FC? ... Never. Bad. Unless I'm misinformed, hopefully we still plan to have FC4 Extras ready together with the release of FC4 or shortly after. For that we would need a mass rebuild at least for FC4 Test3, though, to catch remaining packages which don't compile or fail at run-time and which have not been checked by their owners due to lack of a Rawhide or FC4 Test installation. I also think there are a very few package owners still missing. > It's possible > that a package will effectively drop out of core without any conscious > decision. What if a user depends on that package, upgrades to FCn+1, > and finds that it no longer works? This is far less likely to happen > 'on accident' for packages in core. Fedora Extras Development is used to prepare packages for FCn+1, currently. And once more, a user, who _depends on a package_, should invest some time in making sure the package does work in FCn and continues to work in FCn+1. -snip- > All of these issues only matter for packages that are coming out of > core.. For a package that never was in core, it is less of an issue... > being in Extras is better than nothing at all. Packages, which come out of Core and effectively are "dropped on the floor", need to be picked up by the Fedora community. And Fedora Extras development is open enough to allow for participation, and monitoring of development done by others. > Perhaps a solution would be to define a subset of extras that belong > to a set of more stable/more important. Start with a set of packages which you think are not stable or not good enough. File a bug report for each package.