I see no simplification in calling release branch "release" over using versioned name. Merging it back and deleting is right thing to do but there is a benefit in keeping names unambiguous in terms of pure communication.

We have yet to read Andrew feedback about how cumbersome will be resolving conflicts upon branch merge to master with such approach. I will reserve my judgement until then ;)


On Thu, Jan 23, 2014 at 10:51 PM, Михаил Страшун <me@dicebot.lv> wrote:

> I see no simplification in calling release branch "release" over using versioned name. Merging it back and deleting is right thing to do but there is a benefit in keeping names unambiguous in terms of pure communication.
>
> We have yet to read Andrew feedback about how cumbersome will be resolving conflicts upon branch merge to master with such approach. I will reserve my judgement until then ;)
>
>
> On Thu, Jan 23, 2014 at 9:24 PM, Andrew Edwards <edwards.ac@gmail.com>wrote:
>
>> On 1/23/14, 1:10 PM, Brad Roberts wrote:
>>
>>> Yes it did. Once 2.065 is released, the branch will be merged back into master and then deleted.
>>>
>>>> When it's time to prepare 2.066, a new release branch will be created.
>>>> See
>>>> http://wiki.dlang.org/Simplified_Release_Process_Proposal for
>>>> additional information.
>>>>
>>>
>>> I don't know who to be mad at here, but this is getting !@#$@@#$ing stupid.
>>>
>> I've never had a problem taking responsibility for the decisions I make so you can be mad at me if it makes you feel better.
>>
>>  Per-release branches were working fine.  They make it easy to keep
>>> adding fixes to after release. They're simple.  They're easy to track. Etc etc.  They're tried and true for oh so many projects.
>>>
>> I fail to see how "release" makes it many more difficult but I will concede that keeping the branch around does simplify the process of adding fixes after release.
>>
>>  Sigh, how many more ways is this release going to suck?
>>>
>>>  I'll reserve my opinion here!
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
>

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 made it (http://forum.dlang.org/post/CAFU1Uzpm4DBADOxMjcJ_Guj1=T8BQ4nPb5OEbADNbUQDD2ijuQ@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.

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.

Regards,
Andrew

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

On Thu, Jan 23, 2014 at 2:53 PM, Михаил Страшун <public@dicebot.lv> wrote:

> I see no simplification in calling release branch "release" over using versioned name. Merging it back and deleting is right thing to do but there is a benefit in keeping names unambiguous in terms of pure communication.
>
> We have yet to read Andrew feedback about how cumbersome will be resolving conflicts upon branch merge to master with such approach. I will reserve my judgement until then ;)
>
>
>
The naming isn't really part of the simplification.  I just used "release" because it's what I'm familiar with (because it's part of Git Flow[1] which I use regularly).  What it's called doesn't matter too much to me (I can't speak for Andrew though).

The simplification comes mostly from making one person responsible for the release branch instead of trying to get everyone to follow the process. This makes Andrew's job one of herding commits rather than herding people (the former is significantly easier in my experience).

I do think deleting the release branch when the release is done keeps things simpler and much more tidy but if that's going to cause big problems for the AutoTester that may not be worth it since the AutoTester is absolutely essential.

1. http://nvie.com/posts/a-successful-git-branching-model/

On Thu, Jan 23, 2014 at 2:55 PM, Andrew Edwards <edwards.ac@gmail.com>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). 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.

Brad Roberts, el 23 de January a las 10:10 me escribiste:
> On 1/23/14 9:50 AM, Andrew Edwards wrote:
> >On 1/23/14, 12:29 PM, Brad Roberts wrote:
> >>When did the beta branch switch from '2.065' to 'release' and why? What's going to happen post 2.065 when it's time for 2.066?  And when 2.065 needs a critical bug fix release?
> >>
> >Yes it did. Once 2.065 is released, the branch will be merged back into master and then deleted. When it's time to prepare 2.066, a new release branch will be created. See http://wiki.dlang.org/Simplified_Release_Process_Proposal for additional information.
> 
> I don't know who to be mad at here, but this is getting !@#$@@#$ing stupid.
> 
> Per-release branches were working fine.  They make it easy to keep adding fixes to after release. They're simple.  They're easy to track.  Etc etc.  They're tried and true for oh so many projects.
> 
> Sigh, how many more ways is this release going to suck?

