[arch-dev-public] Repo Distinctions

[Aaron Griffin]

On 10/16/07, Paul Mattal <paul at mattal.com> wrote:
> 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.

This is definitely an interesting proposal. See, what we have here is
two clear camps that define [extra] different ways - packages
developers maintain, or packages the distro needs.

This isn't an attempt to compromise or combine those ideas, it's an
attempt to embrace them as different ideas. I think this is great.

The problem I see is that it's "more repos". It's more of a headache.
I dunno. I know that sounds like a petty reason, but that's the reason
this doesn't sit too well with me.

In reality, I like this distinction, I just think we should try and
use the repos we already have. Define [extra] the way you defined
[main] and let developers maintain their own packages in [community].
But that's my opinion, and not too many people agree with me on that
one.