On Wed, Feb 25, 2015 at 04:40:00PM +0100, Peter Krempa wrote: > On Wed, Feb 25, 2015 at 09:17:27 -0500, John Ferlan wrote: > > On 02/25/2015 07:52 AM, Ján Tomko wrote: > > ... > > > > > > > > ACK both > > > > If I understand the rules of the road correctly... Since the original > > series was reviewed prior to the freeze and this just adjust that, it > > seems reasonable to say it's OK for freeze... The original series was fixing a bug (-bootloader appearing on QEMU command line), but I didn't consider it important enough to push the already ACKed patches before sending another version of this cleanup. These two patches have no functional change, they aren't needed in this release. > > Actually I'd rather not codify that as a rule. After the freeze > everythling should be re-evaluated if it makes sense actually to push. > > Purpose of the freeze is not to limit new features appearing but have a > line where stuff that is likely to break the comming release in any way > to be limited. > Actually, I always thought it was a feature freeze. Merging a new feature usually is more likely to break something than not. > If you get a review for a big feature prior to the freeze and then send > a few patches after the freeze it will not make them automagically > appear in the RC-package or any less likely to break the release. > If the feature was merged before the freeze, then the followup patches are fixing bugs in it, aren't they? :) > I think only fixes that target code that was touched in the last devel > cycle or fix a obvious bug in a common path should be taken, otherwise > we might as well as not have any freeze. > Fixes in less common paths should be taken too if they're serious enough. Either way, I'm bookmarking this thread. Jan
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list