[arch-dev-public] Repo Distinctions

[Eric Belanger]

On Tue, 16 Oct 2007, Simo Leone wrote:

> On Tue, Oct 16, 2007 at 06:35:47PM -0400, Paul Mattal 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.
>>
>
> Sounds like making a mountain out of a mole hill to me. What's wrong
> with something simple like... extra is for packages that aren't integral
> to the distro which the devs feel like maintaining, and community is for
> packages tus feel like maintaining, and unsupported is for things no one
> wants to maintain?
>
> -S
>

I agree with Simo here.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.