[gmx-developers] 4.6.1 is out

[Mark Abraham]

On Wed, Mar 6, 2013 at 1:46 AM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:

> On Tue, Mar 5, 2013 at 9:00 PM, Mark Abraham <mark.j.abraham at gmail.com>wrote:
>
>> Hi developers,
>>
>> 4.6.1 is now out. I'd like to give a particular thanks to all who helped
>> review the patches.
>>
>> 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. :-)
>>
>
> 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.
>
> 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.
>

"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,
http://redmine.gromacs.org/projects/gromacs/activity 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.

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
https://github.com/tru/redmine-gerrit-scripts?

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.
>

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.

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.
>

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 ;-)

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)
>

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.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130306/9dc33da8/attachment.html>