www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Transitioning to the new Release Process

reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
Before starting this I did come across Walter's complaint of 
issues, but feel this needs a new thread. But didn't read all 
replies.

The new process introduces a new branch called staging. This is 
_not_ used as one would first think.

staging is created/updated _after_ release. This means a delay in 
changes in master (breaking changes/new additions) and release (a 
good thing). It also means that we have to do some awkward 
delaying to get some useful changes into staging so that it is 
different from this last release.

The delay is good, we can continuously releasing betas from 
staging and fixing bugs in both staging and master for the time 
master is being developed. And master doesn't have to be perfect 
when doing a release, it is moved into staging afterwards and can 
get final touch ups there.

Maybe the next release can just be a -bugfix- regression release 
off staging?

Walter, I believe the proper way to merge changes from staging 
into master is:

$ git checkout master
$ git merge staging

Cherry pick isn't needed since all changes should be desired.
Jan 09 2013
next sibling parent reply "Rob T" <rob ucora.com> writes:
On Wednesday, 9 January 2013 at 17:12:15 UTC, Jesse Phillips 
wrote:
 The new process introduces a new branch called staging. This is 
 _not_ used as one would first think.

 staging is created/updated _after_ release. This means a delay 
 in changes in master (breaking changes/new additions) and 
 release (a good thing). It also means that we have to do some 
 awkward delaying to get some useful changes into staging so 
 that it is different from this last release.

According to the wiki, this is not what is supposed to happen, staging should have existed prior to the version branch release: --------------- version branches: Once we determine it's time to do a new release, a version branch is made by branching from the staging branch. A version branch will not receive any new features, only regression fixes. To determine to which version branch regression fixes should go, see #Regression fix. Version branches are used to support the version for an extended period of time to enable updated minor releases which fix regressions. --------------- I think what you mean, is that the 2.061 release was done improperly, and that we need to find a solution to fix whatever problems are being caused by the improper release. Correct? --rt
Jan 09 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/13 1:28 AM, mist wrote:
 Sounds like different people have different understanding of staging
 concept here and each one is doing minor tweaks to own direction. I ran
 through updated wiki and some stuff like "pull requests against staging"
 just scares me a lot.

Why is that scary? Thanks, Andrei
Jan 10 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/13 4:42 AM, Johannes Pfau wrote:
 Am Thu, 10 Jan 2013 10:28:51 +0100
 schrieb "mist"<none none.none>:

 Sounds like different people have different understanding of
 staging concept here and each one is doing minor tweaks to own
 direction. I ran through updated wiki and some stuff like "pull
 requests against staging" just scares me a lot. Someone really
 needs to step up and take this under control.

The wiki page needed to be updated though as a lot of the workflow wasn't explained. I asked many times if all contributors of the original wiki page are satisfied with the changes as I did not intend to change the concept. If you don't want bug fixes to go into staging where should they be merged to then? If we merge them into master, staging won't receive any development in between releases? Or do you propose to merge master into staging more often? If so, then what's the criteria to merge from staging to master?

My understanding was that staging is worked on only during the (short) time span from initiating a new release and finalizing that release. Andrei
Jan 10 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Wednesday, 9 January 2013 at 20:16:26 UTC, Rob T wrote:

 According to the wiki, this is not what is supposed to happen, 
 staging should have existed prior to the version branch release:

It does exist before release because it was created before the release, but we didn't have a previous release with this model. "To start the release process (This is always done after a major release has been made) merge master into staging:" http://wiki.dlang.org/Release_Process#Preparing_a_new_major_release I voiced my initial concerns about the staging branch here: http://forum.dlang.org/post/mhxudrazfbueboficosq forum.dlang.org I affirmed getting behind a plan here: http://forum.dlang.org/post/jztehgwjvrminlrmgnqq forum.dlang.org For all I care we could instead branch master into the next version branch and use that as a *period* of staging. But I like the delay, continuous betas, and clear expectations for what one will see in the next release. It gives a good period for the stabilization and getting many testing it (as they get tired of waiting for a release they grab the betas and they get some regression fixes too. But we have to get started, and not having a clear plan how to transition has caused confusion.
Jan 09 2013
prev sibling next sibling parent "mist" <none none.none> writes:
Sounds like different people have different understanding of 
staging concept here and each one is doing minor tweaks to own 
direction. I ran through updated wiki and some stuff like "pull 
requests against staging" just scares me a lot. Someone really 
needs to step up and take this under control.
Jan 10 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 10 Jan 2013 10:28:51 +0100
schrieb "mist" <none none.none>:

 Sounds like different people have different understanding of 
 staging concept here and each one is doing minor tweaks to own 
 direction. I ran through updated wiki and some stuff like "pull 
 requests against staging" just scares me a lot. Someone really 
 needs to step up and take this under control.

