Re: [gentoo-dev] Maintainership and commit policy

[Mikael Hallendal]

Hi!

> AFAIK, we could manage the entire thing via cvs - no incoming dir, no
> commit-request emails.
>
> We would have several 'trees' in cvs: stable, unstable (=devel),
> external (any better names?), incoming (=user-submitted), trees for
> past releases which could get bugfixes, etc.
>
> A developer who wanted to change another developer's ebuild would have
> to commit a new revision of that ebuild to the 'external'
> tree. (That's what he'd have permissions to do.) The maintaining
> developer could then look over his changes (and the commit log
> message), and if he accepted them, merge the changes into his main
> devel tree. Once in there, the changes needed to be proven stable and
> good (like the maintainer's own work) and would then be merged into
> the stable tree. Non-developers who did 'emere rsync' could only get
> things from the stable tree.
>
> A similar procedure wuold be used for 'incoming' user ebuilds, with
> another cvs tree.
>
> What do you think?

Hmm, would this mean that I would have to have four different cvs
trees checked out from CVS? stable, unstable, external and incoming?

I think an incoming is unnescessary, an incoming directory is much
better. Perhaps is it my lack of cvs knowledge but would I then have
to update my incoming/external tree and look if any of my files have
been added/updated and then copy the file into my unstable tree and
commit it there, remove it from the external/incoming tree and 'cvs
rm' them in those trees? This doesn't sound like a good solution and
indeed creates more work then mailing the maintainer.

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@×××××××××××.se
CodeFactory AB                  http://www.codefactory.se/
Office: [phone]     Cell: [phone]