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
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
