On 18.11.2015 11:31, Dmitry Timoshkov wrote:
And that's true for any other patch regardless of the area and amount of code. Basically any patch can have side effects, but if even in the first week of code-freeze any patch is considered as risky, then I don't know how you are going to fix the regressions or any bugs during that time.
I do not want to heat up the discussion, but this is indeed a valid concern, and its also a bit unclear to me what exactly is allowed during the code freeze. In theory, almost every commit could cause regressions. When adding new stubs applications might use a different code paths. When fixing one issue, it might reveal a different one somewhere else.
And especially regarding the remaining regressions: those which already exist for a long time often aren't that easy to fix and also might require reworking a lot of the existing code. This means the risk of adding new regressions is quite high, when they are applied without any testing.
Imho, the only guarantee to ensure a really stable version, would be to develop on both "stable" and "development" in parallel, and frequently backport patches which have been tested well enough - basically similar to our Staging tree. Unfortunately this doesn't force anyone to work on regressions ... ;)
So, what kind of patches are acceptable during the freeze period? If we are too strict, basically only minor cleanup is possible. I still have various patches I would like to send (x86_64 marshalling, ...), but a small risk of regressions is always there.