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

[OH-Dev] Giving more people commit access

Asheesh Laroia lists at asheesh.org
Mon May 12 00:59:31 UTC 2014


My theory is we should do the simplest thing that could possibly work, and
use that to gather data on what complexities we should add.

Given that, I'd be -1 on requiring two reviews unless we know it fixes an
issue we have experienced, or an issue that we are very likely to
experience. I'm open to other ideas, though.


On Sun, May 11, 2014 at 5:27 PM, Shauna Gordon-McKeon <shaunagm at gmail.com>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/5b7e7d77/attachment.html>


More information about the Devel mailing list