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

On 1/10/14, 4: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.
>
> --
> /Jacob Carlborg
I tend to sway a tad in towards this opinion but I don't think it will really make that much of a difference. What is important is that we fix the issue with our release in making this leap. Either way though, the broken/confusing release process requires immediate attention. See my response to Walter.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 1/10/14, 4:33 AM, Jacob Carlborg wrote:
> On Jan 09, 2014, at 11:51 PM, Andrew Edwards <edwards.ac@gmail.com> wrote:
>
>> I am responsible for this. Request however, that this particular tag be deleted (v2.065-b1) because we're not ready. I am reading Pro Git right now because I made a number of mistakes a few weeks back and decided not to play in the live repo until I get a better grasp of how to use it.
>
> It's very easy to create a local git repository to experiment with. Don't use the public repositories for this.
>
> $ git init .
>
> The above will create a git repository in the current working directory.
>
> --
> /Jacob Carlborg
>
Got it. I'm actually doing that right now. Just suggesting that I will be hands off for a little bit until I'm certain I will not cause any more issues on the public repo.

On 10 jan 2014, at 21:50, Andrew Edwards <edwards.ac@gmail.com> wrote:

>    c. merger of pulls made against master should be suspended

I would say that the whole point of having a release branch is to be able to continue work on master as before. Or did I misunderstand something here?

-- 
/Jacob Carlborg


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

On 1/10/14 12:50 PM, Andrew Edwards wrote:
>
> Once the branch is prepared:
>      a. implementation of new features should cease

wrong, that's why there's a separation between master and a release branch.

>      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.

>      c. merge of pulls made against master should be suspended

wrong.  see a.

>      d. attention given to outstanding regressions

ideally, but volunteers spend time where they wish.

>      e. upon resolution of final regression, the tag is created and the beta built and released

correct.


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

On 1/10/14 1:36 PM, Brad Roberts wrote:
> On 1/10/14 12:50 PM, Andrew Edwards wrote:
>>
>> Once the branch is prepared:
>>      a. implementation of new features should cease
>
> wrong, that's why there's a separation between master and a release branch.

Yah, that's important, let's make sure we get that right.

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

On 1/10/2014 1:36 PM, Brad Roberts wrote:
> On 1/10/14 12:50 PM, Andrew Edwards wrote:
>>
>> Once the branch is prepared:
>>      a. implementation of new features should cease
>
> wrong, that's why there's a separation between master and a release branch.

I know that's the way it's supposed to work, but as a practical matter:

1. pulls in master mostly don't get cherry-picked into the release

2. it's fairly tedious to discover which master pulls got cherry-picked into the release, which leads to mass confusion about what is and what is not in the release

3. Sometimes cherry-picking is a bunch of tedious extra work because a fix may rely on other fixes that were not cherry-picked. Yes, this happens frequently. No, it isn't fun for me to try and untangle these things.

4. Bugzilla doesn't handle this very well, either.

5. Github doesn't handle it very well, either. Once a PR is merged, it tends to get forgotten about.

6. We don't have any paid staff we can just assign to keeping on top of this, so it gets done in a haphazard manner by whoever feels like working on it at the moment.

7. The psychological effect of having two diverging branches is everyone wants to be with the kool kids and work on exciting new features in master, not that boring, tedious, scut job of getting the previous release done.


Therefore, I suggest we:

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
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

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".

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

On 1/10/14, 4:36 PM, Brad Roberts wrote:
> On 1/10/14 12:50 PM, Andrew Edwards wrote:
>>
>> Once the branch is prepared:
>>      a. implementation of new features should cease
>
> wrong, that's why there's a separation between master and a release branch.
>
point taken
>>      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.
>
Except that _nothing_ is getting ported back to the branches. I'm still waiting on changes that have been made in master starting in early December (including regressions) to make it to the 2.065 branch. This is just not happening. Regarding multiple regressions, merging to branch and porting to master accomplishes the same thing with less confusion. Every change made in the branch will need to move forward to master, not so the other way around. The added (and more important) benefit is that the branch does not get overlooked.
>>      c. merge of pulls made against master should be suspended
>
> wrong.  see a.
I disagree here. Keep in mind that I'm discussing the first beta here. I'm also only speaking to Core Devs here: not volunteers at large. Attention can go back to master as soon as [e] (below) is done.
>
>>      d. attention given to outstanding regressions
>
> ideally, but volunteers spend time where they wish.
No one is asking anybody to volunteer on things they are not interested in. There is however an obligation to resolve issues that are impeding the release process and this is definitely one of them. If I'm to wait on all regressions to be fixed prior to starting the next release process, it will never happen. There are still regressions out there before I took on the responsibility of managing releases. Who is assigned to resolve them? When do we anticipate a resolution? If no one accepts this responsibility then I would suggest that what we've had up to this point is as good as we'll ever get.
>
>>      e. upon resolution of final regression, the tag is created and the beta built and released
>
> correct.
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

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

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.

Remember also that regressions don't stop showing up because we fixed one. We need to identify which ones will be addressed by the next release and creation of the branch does just that.


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