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