[Ardour-Dev] Release Management/Development process

Tim Mayberry mojofunk at gmail.com
Sun Oct 2 05:45:14 PDT 2016

In the interest of maintaining and improving the quality of Ardour releases
like to request some small changes to the release and development process.

Firstly can we have additional communication via email at certain points in
development cycle?

This would be for the benefit of developers, testers, packagers and users
for whatever reason are not able to follow and participate in realtime
communication via IRC or are not privy to private development/release

I'm not asking that private discussions be made public, only that any
that may affect participants be announced in case they miss a conversation
or feel further discussion is necessary before action is taken.

Specifically I think there should be 3 release management related emails.

The first would be sent at the start of the development cycle(so just after
release), signaling the start of the development period(a merge window).
could be something as simple as:

The master branch is now open for commits/merging.

Any feature/topic branches that haven't already been discussed and approved
this cycle please push to origin/official repo and announce that you have
so with the intention to merge. Then allow some time for testing/discussion
(email and or IRC) before merging.

The second email would be to announce a feature freeze period, which is
to my second request to have a period of at least a week (preferably longer)
before the estimated release date where only straight forward fixes are

The email should contain:

- An estimated tagging/release date, contingent on blocker bugs (if any)
and the
  result of testing.
- A list of the features and fixes (with references to bug tracker) that
  been committed during the development period and any information relevant
  testing (This list will also be used at release)
- List any regressions or issues blocking release with references to bug
- A request for participation in translation and documentation.

A simplistic example of such an email might be something like:

The development period/merge window is coming to a close. I plan to tag a
release late next week so if you don't think you can finish up any
issues with recent work in master by next Wednesday (18th), then please
ASAP so we can discuss.

There have been a number of new features (X, Y and Z) added this cycle so
focus on testing those to ensure there are no remaining issues and if you
some, please use the bug tracker to report them.

If you are interested in helping with testing for this release, please see
following list of bugs that have been fixed during this cycle. Additional
confirmation that these issues are fixed and that there have been no
regressions is welcome. General triage of other issues in the bug tracker is
also welcome, especially for those bugs that have not been confirmed.

[ Bug list ]

Now is the time for contributions to translations so please send pull
via github by Wednesday (18th) for them to be included in the release.

Contributions to the documentation/manual are welcome at any time, but now
also a good time to review the recent changes and features implemented to
ensure that the documentation up to date.

The third email would be an announcement of an intent to tag the release.
would be sent 24 hours before tagging and is probably only necessary AFAICT
because of how the current build system/release system works - there can
be no commits while the official builds are taking place.

This lets all people with commit access know not to commit until after
release (or merge window opens) and hopefully will prevent an issue
like with the 5.2 release.

Ideally these emails will just be a template and minimal time will be spent
adjusting them and sending them at appropriate times by the release
coordinator. I volunteer to do this if necessary.

My last request is that we try to merge larger changes and those that
additional library dependencies towards the start of the development cycle.

I spent a fair amount of time testing and fixing bugs with the expectation
we were heading towards a release as it had been mentioned on IRC but was
totally unaware that so many changes were going to be merged just before the

While the changes probably did not invalidate my testing or fixes as they
mostly related to the new push2 control surface support, it still takes
time to
determine. It should not have to be done in such a short timespan and it
not allow time for testing or review.

I look forward to your feedback,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20161002/55ee5a09/attachment-0001.html>

More information about the Ardour-Dev mailing list