Roman Kyrylych wrote:
2007/10/17, Paul Mattal <paul@mattal.com>:
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
Damir Perisa wrote: 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