seth vidal (skvidal@xxxxxxxxxxxx) said: > So if you have any ideas discuss them here and post criteria to the > brainstorm page. OK, time for a brain dump. Stephen mentioned wondering who the Core architects were. Historically, it's been a loose confederation that involved mainly myself, Elliot Lee, and Jeremy Katz, with other people as necessary. New packages would be proposed, generally by those who would be maintaining them. They'd be asked to provide: - package name (example recently: libosp) - what it does (blah) - why it's needed (it was split off from openjade. Required by various things) - whether or not it needed to be in the comps file (and if so, where) A decision would then be made; sometimes it would be 'please put this in Extras instead'. If it was decided to be fine for Core, it would be added to some internal machinery, and the maintainer would check it into CVS and build it. A similar process would be followed for package removals. However, general reviews of the package universe looking for likely candidates for movement were only done when there was a space crunch, or as occasional projects when bored (such as looking for libraries no longer used by any apps.) That's the general mechanics of it, anyway. Now, as to criteria. I'm sure some of the interaction designers will tell me we're going about it the wrong way, but we've historically looked at the following usage cases: - Internet-attached server This means a server for the main internet protocols. This would include a web server, a database server, name server, DHCP server, etc. More esoteric things like gopher servers, IRC servers, or game servers wouldn't really fall into this category, though. - Knowledge worker desktop This would include the base desktop shell and applications that a typical knowledge worker would use - web browser, office suite, e-mail client, chat/IM client. - Technical workstation/desktop This is a superset of the knowledge worker desktop; it would include some basic development tools, and possibly things such as graphics editors. There are various usage cases we *haven't* focused on: - Game machine, with all the various open source games - Educational desktop for kids On top of these various usage cases, we have technical constraints that drive decisions: 1) Core must be self-hosting. 2) Extras must be self-hosting in conjunction with Core. 3) Subpackages cannot be split between Core and Extras, at least not without building them in each instance separately. Now, the question is, within Core, how do we apply these usage cases and criteria to packages to determine what is and isn't appropriate? Generally, we want to ship best-of-breed apps for any particular functionality. While we release that multiple implementations of various things exist and will need to be shipped (barring something very unforseen, we'll always have both Perl and Python), we want to limit the number of redundant apps - in nearly all cases, Extras is the perfect place for them. When determining what we'd consider best-of-breed, we have the following criteria (not all of these would apply to every package): - should be localized, or at least localizeable - should support internationalized input - should function properly in UTF-8 - should be in a modern graphical toolkit, such as GTK+ or QT - should not drag in an excess number of dependencies Historically, we've erred on the side of adding software; there has been a more-is-better approach, as the amount of things people expect a distribution to do increases. Now, how should this change in the future? What needs to happen, in my opinion, is that the idea of functionality being in packages in Extras shouldn't be seen as a bad thing, or as a barrier to entry. There are various ways to accomplish this: - brand the universe of Core + Extras as Fedora, and generally refer to that, as opposed to Fedora Core and Fedora Extras This could have ramifications on other projects, though - as how does this relate to things such as Fedora Directory Server, or other future Fedora Projects? - seamlessly allow Extras to be everywhere that Core is from an installation path - anaconda, yum, pup, system-config-packages, etc. This is done for yum and pup, but not yet for the others. - allow functionality grouping of packages for download and ISO creation, and potentially do this for Extras I've posted about this before - I think it simplifies the user experience if you have things like Fedora Office, Fedora Java - plus, it allows people to easily see what they would need to download for what they want. Alternatively, we could push DVD isos everywhere. But then we'd probably overflow those. (Fedora Blu-Ray!) Once we accomplish these things, we can then reexamine the package contents of Fedora Core as it stands now, and potentially rearrange things significantly. However, this does bring up issues: - Extras and Core have differing release models, generally. Core has a Release, plus Updates. Extras has a more rolling release model. It could be possible to move Extras to be released more like Core, complete with Updates and advisorys. However, I don't know if that's practical or wanted - it requires more discussion. - With the more rolling release model of Extras, how does that fit in with building CD images, or grouping of packages? Do we offer services that build Extras CDs on-the-fly? Do we have generated Extras isos at Core release time, and never afterwards? Do we allow third-parties to make their own Extras isos with scripts (or infrastructure) that we provide? (Cue the Trademark policy!) There are probably other issues I'm missing in this 20000 foot view. While we're here, we could think of new criteria that we'd use, and new polcies we could implement as part of this. Examples would be: - Compatibility libraries - All compatiblity libraries exist solely in Extras (unless they are required by Core packages - this should be minimized, of course.) Compatiblity libraries could exist in Extras for a period of time that is at the discretion of the maintainer, or we could have specific policy (one release? two releases?) This is something we could start implementing today. - Support for languages not deemed as being fully supported (whether by average translation percentage, or some other metric) would exist solely in Extras. Frankly, I think this is a bad idea, but I know that others disagree with me. I suspect we could come up with some significant reducutions in Core if we tried hard. Looking over a report of all the leaf nodes in the distribution would produce lists of smaller packages that could be removed, while reexaming the entirety of Core based on these criteria could remove various larger things. Examples of the former could include things like privoxy or dtach; examples of the latter could include larger things ranging from Jonas to KDE to Ruby. However, it's my opinion that a lot of implementation of the latter category should wait until we have install-time support for multiple repostiories, and potentially support for CD grouping of the same. Perhaps we should go down this road and start listing such things that we would move in the release notes, in preparation for FC6/FE6. Or should that just be F6: And You Thought Twister Was Bad! Comments? Flames? Not at all what you were looking for? Bill
