On Monday, June 19, 2017 04:37:12 PM Sean Whitton wrote: > Hello Jeremy, > > 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. > > Alternatively, someone might be burnt out by their work on the master > branch. They want to put aside the next upload for a while, and review > some other fixes that have been submitted. Having a next/foo branch to > which they can commit these reviewed changes permits them to properly > step away from the master branch, relieving them of the need to think > hard about which changes can be safely combined with the upcoming > upload. > > > And why does that unusual workflow need a DEP? > > To reserve the next/foo namespace for this purpose.
I'm sorry, but this is sounding more and more like a solution in search of a problem. Are there actual problems that actual maintainers are having right now that this solves? Scott K
signature.asc
Description: This is a digitally signed message part.