The wiki page needed to be updated though as a lot of the workflow wasn't explained. I asked many times if all contributors of the original wiki page are satisfied with the changes as I did not intend to change the concept. If you don't want bug fixes to go into staging where should they be merged to then? If we merge them into master, staging won't receive any development in between releases? Or do you propose to merge master into staging more often? If so, then what's the criteria to merge from staging to master?
Jan 10 2013
prev sibling next sibling parent "mist" <none none.none> writes:
I did not feel competent enough to push for my opinion, I was 
just afraid that 3 consecutive iterations of updates from 
different people with different ideas in mind will result in 
least usable combination of all 3.

But well, if you want my opinion regarding master and staging - 
master should be a development branch as it is a default pull 
request target branch in github. All feature and bugfix branches 
should be branched to master.

Staging as originally intended makes small sense with current 
long release cycle / separate beta test combo. Thus long 
forgotten proposal (sorry, can't remember original author) to 
have releases often and LTS releases once in a long period. Than 
development process looks like:

1) master replaces staging
2) short period (i.e. 1 month) is given for D project maintainers 
to check their stuff on staging and file regression bug reports. 
Those bug fix branches are either merged to both master and 
staging or merged to master and cherry-picked to staging (not 
enough git expertise here to judge what is best).
3) Once period has passed and all regression reports have been 
adressed, release is made from staging
4) Go to 1

LTS release is only different that is is made i.e. once a year, 
has separate branch and is guaranteed to receive 
backwards-compatible bug fixes to own branch from master until 
next 2 LTS are out.

------------------------

This was just straight out of my head, details may vary but there 
are several crucial points I'd really like to be addressed:
1) Release maintenance should be task of, well, maintainer. All 
public development (pull requests) should go against a single 
target branch and never stop. This is important to keep 
open-source entry barrier low for newcomers.
2) LTS is a must for serious commercial usage (and being 
completely frozen for 1 year is probably a bare minimum)
3) Release beta-testing should be as continuous as possible so 
that any D user can make his input regarding next ongoing release 
without following any mail lists and/or release schedules.
Jan 10 2013
prev sibling next sibling parent "mist" <none none.none> writes:
P.S.
This was just another opinion that has no value unless someone of 
authority starts making some clear decisions.
Jan 10 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 10 Jan 2013 14:42:40 +0100
schrieb "mist" <none none.none>:

 Staging as originally intended makes small sense with current 
 long release cycle / separate beta test combo. Thus long 
 forgotten proposal (sorry, can't remember original author) to 
 have releases often and LTS releases once in a long period. Than 
 development process looks like:

period than bug fixes.
 
 1) master replaces staging
 2) short period (i.e. 1 month) is given for D project maintainers 
 to check their stuff on staging and file regression bug reports. 
 Those bug fix branches are either merged to both master and 
 staging or merged to master and cherry-picked to staging (not 
 enough git expertise here to judge what is best).
 3) Once period has passed and all regression reports have been 
 adressed, release is made from staging
 4) Go to 1

