[libreoffice-users] Re: Suggestions to PTB

In news:j37dom$l28$1@dough.gmane.org,
Alexander Thurgood <alex.thurgood@gmail.com> 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: users+help@global.libreoffice.org
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