On 1/10/14 3:02 PM, Andrew Edwards wrote:
> On 1/10/14, 5:44 PM, Andrei Alexandrescu wrote:
>> On 1/10/14 2:37 PM, Walter Bright wrote:
>>> 1. delay forming the branch as long as possible, at least up to the
>>> point where the regression list is minimized and we're ready to go to
>>> data.
>>>
>>> 2. work on future features is not really delayed, the pull requests can
>>> still be made
>>
>> I agree. Essentially we should create the branch when we have the
>> feeling "well, what's in master right now makes for a good release
>> candidate".
>>
> I disagree on the "feeling" thing. That's the way it's been done all
> along and it does not prove to be very reliable. Schedules may become
> delayed for any number of reasons but we should make a best effort to
> stick to them as close as possible. I suggest that if we merely branch
> when we feel like it then the schedule will never be adhered to and we
> will slowly degrade back to our original state.

Fine, too, so long as you realize it's a lot more work for you :o).

Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 01/10/2014 10:36 PM, Brad Roberts wrote:
>>      b. pull request for fixes should be made against and merged with
>> the branch
>
> wrong, fixes should _always_ be made on master first and then back
> ported to branches that might require them.  Consider the case of a
> regression that exists in multiple release branches.

Wouldn't the release branch be merged back into master?

-- 
Mike Wey
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Sat, Jan 11, 2014 at 4:09 AM, Mike Wey <mike@mikewey.eu> wrote:

> On 01/10/2014 10:36 PM, Brad Roberts wrote:
>
>>      b. pull request for fixes should be made against and merged with
>>> the branch
>>>
>>
>> wrong, fixes should _always_ be made on master first and then back ported to branches that might require them.  Consider the case of a regression that exists in multiple release branches.
>>
>
> Wouldn't the release branch be merged back into master?
>
> --
> Mike Wey
>

This is the way I see it. The easiest way to fix a bug and merge it into other branches that need it is to fix it on the oldest branch it exists. To use the latest branch, as Walter mentions, brings in many other changes which may or may not be relevant to the issue. This can be as simple as fixing indentation (which wouldn't actually cause compilation error).

When merging from master to an older branch each needed change needs to be located during the cherry-pick, if you start with the older branch then it is just merge all commits, and since this is git we can do this any number of times. Cherry-picking is great, but I think it is stupid to rely on it as "standard."

-- 
Jesse Phillips

On 1/10/2014 1:31 AM, Jacob Carlborg wrote:
> On Jan 10, 2014, at 01:24 AM, Walter Bright <walter@digitalmars.com> wrote:
>
>> Rather than trying to fix the 2.065 branch, perhaps we should simply abandon it
>> and go with 2.066?
>
> Absolutely not. We already have a very confusing release process, don't making more confusing by skipping version numbers.


I don't see what's confusing about it. Numbers don't have to be sequential, they only have to be increasing.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

I emailed you directly earlier but I'd like to point it out here that I think the release process is far, far too complicated. The people who designed it obviously worked hard on it and it there is definitely value in what they designed but in practice there are clearly a lot of problems following it (as this email chain shows). One problem is that with the current approach it's impossible to do a bugfix only release without freezing all feature development (i.e. cherry-picking is forbidden but all commits must still go to master) which is unacceptable and was the original reason why a Release Process was created.

I put together a very simplified approach that results in only a single person, the Release Manager, have to learn it and do any work and only during a small feature freeze/beta window. Everyone else just makes pull requests to master. Things can be merged regardless of whether a release is in progress or not.

http://wiki.dlang.org/Simplified_Release_Process_Proposal


On Fri, Jan 10, 2014 at 1:50 PM, Andrew Edwards <edwards.ac@gmail.com>wrote:

> On 1/9/14, 7:24 PM, Walter Bright wrote:
>
>> Rather than trying to fix the 2.065 branch, perhaps we should simply abandon it and go with 2.066?
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
> I'm not against that. There are a couple of commits that I think were injected directly into the 2.065 branch that may need to be merged into master but other than that I don't see any issues. As Martin alluded to though, it is necessary to provide more attention to the fixes--specifically regressions--necessary to the getting the release out the door. No doubt they would be simpler to identify if they were air-marked for that branch instead of master, but that requires everyone to embrace the methodology outlined in [1].
>
> Once the branch is prepared:
>     a. implementation of new features should cease
>     b. pull request for fixes should be made against and merged with the
> branch
>     c. merger of pulls made against master should be suspended
>     d. attention given to outstanding regressions
>     e. upon resolution of final regression, the tag is created and the
> beta built and released
>
> This would make for a much smoother release process than what we have going on right now. It's unacceptable to wait 20+ days for to merge pulls air-marked for the current release cycle, which is what's happening.
>
> 1) http://wiki.dlang.org/Development_and_Release_Process
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

