Am Sat, 12 Jan 2013 09:22:27 +0100 schrieb "foobar" <f...@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.
