[arch-dev-public] Repo Distinctions

Paul Mattal paul at mattal.com
Tue Oct 16 18:35:47 EDT 2007

So I've been listening to the discussion about what should and 
shouldn't be in extra so far, and I've come to the following 

1) Niche is subjective.

2) Even if it weren't, whether a package is "niche" or "mainstream" 
is not a good criterion for classifying it in one repo or another.

3) Some good criteria for classifying packages in one repo or 
another are:

   a) Desire to maintain a package long-term.
   b) Association with a particular group of people you trust.

4) There are many who actually do trust developers more than TUs. 
This is not intended as a judgement, rather as an observation.

My feeling is that we should have under the developer umbrella a 
split of the existing [extra] into two repos:

[main] - to be in the main repo, a package must be voted in by a 
majority of the developers; we commit to maintaining these packages 
over a long period of time, and announce 6-12 months in advance if 
we're going to remove them (and again, this removal requires a 
majority vote); there should never be any orphans in here, and we 
should be extremely stingy about putting packages in here in the 
first place

[extra] - developers can maintain any packages in here they wish; if 
they decide to orphan them, they must announce that to the 
developers and TUs and see if anyone wants to take them on; if 
nobody wants them, they get demoted and orphaned in unsupported so 
that the community can still benefit from the work they once did

This is just a proposal intended as a starting point for discussion. 
But I think some notion of a supported group of [main] packages that 
we collectively commit to maintaining will make us feel less bad 
about a more in-flux [extra]. Also, a clear process about what you 
do when you orphan a package helps get those packages picked up by 
those with time or inclination to deal with them.

For those who would say: why not just use [community] as the [extra] 
you're proposing above? The answer: so you can tell which group of 
individuals is standing behind these packages-- the developers. With 
that information, you can then decide for yourself who to trust.

- P

More information about the arch-dev-public mailing list