<br><br><div class="gmail_quote">On Fri, Mar 27, 2009 at 7:05 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>Our release schedule has become a little too variable in timeframe and<br>
quality in recent times. We've tended to get into a situation where we've<br>
had some very large new features going in very late before release with<br>
little time for actually testing them between commit & release. It is<br>
unrealistic to expect pre-commit reviews to catch all problems, so I<br>
think it might be worth us setting out a very slightly more formal rule<br>
for commit/release schedule.<br>
<br>
I'd like to suggest:<br>
<br>
 - Monthly releases aiming for 1st of the month (plus/minus 3 days to<br>
   take into account weekends/holidays)<br>
<br>
 - Any non-trivial new feature for release must be reviewed, approved<br>
   and committed at least 1 week before the release.  eg by 24th of<br>
   each month<br>
<br>
This will give people using libvirt CVS some time to sanity check new<br>
features aren't causing serious regressions / crashes before we release.<br>
</blockquote><div><<snip>> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Daniel</blockquote><div><br>+1 on release schedule.  <br><br>This still gives the project speed and flexibility, while reducing the risks of new features or big changes breaking the release. <br><br>Just my $0.03.  (US Inflation, y'know)<br>
<br>-Richard Balint<br></div></div><br>