On 06/19/2017 05:37 PM, Sean Whitton wrote: > On Mon, Jun 19, 2017 at 08:56:14AM -0400, Jeremy Bicha wrote: >> On Mon, Jun 19, 2017 at 5:18 AM, Sean Whitton <spwhit...@spwhitton.name> >> wrote: >>> Someone might contribute a fix in the form of a PR, and an uploader of >>> the package might review that fix and determine that it should be >>> merged. They then look at the master branch and decide that it should >>> not go into the next upload, for whatever reason. So they can merge the >>> PR to next/sid. >> >> Respectfully, why? > > There are various situations in which this could come up. > > A package might have multiple uploaders, with one or two of them working > on a big, potentially disruptive upload. A third uploader, not involved > in the current work, might want to review and merge uploadable changes, > without interfering with the work going on in the master branch. They > can put them on the next/foo branch.
But that doesn't need a separate area to push this with special restrictions for who can push there: this can just be done into a separate branch in the repository by the people who already have access to said repository. And from a maintainer point of view: it's far simpler for me to simply do a push to the actual packaging repository of a new branch than to push to a new remote specifically created for this. If you want to standardize this a bit, why not update DEP14 then to include recommendations for how these kinds of branches should be named? Even though I do think this is going to be a rather rare situation, I can see the merit of having a recommended convention for this. But that would fit far better into DEP14 IMHO. But I still fail to see any advantage of the technical solution you suggested in the start of the thread, with all the permission checks and so on. Regards, Christian
