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 On Thu, 2 Oct 2014 20:46:42 +0200 Florian Reisinger <[email protected]> wrote: > Hi, > > Please find my answers inline.... > > Liebe Grüße, / Yours, > Florian Reisinger > > > Am 02.10.2014 um 15:05 schrieb Tanstaafl > > <[email protected]>: > > > > On 10/2/2014 4:34 AM, Charles-H. Schulz > > <[email protected]> wrote: > >> 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. > > > > >>> Stick with 4.1.6 (that actually works). > > > >> It works really well, with an important vulnerability left > >> unpatched. That seems to be not important to you either: > >> http://www.libreoffice.org/about-us/security/advisories/ > > > > It is, but again - we are in the position of being forced to choose > > between a rock and a hard place. > > > >> I guess everyone has his or her own priorities, but if anything > >> happens because of that, you will have been warned. > > > > Yeah, thanks for ... nothing... > > > > -- > > To unsubscribe e-mail to: [email protected] > > Problems? > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > > Posting guidelines + more: > > http://wiki.documentfoundation.org/Netiquette List archive: > > http://listarchives.libreoffice.org/global/users/ All messages sent > > to this list will be publicly archived and cannot be deleted > -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
