View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2013
Transitioning to the new Release Process
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.
January 09, 2013
Re: Transitioning to the new Release Process
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
January 10, 2013
Re: Transitioning to the new Release Process
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.
January 10, 2013
Re: Transitioning to the new Release Process
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.
January 10, 2013
Re: Transitioning to the new Release Process
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?
January 10, 2013
Re: Transitioning to the new Release Process
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.
January 10, 2013
Re: Transitioning to the new Release Process
P.S.
This was just another opinion that has no value unless someone of 
authority starts making some clear decisions.
January 10, 2013
Re: Transitioning to the new Release Process
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.
January 10, 2013
Re: Transitioning to the new Release Process
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
January 10, 2013
Re: Transitioning to the new Release Process
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
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home