On Saturday, 12 January 2013 at 12:20:21 UTC, Johannes Pfau wrote:
> Am Sat, 12 Jan 2013 09:22:27 +0100
> schrieb "foobar" <foo@bar.com>:
>
>> [...]
>> 
>> Regarding pull requests targeting master, the current model *is* geared around that. Most contributions _should_ go to master (aka devel) and go through the full process. pull-requests for staging are meant for fixing regressions and critical bugs only, where there is _higher urgency_ for the fix that justifies the short-cut. Regular "bug fixes" should simply go through the regular process and will be released in the _next_ release.
>
> I also think targeting staging for some pull requests is not that bad.
> In the end it's not that bad if a pull request was accidentally merged
> into master instead of staging. It just means that it'll take more time
> for the fix to appear in a release (It'll be delayed by one release),
> but it won't mess anything up.
>
> Regarding where "most" requests go: This also depends on the project. I
> guess for phobos most requests are enhancements/new features and would
> go to master. For druntime it's mostly bugfixes, so probably more
> requests target staging. And for the dmd almost everything is a bug fix
> and could target staging.
>
> The wiki currently says all bug fixes should go to staging. This is a
> concession to D's rapid development. But again, it's not that important
> where the pull requests go. We should try to make breaking changes in
> master and have only "harmless" changes in staging, but the exact
> decision is always up to the contributor & maintainers.
>
> But those 'minor' tweaks such as defining what exactly is merged to
> master and what to staging can always be made later on.

Yea, I agree with the above. I'll just add two additional points:
1. Perhaps it makes sense to have more "strict" rules for new contributors. So Walter, Don, etc could merge straight to /staging/ but someone new will need to have a few pull requests accepted to master before they are allowed the same privilege.
2. Regarding DMD - it depends on the definition of what a "bug fix" is. There are many "bugs" regarding conflicts with the spec or unimplemented features. Even though these are listed as "bugs" on bugzilla they are really enhancements or new features and probably should go through an extra cycle via merging to /master/.
For example, An implementation of "auto ref" for regular functions should really be treated as a new feature (and have a full design cycle) even though it's formally listed as a bug.

On Monday, 14 January 2013 at 10:33:56 UTC, mist wrote:
> On Saturday, 12 January 2013 at 12:30:05 UTC, Johannes Pfau wrote:
>> Am Fri, 11 Jan 2013 18:54:12 +0100
>> schrieb "mist" <none@none.none>:
>>
>>> Short comment about cherry pick - it is only bad in sense that it
>>> creates separate untrackable commit with same content, which may
>>> easily result in merging issues. If there is only one-way
>>> direction for commit transitioning ( stuff goes from master to
>>> staging and LTS and never goes back ) there is nothing inherently
>>> bad about cherry pick.
>>
>> Having multiple commit ids for the same commit is also annoying. For
>> example if someone bisected a regression and you want to revert a commit
>> you have to figure out the commit id of the cherry picked commits.
>>
>
> AFAIK reverts are content-based, so knowing any one commit id is enough. It is annoying mostly when comparison happens between two branches with those commits.
>
>>> Much more important point is that
>>> it complicates development process for newcomers without any
>>> reasonable benefit. And if we still gonna push for success as an
>>> open-source project, being easy understandable by an outsider is
>>> as important as a clear release process.
>> The rule is quite simple and easy to understand though:
>> regression fix -> version branch
>> bug fix -> staging
>> enhancement -> master
>
> Ye, it is easy.. except you need to actually check out wiki page to be aware about it. At the very least we need relevant excerpts for outer devs separated to one small wiki page and set links to this page in github marked with big "NB:".
>
> I don't have a reason to argue about the rest.

The default is /master/ so any new dev unfamiliar with the process will just get his stuff delayed by one release which provides extra safety if you think about it. There is no _need_ to read the wiki as the process will work just fine without it. it'll just default too the longer, safer option.
I really see no point in arguing this "it complicates the process" point any further.

On Tuesday, 15 January 2013 at 13:58:59 UTC, foobar wrote:
> Yea, I agree with the above. I'll just add two additional points:
> 1. Perhaps it makes sense to have more "strict" rules for new contributors. So Walter, Don, etc could merge straight to /staging/ but someone new will need to have a few pull requests accepted to master before they are allowed the same privilege.

I see no need for this, pull requests get reviewed and new contributors are just untrusted in quality and get the same review as old untrusted contributors.

Remember, just because a pull request comes in on staging or master does not mean it must be applied to those branches, you can apply it to any and close commenting where it was pulled to.

Since staging/version can be pulled into master and not the other way around it is easiest to create the fix against that which is oldest then apply it to new code. Since Git knows all parent commits merging is generally simple.