<div dir="ltr"><div>In the interest of maintaining and improving the quality of Ardour releases I'd</div><div>like to request some small changes to the release and development process.</div><div><br></div><div>Firstly can we have additional communication via email at certain points in the</div><div>development cycle?</div><div><br></div><div>This would be for the benefit of developers, testers, packagers and users that</div><div>for whatever reason are not able to follow and participate in realtime</div><div>communication via IRC or are not privy to private development/release planning</div><div>discussion.</div><div><br></div><div>I'm not asking that private discussions be made public, only that any decisions</div><div>that may affect participants be announced in case they miss a conversation and</div><div>or feel further discussion is necessary before action is taken.</div><div><br></div><div>Specifically I think there should be 3 release management related emails.</div><div><br></div><div>The first would be sent at the start of the development cycle(so just after a</div><div>release), signaling the start of the development period(a merge window). This</div><div>could be something as simple as:</div><div><br></div><div>"</div><div>The master branch is now open for commits/merging.</div><div><br></div><div>Any feature/topic branches that haven't already been discussed and approved for</div><div>this cycle please push to origin/official repo and announce that you have done</div><div>so with the intention to merge. Then allow some time for testing/discussion</div><div>(email and or IRC) before merging.</div><div>"</div><div><br></div><div>The second email would be to announce a feature freeze period, which is related</div><div>to my second request to have a period of at least a week (preferably longer)</div><div>before the estimated release date where only straight forward fixes are</div><div>committed.</div><div><br></div><div>The email should contain:</div><div><br></div><div>- An estimated tagging/release date, contingent on blocker bugs (if any) and the</div><div>  result of testing.</div><div>- A list of the features and fixes (with references to bug tracker) that have</div><div>  been committed during the development period and any information relevant for</div><div>  testing (This list will also be used at release)</div><div>- List any regressions or issues blocking release with references to bug tracker.</div><div>- A request for participation in translation and documentation.</div><div><br></div><div>A simplistic example of such an email might be something like:</div><div><br></div><div>"</div><div>The development period/merge window is coming to a close. I plan to tag a</div><div>release late next week so if you don't think you can finish up any outstanding</div><div>issues with recent work in master by next Wednesday (18th), then please respond</div><div>ASAP so we can discuss.</div><div><br></div><div>There have been a number of new features (X, Y and Z) added this cycle so please</div><div>focus on testing those to ensure there are no remaining issues and if you find</div><div>some, please use the bug tracker to report them.</div><div><br></div><div>If you are interested in helping with testing for this release, please see the</div><div>following list of bugs that have been fixed during this cycle. Additional</div><div>confirmation that these issues are fixed and that there have been no</div><div>regressions is welcome. General triage of other issues in the bug tracker is</div><div>also welcome, especially for those bugs that have not been confirmed. </div><div><br></div><div>[ Bug list ]</div><div><br></div><div>Now is the time for contributions to translations so please send pull requests</div><div>via github by Wednesday (18th) for them to be included in the release.</div><div><br></div><div>Contributions to the documentation/manual are welcome at any time, but now is</div><div>also a good time to review the recent changes and features implemented to</div><div>ensure that the documentation up to date.</div><div>"</div><div><br></div><div>The third email would be an announcement of an intent to tag the release. This</div><div>would be sent 24 hours before tagging and is probably only necessary AFAICT</div><div>because of how the current build system/release system works - there can</div><div>be no commits while the official builds are taking place.</div><div><br></div><div>This lets all people with commit access know not to commit until after</div><div>release (or merge window opens) and hopefully will prevent an issue occurring</div><div>like with the 5.2 release.</div><div><br></div><div>Ideally these emails will just be a template and minimal time will be spent on</div><div>adjusting them and sending them at appropriate times by the release</div><div>coordinator. I volunteer to do this if necessary.</div><div><br></div><div>My last request is that we try to merge larger changes and those that introduce</div><div>additional library dependencies towards the start of the development cycle.</div><div><br></div><div>I spent a fair amount of time testing and fixing bugs with the expectation that</div><div>we were heading towards a release as it had been mentioned on IRC but was</div><div>totally unaware that so many changes were going to be merged just before the</div><div>release.</div><div><br></div><div>While the changes probably did not invalidate my testing or fixes as they were</div><div>mostly related to the new push2 control surface support, it still takes time to</div><div>determine. It should not have to be done in such a short timespan and it does</div><div>not allow time for testing or review.</div><div><br></div><div>I look forward to your feedback,</div><div><br></div><div>Tim</div></div>