Re: Avoid privately-owned PRs

Yes, Adam and I have often done this and, in some cases, what Dom said about explicitly pulling in a PR and fixing as we apply it.  I am *not* in favor of many people having write access to the repository.  We have occasionally had confusion with just the small group of editors/chairs/Dom, but that is thankfully only occasional.  Adding more people is likely to make that problem occur more often.

Bernard, it's actually easy to do a pull request to someone else's pull request that they can merge in, if you want to suggest changes to their PRs.

I've actually been *more* careful over the past year to do all of my personal requests as PRs in my own branch rather than in the main repo just because it's way cleaner, even if it adds a few steps.

Dom, we may have gotten a little lazy recently with "just fixing it ourselves".  For quite a while we would do the rebasing ourselves unless, as you said, it was tricky in some way.  Perhaps we just need to take a quick look before requesting a rebase.  Then again, the more PRs we have in flight the more rebasing will be required in general.  That's just the nature of the beast.

-- dan
On Nov 26, 2015, at 5:05 AM, Adam Bergkvist wrote:

> Hi
> 
> If we don't want to give write access to a lot of people an alternative 
> approach is to use "Merging via command line" instructions from github 
> and do the edits between step 1 and 2. When pushed, the PR is 
> automatically marked as merged. That would let us to test the PR and do 
> some polishing before the PR goes in.
> 
> The drawback would be that we can't do some changes and then pass the 
> token over to the original contributor to add more stuff to the branch. 
> But I don't know if that's a big problem since we're talking about small 
> fixes before something goes in.
> 
> /Adam
> 
> On 2015-11-25 22:14, Bernard Aboba wrote:
>> I am generally supportive of this direction (having lost write access to my own PRs on occasion, and having wanted to edit/rebase other PRs but not having access to do so).
>> 
>> Is there a way for the Chairs/Editors to take some small steps in this direction (such as making it possible for us to edit each other's PRs) before expanding the scope?
>> 
>> Lately I've stopped using my own private repo and started using the github website to create branches for each PR (which at least ensures that I can edit them, but may not give enough access to others).
>> 
>> -----Original Message-----
>> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
>> Sent: Wednesday, November 25, 2015 8:48 AM
>> To: public-webrtc-editors@w3.org
>> Subject: Avoid privately-owned PRs
>> 
>> Hi,
>> 
>> As discussed separately, there are a number of cases when we require a PR submitted to go back and fix typos and bugs in their PRs before they can be merged; while it isn't unreasonable, in cases where these changes are uncontroversial, it would be better to update the pull request itself directly.
>> 
>> This is not generally possible for pull requests that are submitted from privately owned because in general, only the owner has write access to that repository.
>> 
>> One way around that limitation would be to change how we use the shared @w3c repository:
>> * instead of limiting write access to the editors, we would give write access to all the "contributors" (i.e. people from which we expect or request PR)
>> 
>> * we would ask that these contributors instead of making pull requests from their private repo would instead push their changes as branch of the @w3c repo and pull request from there
>> 
>> * that way, any of the other contributor can help fix bugs and typos in these shared branches
>> 
>> * the only drawback is that contributors could mistakenly then push changes to master and gh-pages; but arguably, that's already a risk with editors, chairs and staff contacts, and in most cases, can easily be recovered from. This should probably push us to make these branches "protected" (i.e. not deletable or force-pushable), but that is true in any case.
>> 
>> Thoughts?
>> 
>> Dom
>> 
>> 
> 
>

Received on Wednesday, 2 December 2015 19:13:57 UTC