[arch-dev-public] Where [erxtra] ends and [community] begins

[Eric Belanger]

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.