[dmd-beta] Cherry-picking II

[Jesse Phillips]

Considering Andrew is requesting help to identify which changes should be
merged into release, I doubt this would be acceptable. The person creating
the patch is the most likely candidate to know that his changes need to
enter into release. Though if they are working on regressions, it is
possible to identify the pull requests made for them.

If there was agreement to move in this direction, then me and others could
probably help by yelling at those who make a pull against master and who
pull the request into master.

Andrew has been doing a really good job. Working hard to get the builds to
generate consistently, trying to identify what needs to go into release.
But he's been put in a position where no one seems to want to make his time
a little easier. The idea that a build manager can just take care of things
and everyone else could just go about their business as usual always seemed
very naive to me.

------
Now I'm going to rant on some of the things mention.

The freeze, fix, release, process is very easy to run, its the simplest
process for making a release. However we've decided that isn't acceptable
anymore, that means things must get complicated and that means things will
change. If the goal is to make releasing a version as simple as possible,
we're heading in the wrong direction. If the goal is to allow development
to continue while pushing a release, and to support a release once it is
out the door, then everyone must realize that this means there is some more
work to organize that process and everyone will play a small role.

There was mention of not using branches and instead "forking." I'm sorry,
git doesn't know the difference, they are the same damn thing in git's
view, they are even managed practically the same. The only benefit from the
article was a psychological one. The choice they made was to manage their
branches separately; instead of patching one branch and
merging/cherry-picking into another, they duplicated the effort in both
branches, the branches were never to cross paths again (one dying out
eventually). Essentially they just forced themselves into the limitations
of SVN.


On Sun, Feb 2, 2014 at 11:34 AM, Михаил Страшун <public at dicebot.lv> wrote:

> Well, what about getting back to sane git model but using inverse help
> from Release Manager? I mean making his job to make sure no fix commits go
> into master while release is in progress and reverting those who slip by an
> accident (with a reminder to redo pull request to proper base). This is
> much less of a burden than cherry-picking and may eventually teach everyone
> to make correct pulls without reminders :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20140202/de2be935/attachment.html>