This site is an archive; learn more about 8 years of OpenHatch.

[OH-Dev] Giving more people commit access

Shauna Gordon-McKeon shaunagm at gmail.com
Mon May 12 00:27:23 UTC 2014


Do we want to have multiple reviewers, or do you think that will slow
things down too much?  For instance, the first reviewer could leave a
comment approving (or gives feedback, and after that is incorporated
approves), and the second reviewer could merge.


On Sun, May 11, 2014 at 8:24 PM, Asheesh Laroia <lists at asheesh.org> wrote:

> Hey all,
>
> I thought about it more, and I concluded that we should give more people
> commit access to oh-mainline.
>
> Here is my plan:
>
> * If at least one person in the Login Team vouches for you, and you have
> gotten
> at least two pull requests merged into oh-mainline (anything in
> oh-mainline, including docs), you will gain push access to the oh-mainline
> repo.
>
> * Login Team is defined here:
> http://openhatch.readthedocs.org/en/latest/community/login_team.html
>
> * I'll run a script every day <
> https://github.com/openhatch/oh-pr-checker/blob/master/ok.py> to see if
> I've fallen behind.
>
> * I've given the following GitHub users push access:
>
> *    Aaron1011
> *    brittag
> *    cpallares
> *    eeshangarg
> *    natea
> *    onceuponatimeforever
> *    pythonian4000
> *    shaunagm
> *    sunu
> *    willingc
>
>
> I also made a slight change to our branching -- there now exist
> deployed_linode.openhatch.org and deployed_linode2.openhatch.orgbranches, which point at the git repo on both those servers. That way,
> there is great clarity about when someone merges some code, but it isn't
> yet deployed.
>
> Only the Login Team people will be able to deploy things, for now.
> Hopefully we can get that fixed shortly.
>
>
> If you're in the list of people I've added here, welcome aboard! And if
> you're not yet, hopefully you will be.
>
>
> Given the much more decentralized access, I'm hoping that people will
> mostly follow the following guidelines:
>
> * Submit your changes as a pull request, and get someone to review them
> before merging them. Don't push your own changes directly without review,
> unless there is some super pressing reason.
>
> * Review other people's pull requests, and merge them if you are happy
> with them, and take good care of licensing. (The docs do talk about this
> already.)
>
> * If you are reviewing people's docs changes, then the quality of the
> submission is not as important as for code changes.
>
> Having more committers maybe means I will start getting more code review
> for my own changes, which would benefit everyone.
>
> That's all I can think of, but I'm sure there's something else.
>
> -- Asheesh.
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20140511/5b39aa19/attachment.html>


More information about the Devel mailing list