On Thu, Dec 6, 2012 at 8:05 AM, Markus Armbruster <arm...@redhat.com> wrote: > Blue Swirl <blauwir...@gmail.com> writes: > >> On Wed, Dec 5, 2012 at 7:41 PM, Hans de Goede <hdego...@redhat.com> wrote: >>> Hi, >>> >>> >>> On 12/05/2012 08:28 PM, Blue Swirl wrote: >>>> >>>> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aligu...@us.ibm.com> >>>> wrote: >>>>> >>>>> Peter Maydell <peter.mayd...@linaro.org> writes: >>>>> >>>>>> On 4 December 2012 18:38, Blue Swirl <blauwir...@gmail.com> wrote: >>>>>>> >>>>>>> The definition of the hard freeze bothers me. A few patches that went >>>>>>> in after 1.3-rc0 were not bug fixes but just new features, so the >>>>>>> difference between soft and hard freezes was not clear. >>>>>> >>>>>> >>>>>> My vote for this would be to adhere to our definition >>>>>> and only commit bugfixes. >>>>> >>>>> >>>>> Let's get specific. What was committed post hard freeze that's not a >>>>> bug fix? >>>> >>>> >>>> d3067b0 Documentation: Update image format information >>>> a13e5e0 Documentation: Update block cache mode information >>>> 044d003 qemu-tech.texi: update implemented xtensa features list >>> >>> >>> Adding missing / updating docs to be more accurate is a bug fix, >>> and one with a very low chance of causing regressions at that. >> >> I don't think they are bug fixes but improvements to documentation >> features. But I agree patches only touching documentation, comment and >> string contents could be exempted. > > What about improvements to tests? No impact on anything but "make > check".
While not bug fixes either, those should be also OK. Though if we had a QA or release team running tests (including these), they would probably have to restart their test cycle if there are changes to the test sets so it's not 100% clear. > > [...]