But isn't this very similar to the current approach? The wiki page also suggests to merge master into staging. Only the time span for release preparation is different which is 8 weeks in the current proposal and always the same length as the time between 2 releases. Your approach fixes that time to 4 weeks. You say merge bug fixes to both master and staging: This is essentially what the wiki page describes: By first merging into staging those are also merged into master by merging staging into master. (Merging bug fixes to master is not possible, as we can't merge master into staging when we're in a stabilization period.) Of course we could also say merge the bugfix directly into master and staging, but this would need 2 pull requests on github. It seems easier to just merge staging into master periodically. So your approach has the same problem: As long as staging is stabilizing bug fixes must go to staging. They can additionally be pushed directly into master, but if pull requests always target master you have the same problem. (Only solution in cherry picking, but we want to avoid that)
 1) Release maintenance should be task of, well, maintainer. All 
 public development (pull requests) should go against a single 
 target branch and never stop. This is important to keep 
 open-source entry barrier low for newcomers.

Although I'd like the process to be as simple as possible for contributors it's difficult to have the same branch for all pull requests: If you wanted to get a regression fix from that branch into a release branch your only option would be cherry picking. But some people want to avoid cherry picking as much as possible, and this means pull requests have to go to different targets.
 2) LTS is a must for serious commercial usage (and being 
 completely frozen for 1 year is probably a bare minimum)

later. I don't think we have the resources to support such LTS releases right now and it's probably not that useful - D has still way too many bugs.
 3) Release beta-testing should be as continuous as possible so 
 that any D user can make his input regarding next ongoing release 
 without following any mail lists and/or release schedules.

Posting beta releases on the download page would probably be a good start.
Jan 10 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 10 January 2013 at 15:51:13 UTC, Andrei Alexandrescu 
wrote:
 My understanding was that staging is worked on only during the 
 (short) time span from initiating a new release and finalizing 
 that release.

 Andrei

I know, that is my general understanding of how staging would be used. This is a release branch in most described models. However I think that extending that to a longer period isn't bad. But it does mean maintaining 3 branches (released, staging, dev). If we only want the usual short prep period, staging should die and we just branch into a Version branch (release branch) and tag when it is released. This would not need a transition period.
Jan 10 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Thursday, 10 January 2013 at 15:51:13 UTC, Andrei Alexandrescu 
wrote:
 My understanding was that staging is worked on only during the 
 (short) time span from initiating a new release and finalizing 
 that release.

 Andrei

There are significant side effects of that approach: 1) There's no beta made available for release. While you can try really hard to claim that there is a beta, in practical terms there isn't one, because very few people will even know it is there, and even less will have the ability to test it. Even if someone managed to try it out, not enough time is available to do anything significant with it and report back the results for refinement. 2) You'll never gain a high degree of stability between releases. The reason why is because the poorly tested development copy, is the released version, and following point 1) above, it will never be sufficiently tested and refined prior to release. The results we got with the 2.061 release is what the process will give you, which is an unstable compiler that no one will want to use in a production environment unless they don't mind getting fired, in other words what was released is in fact a beta release of the unstable development branch. If our intention is to produce a stable release that is maintained, then the process needs to be designed in a way that produces one. The only way stability can happen, is if all development stops on a release branch for a sufficient period of time, ie., it enters into a maintenance mode where only critical bug fixes are introduced. We don't want to stop the clock however, there's always newer exciting things to be done, so the development must proceed, and new major releases must follow. The tricky part is to do it in a non-disruptive way, that smooths out the instability between releases, that's the purpose the beta branch servers, a middle ground between stability and instability, but it's far more than that, it can also provide the development team with crucial feed back from real-world users. We have to realize that the release process is not intended for developers, you have to consider what the users of the compiler want to see. 1) Users want to have access to a well maintained release of the compiler, where incremental upgrades contain only bug fixes up until the next major release, which will contain new features and other major improvements. 2) Some users want to have access to a reasonably stable beta release. The only reason why a user will want to try a beta version, is when the stable released version does not yet have something that they want to try out that is available in the beta, such as a new feature like UDA's. The beta should be in packaged form and available on the download page because you have to make it very easy for people to try it. How we achieve the results may not matter so much, but from what I can see, to achieve point 1), the release must come from the beta, and there must be a release branch that can receive bug fixes. To achieve point 2) which is providing a reasonably stable beta for the users to try out, there must be a beta branch. The beta branch receives only new features and bug fixes that have been fully agreed to and well thought out. Meanwhile all of the half baked new concepts are contained in the development branch (we've pegged it into master), and all the experimental stuff resides in the various scattered feature branches that only developers and high adventures are willing to try out. --rt
Jan 10 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.

