[gmx-developers] Release planning, milestones and gitlab issues

[Erik Lindahl]

Hi again!

To follow up on the discussion yesterday, I have spend quite a bit of time
going through everything that was tagged against 2022-related milestones
and somewhat heavy-handedly changed things a bit.

1) First, I've tried to improve our usage of milestones. All active
milestones now have both clear start and end dates, and I have created
distinct milestones for items such as beta2, the release candidate, and
actual release. At the same time, I have also created all the milestones
for release-2023 to make future planning easier.

2) However, in contrast to our earlier setup, we should be much more
restrictive with wadding issues to milestones. As I see it, these
milestones should be reasonably well-planned intervals of a few weeks to a
few months, and when we add an issue to a milestone that should correspond
to deliberate planning that we've decided to prioritize it, there are
efforts allocated, and a fairly serious expectation we'll be able to finish
it - and actually *close* the issue - by the milestone.

3) We will of course occasionally miss milestones, which is fine, but there
is little to no utility in unrealistically having hundreds of issues marked
for a milestone just to end up bumping 90% of them to the next milestone
when the date finally comes. Second, I think we've repeatedly created
situations where we're incapable of making proper planning/priorities
because there are hundreds of active issues for a particular target.  So,
my thought here is that by being much more restrictive about things we
actually target for a milestone, we will be able to do a better job at
prioritizing (and finishing) the things we do list.

4) For the current release phase, I think we all agree that we both want a
few remaining code fixes in, we want to shepherd important things already
submitted into the release, and do testing. To be able to achieve that and
ship a beta2 that is at least code-complete by November 26, we need to
accept that we only have ~10 more days to submit actual new code, after
which we need to reserve ~10 days for code review and a final few days for
testing.  Thus: A milestone of e.g. Nov 26 is a joint milestone for us as a
_team_ to finish everything for beta2, not an indication we can all keep
working on new code that we submit on November 25 :-)

5) Finally, I want to attempt a slightly "tighter" (in lack of better
words) beta cycle where we don't overwork the team, do hail-mary
coding/testing over the holidays or push things into January. If we are
successful at that, perhaps we could consider modifying our schedules into
having a major patch (or new release) after 6 months, which would remove
the issue where we are all a bit overworked this time because it's the last
chance to get stuff in for a year. No promises, but it's worth a shot.


So, based on all this I would ask everyone to:

A) Go through open issues and bug reports not yet targeted for 2022.beta2
and help us find ones that are so important that we really *should*
prioritize them over others in the next ~10 days.

B) Help with open issues targeted for 2022.beta2, and/or split large such
issues into smaller components if necessary. Perhaps there is one part that
can make it into release-2022, while we push others to next year?

C) Be realistic about priorities. You're all doing a GREAT job, and almost
all issues are worthwhile, it's just that we have to decide which ones are
more important than others at this point, and make sure we focus on those.
Deciding to push some things is not failure, but good team-work!

D) Help reviewing each other's changes! Towards the end of this month we'll
get a bit more formal about this and try to assign people to help with
reviews, while we mostly stop considering new code changes.

E) Be gentle & collaborative in comments and code review. We will need to
make exceptions, we will need to accept code that might not be perfect -
and we will also need to decide that some changes simply don't make the
release in time. These decisions will not be perfect or 100% fair, but the
better we are at quickly making decisions about such cases, the more time
we will have to help each other with review and maybe making one more
exception.


All the best,

Erik
-- 
Erik Lindahl <erik.lindahl at dbb.su.se>
Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
University
Science for Life Laboratory, Box 1031, 17121 Solna, Sweden

Note: I frequently do email outside office hours because it is a convenient
time for me to write, but please do not interpret that as an expectation
for you to respond outside your work hours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20211021/4f482998/attachment.html>