[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