On topic: well, it was somewhat discussed in the very first
thread. One pure technical issue is that github choses master as
default target for pull requests and people gonna do it wrong by
a simple mistake rather often. 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.

Come on, I am reading all new posts in D and D.announce almost
every day (for 2+ years), check most of github pull requests for
druntime and phobos on weekly basis and still have a hard day
figuring out how some stuff is supposed to be done regarding
process and intentions. Imagine some random guy who just fixed
some stuff for his project and now he is full of altruistic
intentions to provide this fix/feature to an upstream. We have
current scenario A - fork repo on github, do stuff, push "pull
request" button. And now scenario B is proposed - go to wiki,
read release process guidelines, chose branch to fork from, do
not forget to chose the same branch when doing pull request
shortly after. Minor details regarding people comfort matter a
lot when they are supposed to work for free.

On Thursday, 10 January 2013 at 15:47:30 UTC, Andrei Alexandrescu
wrote:
 On 1/10/13 1:28 AM, mist wrote:
 Sounds like different people have different understanding of 
 staging
 concept here and each one is doing minor tweaks to own 
 direction. I ran
 through updated wiki and some stuff like "pull requests 
 against staging"
 just scares me a lot.

Why is that scary? Thanks, Andrei

Jan 11 2013
prev sibling next sibling parent "mist" <none none.none> writes:
My understanding is that your understanding is somewhat different 
from initial proposal but that is where discussion has flow to 
since then and that makes me sad :)

They very reason to have staging is to have better replacement to 
beta process which simply does not work good enough currently. Is 
good to have a single branch all the time, which some obscure 
project maintainer can check from time to time to make sure his 
stuff still compiles and fire regression bug reports if needed. 
He may even have add this test to own continuous integration 
suite (I'd do this if I had a serious D project) to be notified 
when stuff goes wrong without paying any constant attention.

Attention is a key here. How many D projects are out there? How 
many of their maintainers pay close attention to newsgroup and 
read beta mail list? Compare this to being able to check your 
stuff on very next release at any moment you have time and want 
to.

I stand at the point that for open source projects release and 
development processes should care most about end users and 
developers and least - about maintainers. Maintainers should have 
perfect git and process knowledge anyway, or at some scales thing 
are doomed to be crewed (2.061 anyone?).

Thus I vote for a persistent staging branch.

 My understanding was that staging is worked on only during the 
 (short) time span from initiating a new release and finalizing 
 that release.

 Andrei

Jan 11 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Friday, 11 January 2013 at 18:03:33 UTC, mist wrote:
 My understanding is that your understanding is somewhat 
 different from initial proposal but that is where discussion 
 has flow to since then and that makes me sad :)

 They very reason to have staging is to have better replacement 
 to beta process which simply does not work good enough 
 currently. Is good to have a single branch all the time, which 
 some obscure project maintainer can check from time to time to 
 make sure his stuff still compiles and fire regression bug 
 reports if needed. He may even have add this test to own 
 continuous integration suite (I'd do this if I had a serious D 
 project) to be notified when stuff goes wrong without paying 
 any constant attention.

 Attention is a key here. How many D projects are out there? How 
 many of their maintainers pay close attention to newsgroup and 
 read beta mail list? Compare this to being able to check your 
 stuff on very next release at any moment you have time and want 
 to.

 I stand at the point that for open source projects release and 
 development processes should care most about end users and 
 developers and least - about maintainers. Maintainers should 
 have perfect git and process knowledge anyway, or at some 
 scales thing are doomed to be crewed (2.061 anyone?).

 Thus I vote for a persistent staging branch.

 My understanding was that staging is worked on only during the 
 (short) time span from initiating a new release and finalizing 
 that release.

 Andrei


