On Sun, 14 Oct 2007, Damir Perisa wrote:
Sunday 14 October 2007, Thomas Bächler wrote: | To me this is easy: The core/extra/unstable repositories are | maintained by the smaller group of Archlinux Developers, the | community repository is maintained by the larger and less strictly | controlled group of Trusted Users.
i agree to this distinction. extra is per definition extra to core (or earlier current - the main official repo). it is extra, but it is official.
community is not official by devs but official by community - therefore also the name. it is less strict and can also be less clean (of course it should be kept as clean as anything :) )
official means, that at least one dev is responsible for the contents.
if somebody needs (wants) to document this, here a first draft from my thoughts:
== a package needs to be in extra (if not core) because:
* it is a dependency to other pkgs and crucial to their functionability i.e. it is a node in the dependency tree - compared to the leaves on the end of the tree - e.g. non-core libs, xorg, ...)
* it has a main benefit on the system functions (additional drivers against kernel26 or official xorg)
* it affects in any case any of the functions of packages in [core]
== a package may be in extra (per definition not in core! core only has pkgs that _need_ to be there) because at least a dev is willing to maintain it and:
* it is an open source project product (i.e. not limited distribution) in the state of usability --- if this criteria is not set, it may be in unstable
* it is a very popular package
* it covers a unique function to an OS with open source software (e.g. publishing - scribus)
== a package should not be in extra:
* if it does not need to be there + there is no reason that it may reside there
* if no dev is using it
* if no dev is willing to maintain it (orphans are temporary per definition and should be moved after a certain lag phase to unmaintained (=unsupported) if nobody wants it)
please feel free to enhance this thoughts if you feel needed.
I suggest the following process: If a dev wants to maintain a package, he can do so in the extra repo. When he orphans it he post to the ML so that we know about the issue and to perhaps speed up its readoption by another dev. If no dev wants to adopt it and if its movable to community (above reasons), we ask if a TU wants to adopt it. If so, we move the package in community. If no TU wants to keep it, we could keep it in extra, especially if it's up-to-date and in working condition. We might be able to maintain it as an orphan as a group effort if people check it regularly for update and fixes. I don't have any problem in having a few orphans. If the package becomes stale or a pain to update/maintain, we can ask again the TU and this time move it to unsupported if no one wants it. We could also do the same if the number of orphans becomes too large to handle.
... and a general note on the whole matter: i realise that several devs - mostly newer devs - raise the matter now on the regular basis... and link it to the fact that we have quite some orphans laying around. stop it! we are all aware of the lots of orphans and the thoughts i listed above.... but i do not want to have it risen every time i include a new pkg to extra (to my list of pkgs! i never orphaned a pkg without a fundamental reason in the last 3 years).
- D
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.