Transitioning to the new Release Process

[Johannes Pfau]

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.