Perhaps you guys should read "Git Branches Considered Harmful" [1] in the
ZeroMQ C4 documentation [2]. They have similar problems to D where there is
no easy way to split up responsibility across the source code.
Basically they say branches should only be internal. To make a release one
should fork the repo. Its better said in their docs though. It reads a bit
like an RFC.

If you did that then build master could create the release forks.

​
[1] http://zguide.zeromq.org/page:chapter6#Git-Branches-Considered-Harmful
[2] http://zguide.zeromq.org/page:chapter6#The-MQ-Process-C<http://zguide.zeromq.org/page:chapter6>

On Mon, Jan 13, 2014 at 7:10 AM, Brad Anderson <eco@gnuk.net> wrote:
> One problem is that with the
> current approach it's impossible to do a bugfix only release without
> freezing all feature development (i.e. cherry-picking is forbidden but all
> commits must still go to master) which is unacceptable and was the original
> reason why a Release Process was created.

What are you referring to as the "current approach" here? The way things have been done in the past, or the proposal at http://wiki.dlang.org/Release_Process?

I'm pretty sure the latter actually addresses this problem as well: A fix that addresses regression or critical bug is merged into the oldest release branch it should end up on, and then merged subsequently into all newer release branches and master (http://wiki.dlang.org/Release_Process#Regression_fix).

David
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Mon, Jan 13, 2014 at 7:10 AM, Brad Anderson <eco@gnuk.net> wrote:
> http://wiki.dlang.org/Simplified_Release_Process_Proposal

Even though I'm not sure whether this proposal is the best choice, let me point out that it gets one point very right, compared to the current state: After a release is created, the branch needs to be merged back into master. Otherwise, people just tracking the release tags (like we tend to do for the ldc druntime/Phobos repositories) will usually get a slew of conflicts due to commits cherry-picked onto the release branch or conflicting release-only changes.

Doing this at the point of the release has the advantage that the release manager is the one who knows what went where for what reasons, and that they still have all the details in their working memory.

I suspect that liberal use of cherry-picking will make this process a bit more annoying than necessary, but it could be that the simplification of the process indeed outweighs this extra bit of effort.

David
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Mon, Jan 13, 2014 at 5:38 PM, David Nadlinger <code@klickverbot.at>wrote:
>
> I suspect that liberal use of cherry-picking will make this process a bit more annoying than necessary, but it could be that the simplification of the process indeed outweighs this extra bit of effort.
>

I feel it rather unjust to put that extra effort on Andrew simply because we can't self-organize to conform existing rules but right now it just does not work :(

However I think resolution of such conflicts can be made very straightforward and even made automatic via simple script (by providing list of identical commit pairs to script and making it skip one of those). Worth investigating.

I must admit, I didn't read carefully enough in my haste.  That would indeed work.


On Mon, Jan 13, 2014 at 9:20 AM, David Nadlinger <code@klickverbot.at>wrote:

> On Mon, Jan 13, 2014 at 7:10 AM, Brad Anderson <eco@gnuk.net> wrote:
> > One problem is that with the
> > current approach it's impossible to do a bugfix only release without
> > freezing all feature development (i.e. cherry-picking is forbidden but
> all
> > commits must still go to master) which is unacceptable and was the
> original
> > reason why a Release Process was created.
>
> What are you referring to as the "current approach" here? The way things have been done in the past, or the proposal at http://wiki.dlang.org/Release_Process?
>
> I'm pretty sure the latter actually addresses this problem as well: A fix that addresses regression or critical bug is merged into the oldest release branch it should end up on, and then merged subsequently into all newer release branches and master (http://wiki.dlang.org/Release_Process#Regression_fix).
>
> David
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>