[Ardour-Dev] Release Management/Development process
robin at gareus.org
Sun Oct 2 07:17:06 PDT 2016
Since there are only about 2 1/2 persons working on Ardour at any given
time the overhead of all this is significant.
While the outlined process makes sense in general, I'd think twice
before proposing this for a tiny dev-team.
For major version releases the current procedures are already very close
to what you suggest and by experience it usually takes weeks to get
though the final stages (feature-freeze, string-freeze,...)
For point releases, the Ardour-dev team is too small to take care of all
this. Remember, the general goal is to have bi-monthly point releases.
There's also no "traditional" product-manager for Ardour to oversee
things, nor a dedicated person to triage bugs reports, nor is there a
second team to review code. Nightly builds and daily testers on IRC have
proven a lot more useful for the small team.
On 10/02/2016 02:45 PM, Tim Mayberry wrote:
> 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,
More information about the Ardour-Dev