<div dir="ltr">On Tue, Mar 5, 2013 at 9:00 PM, Mark Abraham <span dir="ltr"><<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi developers,<div><br></div><div>4.6.1 is now out. I'd like to give a particular thanks to all who helped review the patches.</div>
<div><br></div><div>In future, we will use a different process for patch releases. I will announce a date about a week in the future. I will prepare a single administrative patch pertaining only to the needs of making that release functional. I'll upload it for review in the usual way. Once time is up, and if there are no known critical bugs, that admin patch will go on the current head and get merged and tagged. There will be no other sort of "blocking" patches - targets on Redmine are not binding. Then I will do the admin of actually building release files and normal life in gerrit can go on. This is the only way we can have regular patch releases based on volunteer code review, and keep your release manager sane. :-)</div>
</blockquote><div><br></div><div>A bit more code reviewing involvement would be nice, though. After the 4.6 release the activity has sharply dropped and even trivial patched do not get looked at for a long time. <br>
</div><div> <br></div><div>Additionally, it does not help at all that the issue management discussion has been completely abandoned and it is even for rather active developers (like me) very difficult to know what are the top issues to look at. For instance, if I was able to filter in Redmine issues that have fixes/related code in gerrit that is nominated for the next release, or issues that require feedback, I myself could help more in time when other tasks require most of my attention.<br>
<br></div><div>Right now there are still 35 issues left with target release 4.6.1 which does no good in knowing what is the status of things and will ultimately only deter developers from checking such a rather unmaintained database.<br>
<br>IMHO before the release all issues that did not make it should get bumped. Additionally, whether the release gets slightly delayed or not should be dependent on the state of urgent or immediate bugs nominated for the respective release (and not on how annoyed you got with people not reviewing) - and right now there are quite of few of these reports, some of them just forgotten, I assume.<br>
<br></div><div>Te me it seems clear that things could be considerably improved by improving the infrastructure (like redmine+the long ignored question of issue management and gerrit/git-redmine interaction)<br><br></div><div>
My 2 cents, feel free to ignore it.<br><br>Cheers,<br>Sz.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Cheers,</div><div><br></div><div>Mark</div>
<br>--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br></div></div>