Announcement

Collapse
No announcement yet.

LibreOffice 7.1 "Community" Edition Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • microcode
    replied
    Originally posted by gilboa View Post

    You're being impolite.
    A. I'm no "other guy". I have a name.
    B. I never said its "dumb". I'm not a 3 y/o and I'll appreciate it if you don't miss-quote me as one.

    Per your point: I've reported bugs to both OO and LO. Some of them got fixed some didn't. But this nearly irrelevant.

    The OSS world revolves around a well defined process: The developer(s) writes code, sometimes for free. Distribution(s) build and package this code, sometimes for free. Users use, test and report bugs in this code, sometimes for free. The developer(s) fix the code, rinse and repeat.

    Essentially, if you don't do your part, how can you expect others to do theirs?

    - Gilboa
    Now that you're done lecturing, if you would actually read what you're replying to you'd get your answer.

    Leave a comment:


  • gilboa
    replied
    Originally posted by microcode View Post
    As for the other guy saying it's dumb that we "wouldn't bother" filing bug reports, you try getting anything resolved there and tell me how it goes, all you have to do is read some of the old bugs sitting around for it. We've tried cracking the source to track down these errors, but this codebase is insane (not entirely their fault but still, not exactly a cakewalk to get started in 30 years of gradual evolution from StarOffice..
    You're being impolite.
    A. I'm no "other guy". I have a name.
    B. I never said its "dumb". I'm not a 3 y/o and I'll appreciate it if you don't miss-quote me as one.

    Per your point: I've reported bugs to both OO and LO. Some of them got fixed some didn't. But this nearly irrelevant.

    The OSS world revolves around a well defined process: The developer(s) writes code, sometimes for free. Distribution(s) build and package this code, sometimes for free. Users use, test and report bugs in this code, sometimes for free. The developer(s) fix the code, rinse and repeat.

    Essentially, if you don't do your part, how can you expect others to do theirs?

    - Gilboa

    Leave a comment:


  • slacka
    replied
    Originally posted by microcode View Post
    how you would always build LO with symbols, and send your company confidential information away in core dumps every time; that is, this is a frequent occurrence; and still manage to get productive work done.

    The fact of the matter is, it's easy for you to say you would be able to generate heaps of useful bug reports, or at least ones that you could find in the kind of search that you did, but sometimes in order to remain in business, you need to focus on doing your job, and that means working around issues rather than expending maybe five to ten hours a week producing test cases and debugging.

    I appreciate that you have so many bug reports! wow! and it's good to have patches in, I appreciate it. And honestly, some day we'll have the budget to retain a full-time LO developer, but today is not that day.
    .
    You are right that many of my bug reports came from company files.(Every file in our share drive was opened and saved by LO for testing). But then through your incorrect assumptions show how little effort you put in by assuming I did the same. No, I did not supply any company documents. Unlike you, I spent the time to reduce the problem document to a small test case. I then reported that new document on the bug tracker. If that document caused a crash, yes, I used a debug build, but there was no need to ever share "confidential information" as the minimized reproducer was used. If you didn't have the time for this, there is a tool to strip out all text from bug docs on LO's QA wiki. The fact that you were unaware of this macro is further evidence of how little effort you have put in.

    The QA and development community behind LibreOffice are a high responsive and professional team. Having made no effort to work with them, you assume the worse. However, I can tell you from firsthand experience, everything you assume about them is wrong.


    Also, we never needed to nor hired any developers for LibreOffice. My company time was limited to a side project where I investigated the cost to risk benefit of migrating from MSO to LibreOffice. In the end, we never migrated. If we had, I would have purchased a support contract.
    Last edited by slacka; 09 February 2021, 12:27 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by microcode View Post
    You being disappointed in me, without context, ain't gonna change a thing. You can tell us all how you would always build LO with symbols, and send your company confidential information away in core dumps every time; that is, this is a frequent occurrence; and still manage to get productive work done.
    https://wiki.documentfoundation.org/QA/BugReport
    The reality here what you wrote does mostly does not apply to Libreoffice. Most fixed bugs are the hand written type.

    Originally posted by [B
    slacka[/B]]In my case, my high success rate is probably because I know how to write quality bug reports, include step-by-step, screenshots, stack traces, etc. I think in your case, it's a lack of trying to engage with the community.
    Wrote this but the reality here is the step-by-step is true part of it. Its all the details you need to make the bug highly reproducible is one of the biggest factors if a bug gets fixed or not the step by step + versions of software and sample files if required. There are statistics pulled out of the LibreOffice Bugzilla on bugs fixed that tell this story. Stack traces and screenshots are in a very small percentage of bugs that get fixed with Libreoffice. The most common for a bug not being fixed is lack reproducibility.


    Originally posted by microcode View Post
    The fact of the matter is, it's easy for you to say you would be able to generate heaps of useful bug reports, or at least ones that you could find in the kind of search that you did, but sometimes in order to remain in business, you need to focus on doing your job, and that means working around issues rather than expending maybe five to ten hours a week producing test cases and debugging.
    Sorry to be the person to bring you bad news here but you have made common mistake. The information you need for a high probability to be fixed bug report is the same information you need for training material production. This need to focus on doing your job this is a common business mistake. What if X person doing X job gets sick or worse dies how are you going to replace them in short order with someone who can productive. This is where you need your training materials. Next you don't want those training materials teaching the new people to perform working around in software that are no longer required this is where reproducible tests come in.

    Working around issues how do you know you need to keep on working around a issue in a new version of the software if you don't have a reproducible test to tell you if a bug still exists?

    Please note reproducible test does not mean spending hours debugging it. With libreoffice its normally taken under 15 mins to make the reproducible test with documentation and possible the file to cause it to happen every single time. Please note that file has to be a clean file containing no sensitive information. I do type a 70 words per min on a slow day slower typist 1 to 2 hours with the bug report submit to libreoffice and with the reproducible test in the training documentation before the instructions how to work around it.

    Notice something here when a new person is training up on the job they are now going though the training material running the tests so doing something useful for long to productivity by finding what workaround we are using we don't need be any more.

    Something that is overlooked is a workaround is normally slower than if the broken path though the application in fact works. Not keeping on top of if you need to be still using a work around can be costing the business you are working for more than 1/4 of the possible productivity. Yes that 1/4 of possible productivity I have see that improvement in a place using MS Office updating their training due to using workaround to MS Office defects that had not exists for a decade.

    This workflow for making reproducible tests with documentation on performing workaround to a defect for best productivity long term should be generic no matter the software you are using. Of course once you have made a reproducible test that contains no protected information it makes no sense not to submit it to places like libreoffice bugzilla.

    Originally posted by microcode View Post
    a mile in my shoes would clear this up for you, honest.
    I think i might have walked a few more miles in shoes that close to yours. That experience of walking a little more tells you the upfront cost of making the reproducible test to detect when a workaround is no longer need gives operational savings long term due to the inefficiencies of workarounds.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by oiaohm View Post
    Community edition does have the instant first impression as you are doing copyright infringement using it in enterprise like the first proposed personal edition did.
    Really its surprising to a lot of people how often community editions are in fact used in enterprise.
    This is exactly the issue I was addressing in my "blanket statement". It should not have been called community edition unless they had some ulterior motive at monetizing it. I am not entirely convinced this is going to be the end of it. I think TDF is going to sting us with LibreOffice in the future.

    Leave a comment:


  • microcode
    replied
    Originally posted by slacka View Post
    I am one of those guys and an OpenOffice user since before LO even existed. Doing a search of bugzilla with my email as reporter:"284 bugs found." Of those, only 47 haven't been resolved, all minor interop / feature requests. 81% Not bad for free community supported software. How many bugs have you reported? Searching for some issues that you described. I can't find any report describing those issues.

    Your "reading old bug reports" sounds like an excuse for someone who is rationalizing doing nothing to contribute and never reached out to the community. I could make this claim against any open source project with a searchable bug tracker. Yes, the codebase complex. Yet, despite not being a highly skilled C++ programmer, I have managed to fix several of the issues reported for a challenge. As a heavy users, I too have found crashing bugs. But I reported them. They were all triaged with a high priority, and quickly fixed.

    In my case, my high success rate is probably because I know how to write quality bug reports, include step-by-step, screenshots, stack traces, etc. I think in your case, it's a lack of trying to engage with the community.
    You being disappointed in me, without context, ain't gonna change a thing. You can tell us all how you would always build LO with symbols, and send your company confidential information away in core dumps every time; that is, this is a frequent occurrence; and still manage to get productive work done.

    The fact of the matter is, it's easy for you to say you would be able to generate heaps of useful bug reports, or at least ones that you could find in the kind of search that you did, but sometimes in order to remain in business, you need to focus on doing your job, and that means working around issues rather than expending maybe five to ten hours a week producing test cases and debugging.

    I appreciate that you have so many bug reports! wow! and it's good to have patches in, I appreciate it. And honestly, some day we'll have the budget to retain a full-time LO developer, but today is not that day.

    a mile in my shoes would clear this up for you, honest.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by kpedersen View Post
    Yep, I am not impressed. It has pretty much prevented the standard LibreOffice for use in enterprise deployments by name alone. No upper management will ever allow the word "community" to get installed on their IT images. This is obviously what the monetization drones at TDF were planning.
    Blanket statements are stupid most of the time. Some companies upper managements don't care if software has the word community in its name and you can in lot of cases get community versions in with enough description to management. More effort required but its possible. Community in name is way better than the first proposed name of "Personal Edition" that was proposed with 7.0 Libreoffice that name was absolutely a road block in enterprise setting because companies auditing software are going to see personal edition of something and start legal action without in fact checking if it legal to use in a enterprise setting or not so is 100 percent sure to cause disruptions to operations at some point.

    Community edition does have the instant first impression as you are doing copyright infringement using it in enterprise like the first proposed personal edition did.

    Really its surprising to a lot of people how often community editions are in fact used in enterprise.

    Leave a comment:


  • Danielsan
    replied
    Originally posted by kpedersen View Post

    Yep, I am not impressed. It has pretty much prevented the standard LibreOffice for use in enterprise deployments by name alone. No upper management will ever allow the word "community" to get installed on their IT images. This is obviously what the monetization drones at TDF were planning.

    These days, I think it would be easier to get the older OpenOffice on the images than a community edition of LibreOffice.

    Especially in my experience, "commercial" support has always been vastly inferior to community support. The community is interested in getting things to work. Commercial vendors just want to safeguard themselves behind the useless statements like "that is not supported at this time".
    I am not against TDF trying to make the project auto-sustainable, but at this point they had better to rebrand the suite with a total different name since they were unable to take control over the brand OpenOffice. From my point of view "commercial" means having a reference point for customers needs, if you are a commercial entity you can't go wandering through forums, chat, whatever in order to get support or an answer, you need a proper customer services.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by Danielsan View Post
    Eventually they decided to pursue this fallacious marketing strategy...

    It would be much wiser just having a version called "LibreOffice for Enterprise" to avoid such ridiculous "Community Edition" name.
    Yep, I am not impressed. It has pretty much prevented the standard LibreOffice for use in enterprise deployments by name alone. No upper management will ever allow the word "community" to get installed on their IT images. This is obviously what the monetization drones at TDF were planning.

    These days, I think it would be easier to get the older OpenOffice on the images than a community edition of LibreOffice.

    Especially in my experience, "commercial" support has always been vastly inferior to community support. The community is interested in getting things to work. Commercial vendors just want to safeguard themselves behind the useless statements like "that is not supported at this time".
    Last edited by kpedersen; 05 February 2021, 08:30 AM.

    Leave a comment:


  • Danielsan
    replied
    Eventually they decided to pursue this fallacious marketing strategy...

    It would be much wiser just having a version called "LibreOffice for Enterprise" to avoid such ridiculous "Community Edition" name.

    Leave a comment:

Working...
X