I don't understand the problem you seem to see in the process. I've been away from the PC so couldn't respond earlier but I did manage to read most of the wiki page and I think Johnathan did a very good job explaining the various concepts. The only thing missing IMO is CI: It's already agreed that master is the development channel in the proposed process. The next logical step would be to generate nightly builds off of that branch. The staging branch is the "beta" channel - and also makes sense to have a periodical beta build. This depends on the release time span but something like fortnight or monthly beta builds makes sense to me. the additional manual builds described on the wiki on staging or even before an official release on the version branch will be something like RCs. 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.
Jan 12 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 10 Jan 2013 20:36:40 +0100
schrieb "Jesse Phillips" <Jessekphillips+D gmail.com>:

[...]
 
 However I think that extending that to a longer period isn't bad. 
 But it does mean maintaining 3 branches (released, staging, dev). 
 If we only want the usual short prep period, staging should die 
 and we just branch into a Version branch (release branch) and tag 
 when it is released. This would not need a transition period.

Staging has also 2 other small benefits: It is a central 'beta branch', you can check out 'staging' any time and be sure this is going to be the next release. You'll always have all the features that are in the next release and the only updates till the next release will be bug fixes. This is an interesting point imho. And then there is the benefit that you'll have a central target for bug fix pull requests: Without staging, bug fixes usually go into master. But when a release branch is created, bug fixes suddenly have to go into that release branch. Then after the release, bug fixes have to go to master again and only regression fixes can go into the release branch. This is kinda annoying as it does not only mean the target branch for pull requests on github has to be changed a lot, you might also have to rebase the bugfix on the other branch. With staging you always target staging for bug fixes. They can be merged at any point in time.
Jan 12 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Jan 12 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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.
 
 On topic: well, it was somewhat discussed in the very first
 thread. One pure technical issue is that github choses master as
 default target for pull requests and people gonna do it wrong by
 a simple mistake rather often.

- the only difference with the approach described on the wiki page is that the bug fix will be delayed by one release if it's merge into master instead of staging.
 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.

regression fix -> version branch bug fix -> staging enhancement -> master The benefits have already been stated in other posts.
 
 Come on, I am reading all new posts in D and D.announce almost
 every day (for 2+ years), check most of github pull requests for
 druntime and phobos on weekly basis and still have a hard day
 figuring out how some stuff is supposed to be done regarding
 process and intentions. Imagine some random guy who just fixed
 some stuff for his project and now he is full of altruistic
 intentions to provide this fix/feature to an upstream. We have
 current scenario A - fork repo on github, do stuff, push "pull
 request" button. And now scenario B is proposed - go to wiki,
 read release process guidelines, chose branch to fork from, do
 not forget to chose the same branch when doing pull request
 shortly after. Minor details regarding people comfort matter a
 lot when they are supposed to work for free.

It's always possible for a maintainer to get the changes from the pull request into their personal repo, rebase on the correct branch, reopen. And it's not that bad if a request goes to master accidentally. Regression fixes have to go to version branches anyway, you can't avoid this without cherry-picking. But newbies don't do regression fixes anyway. Separating between staging and master then has the nice benefit of a more stable "beta" branch and a fast moving development branch.
Jan 12 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
On Wednesday, 9 January 2013 at 17:12:15 UTC, Jesse Phillips 
wrote:
 Before starting this I did come across Walter's complaint of 
 issues, but feel this needs a new thread. But didn't read all 
 replies.

 The new process introduces a new branch called staging. This is 
 _not_ used as one would first think.

 staging is created/updated _after_ release. This means a delay 
 in changes in master (breaking changes/new additions) and 
 release (a good thing). It also means that we have to do some 
 awkward delaying to get some useful changes into staging so 
 that it is different from this last release.

Since we don't have much opposition here for the staging process I will make my suggestion for this transition. Since std.uni is up for review, lets plan that upon inclusion we move master into staging. This will be the next release as defined in our process. When another group of changes is considered ready we can make the release and update staging. We could choose other changes, but I think this will be a good arbitrary point to make the transition (and not end up with an "empty" release).
Jan 13 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.

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.
Jan 14 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
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.
Jan 15 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
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.

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.
Jan 15 2013
prev sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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.
Jan 15 2013