Transitioning to the new Release Process

[foobar]

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 at 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.