<br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 1:46 AM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</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"><div><div class="h5">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></div>
<div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<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></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>
</div></div></div></div></blockquote><div><br></div><div>"Top issues" are highly subjective and reviewers' existing expertise is critical in determining what it makes sense for them to review. So I'm not sure there's a good solution here. Good Redmine subject lines and commit one-line summaries are critical in directing the flow of eyes to things they can usefully read. In Redmine, <a href="http://redmine.gromacs.org/projects/gromacs/activity">http://redmine.gromacs.org/projects/gromacs/activity</a> is a good way to find out what's bubbling. Filtering the list of gerrit patches by things like "status:open branch:master" can be useful. People submitting patches should try to identify reviewers who can be useful. If the above happens (and I think it mostly does) then I think we're doing reasonably well.</div>
<div><br></div><div>Personally, I'd rather browse gerrit for open patches that look like they're doing important things, than try to filter Redmine by the things that have patches in gerrit. If the latter condition was flagged automatically, that would help a little. What do you think about <a href="https://github.com/tru/redmine-gerrit-scripts">https://github.com/tru/redmine-gerrit-scripts</a>?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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>
</div></div></div></div></blockquote><div><br></div><div>Right, so anybody reading that knows that they might get fixed some time in the future. I think the Redmine targets are only useful as vague indicators, particularly because anybody can set them and so there is no pattern to their meaning until somebody spends a few hours triaging. There's a heck of a lot of things targeted at "future" too.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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>
</div></div></div></div></blockquote><div><br></div><div>Not sure what you mean here. Please feel free to read 4.6.1 as "4.6.2 or future, whenever someone gets time to make a suggestion" :-) It seems every time there's a release there's another minor thing someone would like someone (i.e. Mark) to do. I do not have time in the 40-hour week for which I am paid to manage the whole release process, some of the infrastructure maintenance, some of the user feedback, discuss things on gmx-dev and Redmine, review most of the new code, triage Redmine issues, learn C++, organize gmx-dev teleconferences, do the agreed follow-up from past discussion about master, review others' work on same, write developer manual, learn the existing content of master branch, and help write BlueGene kernels. Many of those could be done full-time if we had infinite resources. How about I start working a 40-hour week and see how well we do then ;-)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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>
</div></div></div></div></blockquote><div><br></div><div>I'm not sure what you mean by "issue management". Someone writing a list of the top 10 gerrit patches or Redmine issues won't achieve much, because most people will only have the expertise to contribute to a small number of them. Someone making a list of things to fix for 4.6.2 would be nice, but if there's nobody to whom they can be assigned, and a timed release will be made even if non-critical fixes are not fixed, then there's not much point. The project is staffed mostly by volunteers, and they will only do the things that interest them. That's life. If we had a team of full-time developers, then today I'd be looking at Redmine and assigning issues to be fixed in the next fortnight. None of us can do that, however.</div>
<div><br></div><div>Mark</div></div>