[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 
conclusions:

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