[arch-dev-public] Repo Distinctions

[Paul Mattal]

Roman Kyrylych wrote:
> 2007/10/17, Paul Mattal <paul at mattal.com>:
>> Damir Perisa wrote:
>>> Wednesday 17 October 2007, Aaron Griffin wrote:
>>>  | 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.
>>>
>>> they are not really that cleanly separated camps.
>> In fact, the thing to note is that they aren't really camps or people
>> taking sides.. it's just about the reality of free agents working in a
>> free system scratching their own itches. We want to capitalize on all
>> the itch-scratching going on so it can benefit us all! If a developer
>> needs to maintain a package, and he can't do so in any repo we provide,
>> he'll have to go do it in private.. and the community suffers from not
>> being able to benefit as effectively from his creative energy.
> 
> Again - what's wrong with committing such packages in community?
> Who's prohibitting that dev from doing so except himself?

The problem is that the level of trust placed in dev packages is, on 
the whole, higher, and when the TU group takes control of the 
package when it is placed in community, it's now the TU group that 
controls the package and makes the guarantees.

And, currently, it is an additional burden that the dev must use two 
non-unified systems to manage his packages, and it is cumbersome to 
move packages between them.

Furthermore, the devs when placing packages in community now need to 
subscribe to tur-users mailing list and read and abide by all the TU 
rules. It's two parallel sets of infrastructure which wastes the 
dev's time.

Finally, when the dev leaves, it's now extra burden for the TUs to 
triage and redistribute/clean out his packages.

>> Instead, we should give him a repo where he can maintain any package he
>> wants for as long as he wants, and require him to clean up after himself
>> and hand the package off or demote it to unsupported when he's had
>> enough of it.
> 
> What it gives to users? We'll end up in many repos as it was with TUR
> before AUR was created.

Not each dev his own repo, all the devs 1 repo ([crust] by Damir's 
naming scheme) where they don't have to worry about long-term 
committment. If tomorrow I decide I don't really want the hassle of 
this package anymore, I follow a protocol to orphan it, see if 
anyone else wants it, then I demote it to wherever it should go, in 
a certain time frame.

>> Right now, for instance, I maintain about 30 packages in a private repo
>> for this very reason.. I was not ready to commit Arch long-term,
>> short-term, or otherwise to have to deal with these packages.
>>
> 
> Again - just put them in community repo (or unsupported if you like so).

I prefer not to turn them over to the TUs. They are in some cases 
important packages that I and others rely on and because they're so 
essential, I'm not willing to trust them to any but the devs.

- P