On 1/23/14 2:17 PM, Brad Anderson wrote:
On Thu, Jan 23, 2014 at 2:55 PM, Andrew Edwards <[email protected] 
<mailto:[email protected]>>
wrote:

    On 1/23/14, 2:01 PM, Walter Bright wrote:

        I agree, I don't know what's wrong with what we had before:

        1. All pull requests get merged to master
        2. Create 2.065 branch
        3. Cherry-pick from master to 2.065 as required
        4. Tag 2.065.whatever as releases get done on that branch

        Easy, simple. All these other procedures seem like massive 
over-engineering to me.

    Good to go... I for one did not see either of you weigh in on the proposal 
when Brad Roberts


Brad Anderson :P

    made it
    
(http://forum.dlang.org/post/__CAFU1Uzpm4DBADOxMjcJ_Guj1=__T8BQ4nPb5OEbADNbUQDD2ijuQ@__mail.gmail.com
    
<http://forum.dlang.org/post/CAFU1Uzpm4DBADOxMjcJ_Guj1=t8bq4npb5oebadnbuqdd2i...@mail.gmail.com>).
    I decided to use it because, compared to the alternative of trying to 
convince volunteers to do
    something they do not want to, it would be much simpler for me to follow 
this scheme.


I wish I would have thought to email Brad directly (sorry, Brad) to make sure 
he saw it and could
weigh in. Especially since apart from you he's really the only other person 
that needs to change
anything to adopt this workflow.


    To me there is no difference between the two processes, except the "we've 
always done it this
    way syndrome". Fixes are generated from release tags into a hotfix branch. 
Once the fix is
    released, we merge it back into master, remove the branch and move on. I am 
preparing both
    releases and hotpicks so I don't see any extra work being generated for the 
devs.

    The only chance I see on your parts is the need to change the tester 
scripts to point search for
    and test "hotfix" and "release" branches if they exist. I'm not the person 
doing that so I might
    have an overly simplified view of your processes but I really don't see the 
big deal.


If Brad Roberts decides it's too hard for whatever reason we should be able to 
just change the
workflow over to use a versioned branch name and dropping the step where the 
branch is deleted. Then
the hotfix process would just checkout the versioned branch (and skip the 
delete as well). I like
the tag and delete method better but we can't sacrifice the autotester for that.

The problem is that as specified, _every_ fix requires also setting up builds in the auto-tester (regardless of who does it). That should be once per maintained version. Deleting and recreating is a waste of everyone's time.

It's not just me that's affected. Anyone who wants to test releases as they're being built has to carefully track what branch to use when, which is tedious and a waste of time.

Also, what if we decide to patch two past releases, does that happen serially, using the release branch name for each of the versions one at a time? Also stupid and a waste of time.

Should I continue or is it obvious now?

_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Reply via email to