<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 3, 2016 at 12:17 AM, Robin Gareus <span dir="ltr"><<a href="mailto:robin@gareus.org" target="_blank">robin@gareus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tim,<br>
<br>
Since there are only about 2 1/2 persons working on Ardour at any given<br>
time the overhead of all this is significant.<br>
<br></blockquote><div> </div><div>I disagree that the overhead is significant. It is a long proposal but it is basically just sending 3 emails at various points in the release process, which I've volunteered to do.</div><div><br></div><div>The only part of the process that may take any significant time is going through the commit list and bug tracker to gather a list of fixes for the "feature freeze" email. That part of the proposal could be optional but is something that needs to be done for the release announcement anyway so is not really an overhead.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While the outlined process makes sense in general, I'd think twice<br>
before proposing this for a tiny dev-team.<br></blockquote><div><br></div><div>I can think of 3 part time contributors (Myself, Nick and John Emmas) that would benefit from these announcements, so they can respond if they agree.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For major version releases the current procedures are already very close<br>
to what you suggest and by experience it usually takes weeks to get<br>
though the final stages (feature-freeze, string-freeze,...)<br>
<br>
For point releases, the Ardour-dev team is too small to take care of all<br>
this. Remember, the general goal is to have bi-monthly point releases.<br></blockquote><div><br></div><div>It is not much to take care of IMO, the only real difference is that we have one week out of the 8 or so that we dedicate for testing/release process and we announce it in advance so that those that aren't or can't be on IRC 24/7 can be notified and hopefully contribute.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's also no "traditional" product-manager for Ardour to oversee<br>
things, nor a dedicated person to triage bugs reports, nor is there a<br>
second team to review code. Nightly builds and daily testers on IRC have<br>
proven a lot more useful for the small team.<br>
<br></blockquote><div> </div><div>Yes, I realise that users are doing most of the testing, and I think they would benefit most from my suggested changes.</div><div><br></div><div>A slightly longer and announced testing/release period should help improve the quality of releases and I don't think that would hinder the development process.</div><div><br></div><div>It allows those people that want to contribute to fixes/testing/translation/etc an opportunity to do so with the expectation that there will be no major changes/regressions before release. It should also make it easier for the person doing the release as it means there is more time for system/packaging tests, which I think would help after following the last few releases.</div><div><br></div><div>I'm only suggesting dedicating a small fraction of the development cycle to testing, a far smaller fraction than some other open source projects.</div><div><br></div><div>Tim</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2c,<br>
robin<br>
<div><div class="m_1686752996645376275h5"><br>
On 10/02/2016 02:45 PM, Tim Mayberry wrote:<br>
> In the interest of maintaining and improving the quality of Ardour releases<br>
> I'd<br>
> like to request some small changes to the release and development process.<br>
><br>
> Firstly can we have additional communication via email at certain points in<br>
> the<br>
> development cycle?<br>
><br>
> This would be for the benefit of developers, testers, packagers and users<br>
> that<br>
> for whatever reason are not able to follow and participate in realtime<br>
> communication via IRC or are not privy to private development/release<br>
> planning<br>
> discussion.<br>
><br>
> I'm not asking that private discussions be made public, only that any<br>
> decisions<br>
> that may affect participants be announced in case they miss a conversation<br>
> and<br>
> or feel further discussion is necessary before action is taken.<br>
><br>
> Specifically I think there should be 3 release management related emails.<br>
><br>
> The first would be sent at the start of the development cycle(so just after<br>
> a<br>
> release), signaling the start of the development period(a merge window).<br>
> This<br>
> could be something as simple as:<br>
><br>
> "<br>
> The master branch is now open for commits/merging.<br>
><br>
> Any feature/topic branches that haven't already been discussed and approved<br>
> for<br>
> this cycle please push to origin/official repo and announce that you have<br>
> done<br>
> so with the intention to merge. Then allow some time for testing/discussion<br>
> (email and or IRC) before merging.<br>
> "<br>
><br>
> The second email would be to announce a feature freeze period, which is<br>
> related<br>
> to my second request to have a period of at least a week (preferably longer)<br>
> before the estimated release date where only straight forward fixes are<br>
> committed.<br>
><br>
> The email should contain:<br>
><br>
> - An estimated tagging/release date, contingent on blocker bugs (if any)<br>
> and the<br>
>   result of testing.<br>
> - A list of the features and fixes (with references to bug tracker) that<br>
> have<br>
>   been committed during the development period and any information relevant<br>
> for<br>
>   testing (This list will also be used at release)<br>
> - List any regressions or issues blocking release with references to bug<br>
> tracker.<br>
> - A request for participation in translation and documentation.<br>
><br>
> A simplistic example of such an email might be something like:<br>
><br>
> "<br>
> The development period/merge window is coming to a close. I plan to tag a<br>
> release late next week so if you don't think you can finish up any<br>
> outstanding<br>
> issues with recent work in master by next Wednesday (18th), then please<br>
> respond<br>
> ASAP so we can discuss.<br>
><br>
> There have been a number of new features (X, Y and Z) added this cycle so<br>
> please<br>
> focus on testing those to ensure there are no remaining issues and if you<br>
> find<br>
> some, please use the bug tracker to report them.<br>
><br>
> If you are interested in helping with testing for this release, please see<br>
> the<br>
> following list of bugs that have been fixed during this cycle. Additional<br>
> confirmation that these issues are fixed and that there have been no<br>
> regressions is welcome. General triage of other issues in the bug tracker is<br>
> also welcome, especially for those bugs that have not been confirmed.<br>
><br>
> [ Bug list ]<br>
><br>
> Now is the time for contributions to translations so please send pull<br>
> requests<br>
> via github by Wednesday (18th) for them to be included in the release.<br>
><br>
> Contributions to the documentation/manual are welcome at any time, but now<br>
> is<br>
> also a good time to review the recent changes and features implemented to<br>
> ensure that the documentation up to date.<br>
> "<br>
><br>
> The third email would be an announcement of an intent to tag the release.<br>
> This<br>
> would be sent 24 hours before tagging and is probably only necessary AFAICT<br>
> because of how the current build system/release system works - there can<br>
> be no commits while the official builds are taking place.<br>
><br>
> This lets all people with commit access know not to commit until after<br>
> release (or merge window opens) and hopefully will prevent an issue<br>
> occurring<br>
> like with the 5.2 release.<br>
><br>
> Ideally these emails will just be a template and minimal time will be spent<br>
> on<br>
> adjusting them and sending them at appropriate times by the release<br>
> coordinator. I volunteer to do this if necessary.<br>
><br>
> My last request is that we try to merge larger changes and those that<br>
> introduce<br>
> additional library dependencies towards the start of the development cycle.<br>
><br>
> I spent a fair amount of time testing and fixing bugs with the expectation<br>
> that<br>
> we were heading towards a release as it had been mentioned on IRC but was<br>
> totally unaware that so many changes were going to be merged just before the<br>
> release.<br>
><br>
> While the changes probably did not invalidate my testing or fixes as they<br>
> were<br>
> mostly related to the new push2 control surface support, it still takes<br>
> time to<br>
> determine. It should not have to be done in such a short timespan and it<br>
> does<br>
> not allow time for testing or review.<br>
><br>
> I look forward to your feedback,<br>
><br>
> Tim<br>
><br>
><br>
</div></div>______________________________<wbr>_________________<br>
ardour-dev mailing list<br>
<a href="mailto:ardour-dev@lists.ardour.org" target="_blank">ardour-dev@lists.ardour.org</a><br>
<a href="http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org" rel="noreferrer" target="_blank">http://lists.ardour.org/listin<wbr>fo.cgi/ardour-dev-ardour.org</a><br>
</blockquote></div><br></div></div>