[Libreoffice-qa] mab4.2 to mab4.3 migration almost over

Alexander Thurgood alex.thurgood at gmail.com
Wed Dec 17 10:18:50 PST 2014


Le 17/12/2014 18:16, Joel Madero a écrit :



>> Shifting MABs is a convenient way of ignoring long-felt problems,
>> sprucing up the QA stats, and a bit like ignoring back pain and hoping
>> it will somehow go away.
> I don't think it's a "convenient way of ignoring" - it's just our
> workflow and has nothing to do with ignoring anything.


Call it my cynical view from my armchair, then, if you will. The older I
get, I the more I seem to espouse the philosophy of "release when it is
ready", rather than "release at all costs and be damned".



> I'm aware of no such mantra. My understanding is that we accept and are
> transparent about our bugs - vs. closed source projects which hide
> behind their veil of secrecy. Who is claiming this? Someone on our project?

Not on QA - realism is much more prevalent here, and among the devs, for
that matter, who are equally pragmatic, afer all they're the ones that
fix the code - we all know it is about resources and orioritising them.

Evangelism and marketing spring to mind, where this kind of behaviour
tends to surface, but certainly on various social media outlets (G+
included) and in non-project related forums where LO was being discussed.


> Yes - and if the user leaves...well, we accept that there are
> alternatives (mostly that they'd have to pay for). We shouldn't pretend
> to our users that at $0 they're going to get a flawless product (hell

There is actually more than a fair selection of free "office" suites
available these days :

- Pages, Keynote, Numbers on Mac
- Google's ubiquitous offering
- Softmaker's FreeOffice
- WPS Office

and no doubt more that I have forgotten or overlooked, and obviously
these products will have their own issues, that may or may not be fixed
over a given period of time.

I'm just not convinced that shifting longstanding bugs constantly from
one version to the next is the best way to deal these issues, but as I
don't code, nor am I likely to be able within the foreseeable future, it
is not my place, nor can it be, within the framework of a project like
this, to tell someone to go and fix this and that bug, which always
leaves one with a slightly bitter taste in ones mouth ;-)

Alex



More information about the Libreoffice-qa mailing list