+1

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
The biggest lie you can tell yourself is
When I get what I want I will be happy
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Brad Anderson, el 23 de January a las 15:07 me escribiste:
> On Thu, Jan 23, 2014 at 2:53 PM, Михаил Страшун <public@dicebot.lv> wrote:
> 
> > I see no simplification in calling release branch "release" over using versioned name. Merging it back and deleting is right thing to do but there is a benefit in keeping names unambiguous in terms of pure communication.
> >
> > We have yet to read Andrew feedback about how cumbersome will be resolving conflicts upon branch merge to master with such approach. I will reserve my judgement until then ;)
> >
> >
> >
> The naming isn't really part of the simplification.  I just used "release" because it's what I'm familiar with (because it's part of Git Flow[1] which I use regularly).  What it's called doesn't matter too much to me (I can't speak for Andrew though).
> 
> The simplification comes mostly from making one person responsible for the release branch instead of trying to get everyone to follow the process. This makes Andrew's job one of herding commits rather than herding people (the former is significantly easier in my experience).
> 
> I do think deleting the release branch when the release is done keeps things simpler and much more tidy but if that's going to cause big problems for the AutoTester that may not be worth it since the AutoTester is absolutely essential.

Is not only the auto-tester, using the branch name as the version you are releasing is self-documenting, you keep that branch and keep adding hotfixes while it's in the maintenance period. The process is very clear. I agree about having a release manager in charge of porting fixes back to the release branch (or stable branch once is released), but naming it release *and then deleting it when is released* makes everything very confusing!

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El amor es como una reina ortopédica.
	-- Poroto
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 1/23/14 2:17 PM, Brad Anderson wrote:
> On Thu, Jan 23, 2014 at 2:55 PM, Andrew Edwards <edwards.ac@gmail.com <mailto:edwards.ac@gmail.com>>
> 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=T8BQ4nPb5OEbADNbUQDD2ijuQ@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
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Thu, Jan 23, 2014 at 9:03 PM, Brad Roberts <braddr@puremagic.com> wrote:

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

OK, makes sense in the context of the autotester since it requires specifying the branches to test in `server/add/github-post.ghtml` (if I'm understanding how it works properly). I was thinking it might be as easy as just having the autotester test every branch on D-P-L (or just release and hotfix only if they are present). It doesn't look like how it works is very adaptable to that type of setup though.


> 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.
>
>
They checkout `release` if there is an upcoming release, otherwise a tag.
 I don't see any difference here other than typing `git checkout release`
instead of `git checkout 2.065`.


> 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.
>
>
It seems incredibly unlikely this would ever happen.  Like I said though, we can call the branches whatever and not delete them if that makes it easier for you. This aspect isn't important to how it all works.

Should I continue or is it obvious now?


I don't understand why you are always so hostile in your correspondences.

The branch will be renamed tonight in preparation for building beta 2. I will make this change start building beta 2 at 10:00PM EST (UTC -5) so please ensure the auto tester is not using the release branch in order prevent any complications when it is renamed. Also just to verify that I am not causing any additional issues, the tags (aka version numbers) for the release will be as follows:

     2.65.0-b2

Obviously, this is another chance but mandatory to resolve issues with upgrading from installer packages on FreeBSD and Debian OSes.

Following are the changes I've cherry-picked into the release branch since beta 1.

     DMD
[REG2.061] Issue 11980 - startaddress pragma broken (pull request #3142)
     Issue 11974 - ICE(cast.c) Segfault with invalid assignment (pull
request #3141)
[REG2.065a] Issue 11966 - inout(const(char))[] doesn't convert to
inout(char)[] (pull request #3138)
     fix Issue 11956 - dmd doesn't lookup /etc/dmd.conf (pull request #3128)
Issue 11968 - ICE(expression.c) Crash when deleting __FILE__ (pull
request #3139)
     Issue 11944 - ICE(expression.c) Assertion `f' failed. (pull request
#3125)
fix Issue 11922 - [REG2.065a] ICE on nonexistent identifier in templated
auto method (pull request #3094)
[REG2.065a] Issue 11924 - inout Variadic Template Parameters (pull
request #3097)
[REG2.065a] Issue 11896 - isVirtualMethod related GitHub HEAD regression
(pull request #3104)
[REG2.065a] Issue 11930 - Alias this not considered in is(T unused: U)
matching (pull request #3105)
[REG2.065a] Issue 11931 - Linkers "Symbol Undefined" again with dmd HEAD
when -g specified (pull request #3107)
[REG2.065a] Issue 11941 - Errors when appending to aggregate member
array in CTFE (pull request #3112)
[REG2.065a] Issue 11967 - ICE(parse.c) Parser crash (pull request #3137)
[REG2.064] Issue 11965 - Segfault on garbage (pull request #3136)
[REG2.065a] Issue 11963 - ICE(parse.c) Parser crash (pull request #3135)

     Druntime
     None

     Phobos
     Remove duplicate ArchiveMember.madeVersion() property.

     Installer
Build the installer GUI for D2 on OS X (pull request #44)
add "dustmite" binary on deb/rpm packages (pull request #43)
don't zip .git* and .DS_Store files (pull request #42)
fix expanding zip files created on Windows (pull request #41)
     cleanup leftover from merge conflict (pull request #40)

     dlang.org
fix chmgen after renaming phobos.html => index.htm (pull request #480)
Revert changelog.dd encoding to UTF-8 (pull request #478)
     Changelog: add notes about std.uni.byGrapheme and std.range.only
(pull request #477)
     2.065 changelog (pull request #476)

     tools
     None

If important you are expected to be included are not on the list, please identify them so I can adjust accordingly.


On 1/23/14, 11:03 PM, Brad Roberts wrote:
> On 1/23/14 2:17 PM, Brad Anderson wrote:
>> On Thu, Jan 23, 2014 at 2:55 PM, Andrew Edwards <edwards.ac@gmail.com
>> <mailto:edwards.ac@gmail.com>>
>> 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=T8BQ4nPb5OEbADNbUQDD2ijuQ@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
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

I would really like https://github.com/D-Programming-Language/dmd/pull/3061to go in this release.

It's not a regression, but it's a nasty wrong-code bug and blocks ddmd on linux64.

Does it seem reasonable to anyone?



On Sat, Jan 25, 2014 at 12:47 AM, Andrew Edwards <edwards.ac@gmail.com>wrote:

>  The branch will be renamed tonight in preparation for building beta 2. I
> will make this change start building beta 2 at 10:00PM EST (UTC -5) so
> please ensure the auto tester is not using the release branch in order
> prevent any complications when it is renamed. Also just to verify that I am
> not causing any additional issues, the tags (aka version numbers) for the
> release will be as follows:
>
>     2.65.0-b2
>
> Obviously, this is another chance but mandatory to resolve issues with upgrading from installer packages on FreeBSD and Debian OSes.
>
> Following are the changes I've cherry-picked into the release branch since beta 1.
>
>     DMD
>     [REG2.061] Issue 11980 - startaddress pragma broken (pull request
> #3142)
>     Issue 11974 - ICE(cast.c) Segfault with invalid assignment (pull
> request #3141)
>     [REG2.065a] Issue 11966 - inout(const(char))[] doesn't convert to
> inout(char)[] (pull request #3138)
>     fix Issue 11956 - dmd doesn't lookup /etc/dmd.conf (pull request #3128)
>     Issue 11968 - ICE(expression.c) Crash when deleting __FILE__ (pull
> request #3139)
>     Issue 11944 - ICE(expression.c) Assertion `f' failed. (pull request
> #3125)
>     fix Issue 11922 - [REG2.065a] ICE on nonexistent identifier in
> templated auto method (pull request #3094)
>     [REG2.065a] Issue 11924 - inout Variadic Template Parameters (pull
> request #3097)
>     [REG2.065a] Issue 11896 - isVirtualMethod related GitHub HEAD
> regression (pull request #3104)
>      [REG2.065a] Issue 11930 - Alias this not considered in is(T unused:
> U) matching (pull request #3105)
>      [REG2.065a] Issue 11931 - Linkers "Symbol Undefined" again with dmd
> HEAD when -g specified (pull request #3107)
>      [REG2.065a] Issue 11941 - Errors when appending to aggregate member
> array in CTFE (pull request #3112)
>      [REG2.065a] Issue 11967 - ICE(parse.c) Parser crash (pull request
> #3137)
>      [REG2.064] Issue 11965 - Segfault on garbage (pull request #3136)
>      [REG2.065a] Issue 11963 - ICE(parse.c) Parser crash (pull request
> #3135)
>
>     Druntime
>     None
>
>     Phobos
>     Remove duplicate ArchiveMember.madeVersion() property.
>
>     Installer
>      Build the installer GUI for D2 on OS X (pull request #44)
>      add "dustmite" binary on deb/rpm packages (pull request #43)
>      don't zip .git* and .DS_Store files (pull request #42)
>      fix expanding zip files created on Windows (pull request #41)
>     cleanup leftover from merge conflict (pull request #40)
>
>     dlang.org
>      fix chmgen after renaming phobos.html => index.htm (pull request #480)
>      Revert changelog.dd encoding to UTF-8 (pull request #478)
>     Changelog: add notes about std.uni.byGrapheme and std.range.only (pull
> request #477)
>     2.065 changelog (pull request #476)
>
>     tools
>     None
>
> If important you are expected to be included are not on the list, please identify them so I can adjust accordingly.
>
>
>
> On 1/23/14, 11:03 PM, Brad Roberts wrote:
>
> On 1/23/14 2:17 PM, Brad Anderson wrote:
>
> On Thu, Jan 23, 2014 at 2:55 PM, Andrew Edwards <edwards.ac@gmail.com
> <mailto:edwards.ac@gmail.com> <edwards.ac@gmail.com>>
> 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=T8BQ4nPb5OEbADNbUQDD2ijuQ@mail.gmail.com><http://forum.dlang.org/post/CAFU1Uzpm4DBADOxMjcJ_Guj1=T8BQ4nPb5OEbADNbUQDD2ijuQ@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
> 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
>