[repoman] Maintainer, Maintainee, Maintainere

[Paul Mattal]

Essien Ita Essien wrote:
> I wanted to start up a discussion concerning package maintainance and TU 
> workload.
> 
>  From #6 on the http://repoman.mattal.com/ website it says: Any trusted 
> party may register as a maintainer for any package. Packages will 
> usually have more than one maintainer.
> 
> I think that just because I upload a package to a repo, I shouldn't be 
> labelled the Maintainer (but I should be responsible for seeing that it 
> is being Maintained).
> 
> In the current model, when a contributor convinces a TU to upload it to 
> community, it seems the contributors work finishes there, and the TU is 
> now more or less FORCED to upload something that they may not be too 
> keen on maintaining. Ramp the numbers on this, and its very easy for a 
> TU to be actually excepted to Maintain much more than they're able to.
> 
> What I think should happen is this: The contributor of a package will be 
> its Maintainer. The TU will just be an upload and Quality control 
> channel. Bug reports will be sent _directly_ to the 
> Contributor/Maintainer of the package, while the TU just makes sure that 
> there are no errors in the package etc.
> 
> If a TU sees a package going unmaintaineed, they can (and should) 
> contact the real maintainer and threaten to remove their unmaintained 
> packages from the repo if they don't shape up. This should allow the TUs 
> to only actually maintain what they actually WANT to maintain, but only 
> act like a supervisor on other things that they upload but are 
> maintained by other ppl.
> 
> The new repoman system will allow this kind of maintainance model to be 
> EASILY acheived.
> 
> thoughts?

The general idea of the new system is to shift the roles a little so
that TUs and developers can act more as gatekeepers than having to do
all the work themselves. So it is hoped that anyone who wants to
contribute, the contributor or anyone else, will be able to contribute
easily.

This is as yet a feature I haven't figured out the easiest way to do.
One thought I had was to use monotone for this, and maybe mercurial
allows the same thing.

The basic idea is to be able to separate the propagation of patches from
the trusting of patches; so a developer can receive all the patches,
assess them, and decide which to merge into the trunk.

Sadly, doing this with subversion is nontrivial, both because of its
overly simplistic branch/merge mechanism and its combination of
propagation and trust mechanisms. So we'd have to slap some system for
patch management to do this work alongside subversion.

- P