<div dir="ltr"><div><div><div><div>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.<br>

<br></div>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.<br><br></div>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.<br>

<br>------<br></div><div>Now I'm going to rant on some of the things mention.<br></div><div><br></div>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.<br>

<br></div>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.<br>

<div><div><div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 2, 2014 at 11:34 AM, Михаил Страшун <span dir="ltr"><<a href="mailto:public@dicebot.lv" target="_blank">public@dicebot.lv</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">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 :)</span></div>

</blockquote></div></div></div></div></div></div></div></div></div>