In news:[email protected], Alexander Thurgood <[email protected]> typed: > Le 25/08/11 19:37, Twayne a icrit : > > Hi Twayne, > >> I would love to tell MS to kiss my shiny metal butt, >> but I can't as long as some of these serious bugs >> continue to be ignored. One man can push one car; as >> you're doing now, but not three or four at the same >> time. All this is part of watching out for the future of >> LO and being able to say its users are solidly behind >> it. Anythng that doesn't work shouldn't have been >> released until it does work.
> Hi Alex, Thanks for the comeback. Please try to read this with the understanding that every word is meant to be positive and assstive to the LO project. I apprecate your come-back and don't expect a reply but if you wish to, feel free. I'm simply tryng to indicate the other side of the coin and I don't believe I'm alone in this. LO is in danger of going the same route as OOo did. My comments are in no way to denigrate any one in the development area specifically but one of the high hopes I had for LO was a very early-on promise from TDF/the LO grroup that such things wouldn't be tolerated in LO. I was specifically referring to NOT being like OOo was and ignoring early-on bugs. Quite a few OOo bugs still exist in LO's latest version and all in between versions AFAICT. In particular the large-file problems with images & tables, properly anchored per LO's instructions, are still present in LO. I like that the envelope issues were sort of taken care of by including templates for the most popular envelope sizes, but it's still several trips around Hogan's Barn if the templates one needs don't exist and if the center/left/right position of text for the addressee doesn't match what the prnter wants, it's still using oddball dimensonal references instead of simply a dimension from the top & left side of the envelope. And though I haven't looked on 3.4, having to set BOTH printer AND program paper sizes shouldn't be a requirement, ever. I only know of a few different hi-end processors, but none of them require touchng the printer paper size Settings. But I have learned to work out the how-to for envelopes should I need to, so t's not a huge issue to me personally, more like a big annoyance and time-waster. Others though ... The above and at least 6 more have been in OOo and continued on into LO without beiing fixed. Do you REALLY feel it's unfair to expect those things to have been fixed? Has there ever been a CALL for anyone to the dev masses to dig into these things? LO is an excellent program but it's stuck in the 80-20% rule; and that 20% makes it impossible for me to drop Word for the large files. Not good: I lose not only the ability to do away with Word or WP but I can't make LO a production-use app because of those things. > I fear you might have misunderstood how this project > functions. Most of the bugs get fixed as and when someone > decides that their "itch to scratch" is really starting > to annoy them. I think I understand how the project "functions" but of course have no experience in same. The real problem is, LO does not do what it says/implies/menus it can do and still has OOo bugs in it. The developers working as employees of > some of the software companies involved in the > LibreOffice project do not have set agendas with regard > to bug fixing as such that I know of - no doubt they have > their own internal work pressures and priorities to deal > with before sorting out bug X or bug Y. Most of the > volunteer developers participate in the project because > they like developing, i.e. for fun. There's no fun > involved in being told which bug to fix and why that > particular bug should trump all others, in that case, But again, has a CALL ever gone out for people to work on the "old" bugs? Like the ones that carried over from OOo? Doesn't anyone realize that the project cannot actually become a leader in the processor industry while it has those and other bugs? You seem to be saying that volunteers will write the original code but then won't stand behind it when parts of it don't function properly or at all. I WANT LO to succeed, but it cannot while such bugs are ignored and figured instead to be "good enough for government work". > they might as well go and develop something else. Door - ass. Have they been ASKED to work on their bugs? How can they not be expected to keep the code accurate if they simply develop, move on, and no one will fix the bugs? Aren't they ever given a LIST of the most serious bugs and the importance of working on them so LO can do what it says it can do without surprises. The > fact of the matter is that there are still too few > developers to be able to maintain the massive beast of > code which LibreOffice represents. I'm actually only currently interested in Writer here as my use of Calc is standard enough to not run into most other bugs in it (so far, anyway). If the above is a true fact, then perhaps the hype provided with each release of LO needs to be modified to reflect how you need more developers desparately instead of how you got xxx,000 developers in only xx weeks. I cringe whenever I see that anymore. Add to that the fact > that an even smaller number really know anything about > the code base and how it works as a whole (i.e. where > poking one thing causes the butterfly to explode on your > screen 50,000 miles away). "50,000 miles away" is irrelevant, really. Digitally that's no further away than the bldg next door these days. Much of my career was working with the Pacific Rim so I'm familiar with how far away places are not these days. > > If you can live with the way the project functions, then > you can live with the bugs. Jeez! Re-read what you said! That's what I'm trying to tell you: I cannot live with the way the project functions because LO does not do what it says it can do menu wise and documentation-wise, which is a mis-mosh of OOo and LO when you get to reading it. If not, then from a pragmatic > point of view you can either do it yourself, pay someone > to do it for you, or else come back to the project in a > few months/years time to see if things have moved on in > the direction you want. Right back at ya! Since you (LO) are providing the goods, then it's you should be doing those things. Facetious/rhetorical comments such as that show you're developing an ire over something I suspect has been purposely allowed to drop to the floor, same as OOo did. The only "direction" I want is for LO to do what it says/implies it can do. Personally, if I were capable of it, I would WANT to repair the code I wrote (and do so) whenever a bug is discovered. Having spent many years as R&D Management and then Director of R&D for a telecommunications company, I had both hardware and software teams, along with QA and IT under me. QA being a shared leadership between all departments. No software writer/author/engineer/manager EVER blamed anyone but themselves for the bug-fixing stage. That meant there were clear guidelines, human traits kept the bugs low and repaired as close to when discovered as possible. The estimates might be months off, but they are assigned and scheduled based on the resources available at any single time. If you've ever written embedded assembler code then you know how hard most of those people worked. > > Alex -- For unsubscribe instructions 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
