[arch-dev-public] Repo Distinctions
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
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
[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.
More information about the arch-dev-public