I realise Stuart has asked us to let this go, as people are now mostly
arguing over what they think Tanstaafl won't do, but by now has said he
will, and thus the arguments are pointless, but some things said here
are just too wrong to be left alone...
I'm sure Florian doesn't realise quite what he is saying. He is trying
to defend his position, because he believes in it, and that means
rebutting the arguments against it, despite the broken logic and
dangerous sentiments that introduces. However, I think some things need
to be pointed out.
Please forgive me for using "LO" as a convenience in the below to mean
the people behind the LibreOffice project and those who defend their
position, whomever they may be. I don't know who all they are. I'm not
even sure if Florian is part of the LO team (although he does imply
it below), he may only be defending their position. I also realise that
probably many of the devs (and others) don't share the views below. So
I am not speaking about the views of any single person or persons, but
the view as presented here, and in general in this thread, as
representing the LO project's viewpoint.
Please also understand that I don't use the feature in question, and
until now didn't even know it was broken (well, I do recall this coming
up on this list in the past, now that it is mentioned...). I am also
not familiar with the bug reporting process, as I haven't reported any
bugs myself yet. The process required creating accounts and stuff,
and seemed like some effort, so I left it for a better time. I do have
bugs to report, and fully intend to do so for the betterment of LO, I
just haven't as of this point in time, so am unfamiliar with quite how
the whole thing works. So largely my impressions of the current
situation come purely from that has been said in this thread.
The below is, of course, just my personal view, IANAL, take with a
pinch of salt, YMMV, etc, etc.
Paul
Hi,
Please find my answers inline....
Liebe Grüße, / Yours,
Florian Reisinger
>
>> The real extortion here is someone who expects people to work for
>> his own needs for free.
>
> I am *not* talking about enhancement/feature requests, I am talking
> about a major regression that should have never even made it into a
> release build (in other words, it should have been caught/fixed in
> rudimentary testing),
Dou you think the dev, who implemented this wanted to break this?
>
> Also, as I have said more than once - and even created an
> enhancement request for it -
We (QA) do not look at enhancement requests ATM to be honest... We do
not have the volunteers....
The problem here is that, after several attempts to tell Tanstaafl that
he hasn't been part of the process and thus can't complain, you now
tell him you pretty much ignore the process anyway.
Does LO want user input or not? You cannot base your whole position on
expecting the user to be a large part of the development process and
also ignore the user's input.
I understand you're not saying you're ignoring all user input, only
enhancement requests, but in this case the enhancement request was a
part of the process that Tanstaafl followed in order to help move
things along with the bug that concerned him. And after accusing him of
not being active enough in resolving it, you're basically saying that
he wasn't active enough because you ignored half his activity.
Clearly this does represent a problem in this specific case. The LO
side clearly does have something to answer for here.
And in the general case, ignoring enhancement requests due to lack of
developer time sounds reasonable, but then what exactly are the
developers doing with their time right now? Are there so many bugs that
they are only fixing bugs? In that case are no further major revisions
expected any time soon? I'm assuming major revisions are still planned
for the near future, so am assuming that features are being added, but
where do those features come from if not enhancement requests? Unless
there are both feature and enhancement requests, and if so, please
explain exactly what the difference is, and why only one of those is
considered important right now.
>
> There is simply no - zero - reason to:
>
> 1. have not provided the ability to fall back to the old behavior
> when this very new, very different (to the old way) feature was
> implemented, *especially* considering that the old behavior is
> obviously still there (since you can still invoke it with
> CTRL-SHIFT-F9), or even more inexplicable,
>
It is a major change within a branch. Which is dangerous... Can break
a lot of things
Just like the previous major change (the one which introduced the bug),
but I guess the difference is that that wasn't within a branch, but
between branches. Fair point.
> 2. *immediately* re-introduce the old behavior - at the very least
> as an *option* - once this bug was detected - until it could be
> properly addressed, as I requested (again, once I became aware of
> the issue) here:
Make a custom build 
Or pay someone to introduce that ASAP
Probably the single worst thing that could be said from the LO side
right now. Treating users so callously is a sure way to lose them.
I understand that LO is a volunteer effort, but if it has any hope of
being a serious competitor to the likes of MSO, or as being anything
but a nice little side project that some guys are working on and some
people find somewhat useful, it needs to understand that users are not
always going to want to be developers, or be super rich. And given the
prices quoted for features and bugfixes, I would say that only the
super rich can afford that sort of thing. The rest of us, if we're not
developers, will have to wait.
But most people will just migrate away to something that works, most
likely MSO. Even if it doesn't actually always work, the perception is
that it does, and so users will leave. Now, for some open source
projects, that's ok. The devs are scratching their own itch, and anybody
that tags along, fine. But they don't mind if users leave. Better that
a user leaves than that he becomes demanding. But is that really the
sort of project LO is? It is trying to market itself as if it isn't, as
if it is a serious alternative. And that means it has users. And
keeping users means at least a little pandering. Now with MSO MS can
afford to ignore users when they complain, because they don't leave.
But for most commercial projects, if the users start complaining about
serious bugs, they sure *do* jump to it. They don't put it in a testing
branch and do nothing with it, hoping the users will notice and test it
for them. They fix it, test it, and roll it out to their users. And
with most users already half convinced they've made a mistake coming to
LO and should have stuck with MSO, having an attitude of "fix it
yourself or pay someone to fix it, just don't bug us" is going to lose
you users. Big time. Even if those users are whiney, demanding
want-it-all-for-free's, they're the only users you've got.
And in this case it clearly is not the case, the user is an involved,
helpful user who is annoyed by the attitude he is getting, which is
unwarranted.
And this sort of attitude is deeply worrying to me, too. I'm sure it's
not what Florian means, nor what LO stands for, but it shouldn't even
feature.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=79877
>
>> Note that the patch already exists, but that you were not
>> proactive in even calling attention on the issue.
>
> That is because, as I said:
>
> 1. There was basically no notice that such a major change was
> pending (I've been on the libreoffice users list since it was
> created, and the openoffice list for years prior to that),
>
You won't find such things on the user list... I guess it was not
even on the QA list... Maybe on the dev list... IDK
One could read the changelog, but who does that?
One doesn't expect old things to be broken, one just expects some new
features to have been added and some bugs to have been fixed. And new
bugs aren't exactly in the changelog
And if one discovers a bug, well, one participates in
the bug reporting process, and hopes it gets fixed fairly soon.
And that's all fine, so far. It's when things aren't fixed, and one
starts pointing it out, and gets blamed for not being part of the
process, and told to either pay for it, fix it yourself, or basically
keep quiet and wait until somebody decides to get round to it, one
starts to get a little peeved. Especially when said bug is a major part
of the application. A real show-stopper. Not some minor edge case that
one might be more or less alone in experiencing. And something that was
introduced into a working feature, not a new feature, and really, really
should have been caught before release.
So most of the time there is no problem here, but in this particular,
and unusual case, the standoffish nature of the LO defenders who
refuse to admit any culpability is not helpful.
Also, as a side note, but relevant in this case, if people who report
bugs are not even informed when the bug has been put in a test build,
how are they supposed to test it? And if devs refuse to do anything
until the users have tested the test build, this will all go nowhere
fast.
> 2. As a one man shop, my time is limited, so my habits with respect
> to testing new Libreoffice builds were to wait until the next major
> version is at least at a .2 or .3 version,
>
Far too late to fix in this branch....
And in this particular case, apparently in the next branch, and the
next...
> 3. It is impossible to test every single feature, as evidenced by
> the actual devs who implemented this new feature/change who failed
> to even TEST the very BASIC paste functionality (as evidenced by
> the fact that the bug exists).
As a dev (I can tell you) you focus on other use cases then the
actual users sometimes....
A problem in its own right, but admittedly one that does tend to
happen. Devs become notoriously blinkered when staring at code all day
(I should know, I am one).
If a user test the BASIC functionality on
alpha 0 this would be soon enough to get the fix (theoretically)
>
> As soon as I encountered it (when the first user I had updated
> reported it to me), I discovered the already opened bug (then
> subsequently created the 'enhancement' request referenced above to
> re-enable, as an option, the old behavior).
>
>> This seems to suggest that the situation your company is on with
>> respect to your LibreOffice deployment is not really problematic.
>
> It is, but there is simply nothing we can do about it.
>
>> If you are not ready to pay anything to have someone fix your
>> problem,
>
> Whose problem? First, this is Libreoffice's problem.
You cannot use the feature. It's your problem. There are no
"LibreOffice's problems"
Ok, maybe *this* is the single worst thing that could be said from the
LO side right now. I really can't decide between the two. They're both
the same issue, of course.
The user doesn't have a problem here, at least, not for longer than it
takes to uninstall LO and install MSO.
It *is* LO who has a problem when all their users leave because the
user support is condescending and unhelpful. At least, assuming, as per
the marketing, that LO considers itself a serious contender in the
office suite space.
The volunteers on LO's side may not care enough about keeping users to
put in more of their own blood sweat and tears than they already do,
and it is hard to blame them for that, but LO as a project will suffer
for it. LO as a project may not have the resources to do this, but if
it has any resources, it should consider shifting them around to do
more in this department, or changing their handling of this.
This may not be right, this may not be fair, but it is true.
Now, I don't feel that these comments represent the LO position
normally, but they have been used to defend the LO position in this
case. And in this case we're not talking about a particularly whiney
user, or a user who is demanding anything difficult or extraordinary,
nor a bug that is minor or difficult to fix (as far as I can tell,
which, without looking at the code, has to be but an educated guess,
although it does sound like a safe bet). We're talking about a
completely reasonable user who has participated in the process as much
as he was able, and has had some of that participation ignored (see
above), and has now pointed out that this has been handled badly from
LO's side, and is now being made out to be unreasonable in order to
justify LO's position, instead of LO admitting that there is some blame
on them.
The user isn't even complaining that LO made a mistake, the user is
complaining that nothing is being done about it, because as far as the
user was aware that was the case. For a major bug that was introduced
into a working feature. And wasn't fixed for more than one major
release. Which is a fairly bad state of affairs. And had LO said "oops,
our bad", and promised to do something about this, all well and good.
But refusing to admit even the slightest blame here, and instead trying
to make out that this whole thing was the user's fault for expecting
anything, and taking a stance of "quit buggin' us, we aint interested,
pay for it or do it yourself", this is not a good situation for LO to
be in. Not by a long shot.
> Second, I am not
> the decision maker for things like this for our company. I am
> simply an IT guy. If you must know, if this were my company, I
> would be supporting numerous open source projects financially, but
> again - it is not my decision, and so I have to work with what I
> have, and since I am not independently wealthy, I am unable to pay
> for things like this out of my own pocket.
So leave them with a security vulnerability - Good job IT guy 
Well, partly that's their choice. They could pay for a bugfix, or live
with a show-stopper, or live with a security vulnerability.
Although, at the quoted prices, I can't blame them for not wanting
to pay for this to get fixed. Especially when there is a lot of
justification to the argument that if LO broke it, LO should fix it.
I suppose that LO could argue that they have no responsability to keep
the application in a working state, but then they can't also want to be
part of the real software world, the one where they have actual users.
>
> But that is all nothing to do with the fact that the responsibility
> for fixing REGRESSIONS should fall on the dev(s) that introduced
> them, and in fact this responsibility should be a part of any
> agreement they are subject to when formally accepted as dev
> contributors.
You can not force a volunteer
No, but you can revoke their commit access. If a dev is going to go
around breaking things, and then refusing to fix them, he is going to
cause more harm to the project than good, and shouldn't be allowed to
play in the sandpit.
In this case that is abviously too drastic a measure, but the point
still stands that the developer who broke it does bear some
responsibility to fix it. And LO as a whole bears some responsibility
for the actions of their team. And should admit that, rather than
trying to paint the bug reporter as the bad guy. Well, not the OP in
this case, but the guy who is complaining that LO are ignoring the
issue, because as far as he was aware they were. And the onus is on
them to make him aware that they had done something, at least by
posting the solution on the bug tracker, not on him to watch the entire
project, including all the testing builds, for possibly months on end,
just to see if they had deigned to get round to his bug.
I may be wrong, but as far as I have understood from Tanstaafl's posts,
there was no notice on the bug tracker that there was a test build
claiming to fix this, or at least no notice to the people connected to
the bug, at least until quite recently. If I'm wrong, then one can
debate about why he didn't notice this earlier and test it and post
back to the bug tracker so that the fix could be included in a release
build. But if my understanding is correct, then there is almost no way
that LO can claim they don't have egg on their face. Trying to divert
attention off them by blaming Tanstaafl isn't making the egg go away.
>
> Likewise, the responsibility for properly testing major new
> features is
> - or should be - again, first and foremost on the dev(s) dong the
> work, and only secondarily on the users.
They do test... But they cannot test everything. The users should
test as well. Their pet use case...
"Their pet use case" is so far from the situation here that this cannot
be anything but an attempt at misdirection. I am sure it wasn't meant as
such, but clearly you have either not been following closely enough, or
have not understood that the particular use case in question is very
clearly an obvious use case. Yes, those do get missed all the time. But
in all the positions I've worked in missing that sort of thing comes
with a stern talking to for both the developer and the tester.
And LO needs to admit that it was a rather big blunder. Those happen,
and no-one should be trying to hang LO for it. In fact, LO being able
to admit it would make us all feel a little more sympathetic to LO.
It is not relevant to the question of how involved Tanstaafl has or
hasn't been or how unreasonable he is or isn't being, at least not
directly, but so far no one seems to want to admit even this most
obvious of faults on LO's part. Which means the response as a whole
comes off as trying to shirk all guilt.
>
> If you are seriously suggesting otherwise (and I don't think you
> are, so the following shouldn't apply to you), then you are nuts.
>
>> and don't even show up to call for an integration of the patch as
>> soon as possible,
>
> I called for it as soon as I became aware it was there.
>
> But, the point is, it should, again, be first on the dev(s) who
> introduce the regression to push the patch(es).
And you do not care it is risky?
He probably does care, a lot, but as he has pointed out, he's in no
position to change it. There is a strong argument that his employer in
this case is partly at fault, but that's just the way users are going
to be. And LO wants users. So LO is going to have to learn to make nice
with this sort of user, who is far from the most obnoxious type you'll
see. This is, however, the most common type you will see.
And in this case, given the responsibility of LO in this particular
case, and the costly options facing Tanstaafl's employer, it is
possibly even a thin argument that he should be doing things
differently.
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}