Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Tue, 2011-09-13 at 00:23 +0200, Cor Nouws wrote:

            + always a trade-off between quality, community fun,
              pace of development (Michael)

   No real argument. I am more interested in the question: do we want
   avoid another 3.4-style release?

So, our memory is getting rustier about how the 3.4.0 release went.
Could you refresh our memory as to what exactly were the issues
concerning the 3.4.0 release?  I assume here that by "3.4-style release"
you mean the actual 3.4.0 release.

It's much easier to discuss specific issues than vague "let's avoid the
3.4-style release" style of argument.

- number and severity of changes on code
how many difficult/basic stuff are touched in these months?
We know that when so much is changed, for sure many nasty hidden
older bugs will surface..

   I have deep respect for the work of Kohei, Eike and Marcus.
   But they do change a whole lot of stuff these days, weeks, months.
   Is it strange that we have to expect quite some unexpected
   side effects?

So,  you want us to stop writing code?

On a serious note, any developers worth his/her money are aware that
making changes may introduce side effects.  There is no way to avoid it.
What we do is that, given that possibility, balance out the necessary
code change *and* avoiding regressions, and do our due diligence to test
our code.  Even with that, some things break in some unknown corner case
scenarios.  So we rely on testers to weed out those weird corner cases
that we had not anticipated.  To me that's just the normal course of
business.  We also help each other out by code review, and also fix each
other's bugs.

Plus, we are not even hitting the code freeze (Dec 5), so I don't think
it's fair to start blaming us for the necessary code changes, unless you
want this project to stagnate to a stand-still way before hitting the
code freeze.

   We cannot on the one side complain that the old code is quite filled
   with oddities, mistakes, redundancies etc etc, and on the other
   hand do light on the risk of side effect with large code changes

Oh come on.  Save us the lecture there.  We are all aware of the risks
of large code changes.  So we are limiting that until we hit a code
freeze.  Isn't that reasonable?

I'm very very confused.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.