[arch-dev-public] Repo Distinctions

[Paul Mattal]

Aaron Griffin wrote:
> 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.

This post and Damir's highlight to me the increased importance of the
strict rules for orphaning packages above all.

However, I think this only works well when the boundaries/commitments
are clear and everyone has buy-in. It's a lot easier to say to a group
of developers "guys, please pick up the orphaned packages from this
developer who left in [mantle]" when those developers voted to support
that package long-term in the first place. I know I'd be more inclined
to make the effort to pick up those packages.

To Aaron's point about too many repos, I would say: There's no good
reason why you shouldn't be able to move packages easily from one repo
to another with one commandline-- that's what repoman is trying to
achieve. When repos are really that lightweight it stops being a big
deal if you have one more and starts being beneficial to have a more
detailed classification of your packages.

Of course, if the argument is that devs should maintain packages in
[community] because the distinction between devs and TUs isn't
important, another solution would be to flatten things and have [core],
[mantle] and [extra] and let TUs and devs maintain packages in [extra].

But I still think it's worth separating the devs and the TUs.. this is
not to say we shouldn't poach regularly from the TU pool to devs, but
the TU post is a great way to get yourself trained to be a good dev.
Look at how many came through that way!

- P