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.

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

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.

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.

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?

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.

P.S.
This was just another opinion that has no value unless someone of authority starts making some clear decisions.

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:
With the current approach features / enhancement have a longer testing 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)
That might be right, but we can always add those real LTS releases 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.

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

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