Re: [gentoo-dev] Maintainership and commit policy

[Thomas M. Beaudry]

Sounds like the Mandrake system and it seems to work for them.

On Fri, Aug 03, 2001 at 07:16:40PM +0300, Dan Armak wrote:
> 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?
>
>
> On Friday 03 August 2001 18:08, you wrote:
> > Hi!
> >
> > I renamed the thread since it's not about xchat 1.8.2 anymore.
> >
> > > I think if we choose to do this, then we had better rethink the
> > > incoming directory right now.  While it may be okay for a few
> > > outstanding user-submitted ebuilds, this scheme has the potential to
> > > cause a lot problems.  What we really need is an unstable cvs tree;
> > > then user-submitted ebuilds and non-team developer-hacked ebuilds can
> > > go there until they are verified by team members.
> >
> > If we have maintainer of ebuilds (which I think we shall have) I don't
> > think that other people should commit into the CVS tree without his
> > aproval (neither unstable nor stable). It will be very hard for a
> > maintainer of many packages to keep track of what's happening if
> > people just commit at will.
> >
> > > I think all we need is maintainer.  This is the guy who "puts his rep
> > > on the line."  cvs log keeps all the other information.  The person
> > > you really want to complain to about a bad ebuild is the maintainer
> > > anyway. Then he can do a cvs log to see who the culprit is and get in
> > > touch.
> >
> > This will not be a problem if only the maintainer are allowed to
> > commit (or aprove commits). I think this is the best way to do it.
> >
> > If you want to make a commit to an ebuild that you are not maintainer
> > of:
> >
> > If you are a developer:
> > 1) Send the patch to the maintainer asking if you may commit.
> > 2) The maintainer might commit or aprove of you commiting or tell you
> >    why it won't go in (and perhaps what you need to fix first).
> >
> > Otherwise:
> > 1) Send the patch to the maintainer which will either commit or tell
> >    you to change the patch in some way.
> >
> > This will make it harder for people to commit to all kinds of ebuilds
> > but I think that this is the way we have to do it in the future.
> >
> > Of course a maintainer might give a certain person commit rights if he
> > trusts the other developer to do it right.
> >
> > Regards,
> > Mikael Hallendal
>
> --
>
> Dan Armak
> Gentoo Linux Developer, Desktop Team
> Matan, Israel
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@××××××××××.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
>

-- 
Thomas M. Beaudry K8LA / YS1ZTM
k8la@××××.net