Suggestions to PTB

Can we expect there to be a "stop" any time soon in development in order to
attack and destroy some of the bugs and problems?
   Along with that, a bug list of what's being fixed, in process and and
fixed would go a long, long ways. I always read the change lists, but they
don't do a whole lot of good when I'm not familian with that bug, often
because the description is different than the accepted bug description.

HTH,

Twayne`

+1
Joe Conner, Poulsbo, WA USA

Hi Twayne,

Twayne wrote (24-08-11 21:44)

Can we expect there to be a "stop" any time soon in development in order to
attack and destroy some of the bugs and problems?
    Along with that, a bug list of what's being fixed, in process and and
fixed would go a long, long ways. I always read the change lists, but they
don't do a whole lot of good when I'm not familian with that bug, often
because the description is different than the accepted bug description.

Bugzilla and all other info is public.
It is relatively easy to query for bugs, fixed, enhancements etc.

A great page, with many queries predefined, is this one:
http://wiki.documentfoundation.org/BugReport_Details

Other useful info for your help:
http://wiki.documentfoundation.org/BugTriage
http://wiki.documentfoundation.org/BugReport
http://wiki.documentfoundation.org/QA

If you do that yourself, the developers have their hands free to continue fixing bugs, improving build, helping other devs etc. :slight_smile:

HTH,

In news:4E558B12.1030205@nouenoff.nl,
Cor Nouws <oolst@nouenoff.nl> typed:

Hi Twayne,

Twayne wrote (24-08-11 21:44)

Can we expect there to be a "stop" any time soon in
development in order to attack and destroy some of the
    bugs and problems? Along with that, a bug list of
what's being fixed, in process and and fixed would go a
long, long ways. I always read the change lists, but
they don't do a whole lot of good when I'm not familian
with that bug, often because the description is
different than the accepted bug description.

Bugzilla and all other info is public.
It is relatively easy to query for bugs, fixed,
enhancements etc.
A great page, with many queries predefined, is this one:
http://wiki.documentfoundation.org/BugReport_Details

Other useful info for your help:
http://wiki.documentfoundation.org/BugTriage
http://wiki.documentfoundation.org/BugReport
http://wiki.documentfoundation.org/QA

If you do that yourself, the developers have their hands
free to continue fixing bugs, improving build, helping
other devs etc. :slight_smile:
HTH,

--
  - Cor
  - http://nl.libreoffice.org

Being "Publc" has no bearing on this. Digging out the data I mentioned is a
huge job and sometimes impossible unless you're involved with the problem
itself. For instance, the image problems in a huge file; half the
entries/variations of the issue are not there. And many others. Maybe you
can sit there for hours making sure something isn't already reported, but I
won't do that. The tool just is not userfrendly for the types of information
displayed in the manner it needs to be displayed in.
    I take it your last sentence indicates I should do the fixes myself? No,
I can't do that. I doubt I would anyway, considering how hard it is to find
all of the complaints at once and get a nice, clean output to work to.

But back to my original comment: I think some of the more serious bugs need
a concerted effort to be fixed, especially in largish files with over x
images on this page, y image on those pages, and so forth.
   Also, when something is meant to apply to LO, it should NOT have titles,
headers about OOo that keeps popping up.
   Also, when you install a new version, the only place you see the full
version is under Help About. All the way thru the install process, it only
says "3" or "3.3", not 3.3.4 and so on. It's always been like that AFAIK.
Once started, you don't know whether you downloaded the right package or not
since it's a 3-digit rev and only one or two digits of the rev are given. I
call stuff like that "dirty" and needing to be swept or the caked mud
removed.

You're looking at a tree, not the forest. If the forest doesn't have the
right trees speces, there may be little to be harvested from it, which is my
case. I would simply like to see what's beng worked on clearly listed out,
along wth what's not planned, etc., as it is now but with an easier way to
bring all related bugs into one list.
   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.

HTH,

Twayne`

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.

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. 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, they might as well go and develop something else. 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. 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).

If you can live with the way the project functions, then you can live
with the bugs. 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.

Alex

Hi :slight_smile:
My answer is to keep whichever product you were using previously. Just don't
bother to upgrade it. Updates are a good idea but paying for a full upgrade is
unnecessary.

That way you can use LibreOffice most of the time but still go back to your old
one for bits&bobs.
Regards from
Tom :slight_smile:

Question: Which version of LibreOffice are you using? 3.3.3, 3.3.4, 3.4.1, 3.4.2? Many issues/bugs have been fixed in the 3.4.x line that has not yet been fixed in the 3.3.x line. 3.4.x reads MS formats better, is one of the fixes in that line.

I kissed MSO completely on Feb. 2010 when I choose Ubuntu as my OS on my new desktop. Then when LibreOffice came out I kissed OpenOffice.org goodbye.

I had been using MSO since Office 95 or 97, with the last one Office 2003.

As for releasing software with "bugs", this is normal, even with MS products. Many bugs are found in real world testing that happens on some systems, but not others. When these bugs are reported, they are placed on some type of "bug needing to be fixed list". Then it is up to the individuals who do the programming/developing [all volunteers] to choose which bug they have the skills to fix. I was a mainframe programmer. I was really good. I am not skilled in the programming needed for developing/fixing code for LibreOffice.

We all hope that the next release has the bug fixed that causes problems for some groups of users. Each release does its best to have as many issues fixed as it can with the fixed release schedule. With a fixed release schedule, it give the developers/helpers/bug-fixers a time line to do the work. Some bugs takes a long time to find the code that is the problem. I was once told that the code base for LibreOffice [and OpenOffice.org] is 100's of thousands of lines of code. Some are no longer used, while some are in need of "cleaning up". The LibreOffice developers took OpenOffice.org's open source code base and dedicated themselves to cleaning up all the messy and bad coding that was in the OOo code base. They did a lot of that and made improvements and more functions/abilities in their 3.3.0 release and came out with it before Oracle's people came out with OOo's 3.3.0 package. Plus, the tech-media stated that LibreOffice was a better product from the volunteers for The Documents Foundation/ LibreOffice than was put out by the paid employees [and some volunteers] at Oracle.

To be honest, I was told that many of the bugs that are annoying LibreOffice users can be traced back to the original messed up core coding and the fixes placed on top of that coding to make it work, instead of fixing that core code that is not working correctly. That is some of the hardest work for our volunteeers, to trace and fix the core coding that should have been fixed long time ago when it was developed during the time Sun Microsystems "owned" the OpenOffice brand.

Our developers are all volunteers and they are doing the best that they can. If Sun, and then Oracle, paid employees working 8 hours a day 5 days a week was working on developing/fixing/improving the OpenOffice.org product and did not do as good of a job putting out the 3.3.0 version of OOo as was put out with the all volunteer package of LibreOffice, we have to give our people a hand for all that they did to make LO better than OOo. Our volunteers are doing the best job as possible for volunteers and their limited amount of time after they come home from their paid jobs. They deserve out thanks for their dedication to making LibreOffice the best they can make it with the limits to their time to do the work.

Sorry for the band standing, but our volunteers are doing everything they are able to do to make LibreOffice the best free MSO alternative office package.

Question: Which version of LibreOffice are you using? 3.3.3, 3.3.4,
3.4.1, 3.4.2? Many issues/bugs have been fixed in the 3.4.x line that
has not yet been fixed in the 3.3.x line. 3.4.x reads MS formats
better, is one of the fixes in that line.

I kissed MSO completely on Feb. 2010 when I choose Ubuntu as my OS on my
new desktop. Then when LibreOffice came out I kissed OpenOffice.org
goodbye.

I had been using MSO since Office 95 or 97, with the last one Office 2003.

As for releasing software with "bugs", this is normal, even with MS
products. Many bugs are found in real world testing that happens on
some systems, but not others. When these bugs are reported, they are
placed on some type of "bug needing to be fixed list". Then it is up to
the individuals who do the programming/developing [all volunteers] to
choose which bug they have the skills to fix. I was a mainframe
programmer. I was really good. I am not skilled in the programming
needed for developing/fixing code for LibreOffice.

We all hope that the next release has the bug fixed that causes problems
for some groups of users. Each release does its best to have as many
issues fixed as it can with the fixed release schedule. With a fixed
release schedule, it give the developers/helpers/bug-fixers a time line
to do the work. Some bugs takes a long time to find the code that is
the problem. I was once told that the code base for LibreOffice [and
OpenOffice.org] is 100's of thousands of lines of code. Some are no
longer used, while some are in need of "cleaning up". The LibreOffice
developers took OpenOffice.org's open source code base and dedicated
themselves to cleaning up all the messy and bad coding that was in the
OOo code base. They did a lot of that and made improvements and more
functions/abilities in their 3.3.0 release and came out with it before
Oracle's people came out with OOo's 3.3.0 package. Plus, the tech-media
stated that LibreOffice was a better product from the volunteers for The
Documents Foundation/ LibreOffice than was put out by the paid employees
[and some volunteers] at Oracle.

To be honest, I was told that many of the bugs that are annoying
LibreOffice users can be traced back to the original messed up core
coding and the fixes placed on top of that coding to make it work,
instead of fixing that core code that is not working correctly. That is
some of the hardest work for our volunteeers, to trace and fix the core
coding that should have been fixed long time ago when it was developed
during the time Sun Microsystems "owned" the OpenOffice brand.

Our developers are all volunteers and they are doing the best that they
can. If Sun, and then Oracle, paid employees working 8 hours a day 5
days a week was working on developing/fixing/improving the
OpenOffice.org product and did not do as good of a job putting out the
3.3.0 version of OOo as was put out with the all volunteer package of
LibreOffice, we have to give our people a hand for all that they did to
make LO better than OOo. Our volunteers are doing the best job as
possible for volunteers and their limited amount of time after they come
home from their paid jobs. They deserve out thanks for their dedication
to making LibreOffice the best they can make it with the limits to their
time to do the work.

Sorry for the band standing, but our volunteers are doing everything
they are able to do to make LibreOffice the best free MSO alternative
office package.

Well said, the vast majority of people working on any aspect of LO are
volunteers doing the best they can with the time available.

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.

In news:4E577895.1020607@krackedpress.com,
webmaster for Kracked Press Productions <webmaster@krackedpress.com> typed:

Question: Which version of LibreOffice are you using?
3.3.3, 3.3.4, 3.4.1, 3.4.2? Many issues/bugs have been fixed in the
3.4.x line that has not yet been fixed in the 3.3.x line.
3.4.x reads MS formats better, is one of the fixes in that line.

I've used/looked at/tested out about every version since 2.whatever. They
all read MS formats fine for me; no x__ stuff used.
   I'll reviisit 3.4.x since I never downloaded it, but something on the
page made me take a pass on it but I can't remember what right now. I did
look at the change list though and the changes didn't affect the carriy-over
of bugs or anything on my list of problems. Seems like it was somethiing
about stability? I'll recheck and download it though & see for myself.

I kissed MSO completely on Feb. 2010 when I choose Ubuntu
as my OS on my new desktop. Then when LibreOffice came
out I kissed OpenOffice.org goodbye.

Those are my intentiions too but for the 'nixes I've come up against other
walls, namely a lack of apps and drivers both.

...

As for releasing software with "bugs", this is normal,
even with MS products.

But MS fixes their bugs and will continue to do so until 2014 in my case. I
am trying to get them to think about the problem that lost them a lof of
people in OOo, most of which are still in LO, and if you read over to
Alexander's post to me, there seems to be no plans to pick up the bugs and
fix them. They're dangerously close to repeating OOo's mistakes. LO is
better IMO but what it does not do is what it says it'll do.

  Many bugs are found in real world

testing that happens on some systems, but not others. When these bugs are
reported, they are placed on some type of "bug needing to
be fixed list".

According to Alexander, no, that's not so. Again, see his post to me. Devs
only want to write new code, not fix code, apparently not even their own.

  Then it is up to the individuals who do

the programming/developing [all volunteers] to choose

No, not all volunteers. Several companies are actually contributing to the
LO project. There is an excellent bit of support behind LO that way.

which bug they have the skills to fix. I was a mainframe
programmer. I was really good. I am not skilled in the
programming needed for developing/fixing code for
LibreOffice.

Same here; my background/time doesn't allow me to be of any real help to
them. I couldn't fix bugs if I had to. I want LO to succeed, but ... when
OOo bugs are still happily sliding along all cozy in the code, well, that
was OOo's problem, too, and it appears to be being repeated at LO.

HTH,

Twayne`

In news:1314348038.23154.YahooMailRC@web24101.mail.ird.yahoo.com,
Tom Davies <tomdavies04@yahoo.co.uk> typed:

Hi :slight_smile:
My answer is to keep whichever product you were using
previously. Just don't bother to upgrade it. Updates
are a good idea but paying for a full upgrade is
unnecessary.

That way you can use LibreOffice most of the time but
still go back to your old one for bits&bobs.
Regards from
Tom :slight_smile:

That's pretty much what I do, Tom;

Cheers!

In news:1314360010.75144.YahooMailRC@web24103.mail.ird.yahoo.com,
Tom Davies <tomdavies04@yahoo.co.uk> typed:

Hi :slight_smile:
I agree with that but there is some minor additional
complexity that doesn't really affect the main points of
the post but might be interesting.

Not all "our" devs are volunteers. I think most are,
possibly "almost all" but some are employees of the
various companies seen listed on "our" supporters page
http://www.documentfoundation.org/supporters/
The employees probably don't have much say in what they
work on. I would guess that they are told what to do or,
if they are lucky, get pointed at a particular area.

There is a list of people that are credited with having
worked on code but the stats are a bit rough and it's
only up to about mid-June
http://www.libreoffice.org/about-us/credits/
I have a feeling the employees might have been missed off
that list although my feeling is that they should be
included too. There is at least one so i could be wrong.
Probably some people have been missed off but might get
included next time.

The code was (maybe still is in places) messy because the
project is over a decade old. Things generally need
cleaning occasionally and there was a plan being
developed under Sun to do a massive clean-up. The move
to TDF meant that could finally be started on. I heard
that the code is now 20-30% lighter! Regards from
Tom :slight_smile:

Hi Tom,

Just to clarify, I'm not saying that anythng done to date is useless or
otherwise unedesirable in any way. All I want is for the simple, original
bug list of bugs that have always been there need to be fixed. LO should do
what it says it'll do. I seem to be getting back noise that says bug fixing
is of no interest to anyone on the dev teams. That bothers me because it
prevents a huge number of people from doing more than testing LO for a few
days and stopping when such up-front, obvious a lst of bugs as exists
becomes apparent.

In news:4E577895.1020607@krackedpress.com,

...

As for releasing software with "bugs", this is normal,
even with MS products.

But MS fixes their bugs and will continue to do so until 2014 in my case. I
am trying to get them to think about the problem that lost them a lof of
people in OOo, most of which are still in LO, and if you read over to
Alexander's post to me, there seems to be no plans to pick up the bugs and
fix them. They're dangerously close to repeating OOo's mistakes. LO is
better IMO but what it does not do is what it says it'll do.

  Many bugs are found in real world

testing that happens on some systems, but not others. When these bugs are
reported, they are placed on some type of "bug needing to
be fixed list".

According to Alexander, no, that's not so. Again, see his post to me. Devs
only want to write new code, not fix code, apparently not even their own.

On the OOo releases list you could nominate a bug as a 'blocker' on the
list. LO doesn't have the same (that I'm aware of), but they do have a
'most annoying bug' bug report for releases going forward. As far as I
can tell anyone can add to that bug report with their own bug report
addition. See:

https://bugs.freedesktop.org/show_bug.cgi?id=37361
[LibreOffice 3.5 most annoying bugs]
<quote from first comment>
This is the Meta issue to track most annoying bugs for the release of
LibreOffice 3.5.x releases. It helps developers to concentrate on bugs
that are important for users. Also it helps users to be aware of
potential problems.

If anyone wants to raise an Bug for the release, please add the Bug ID
as dependent Bug here to the Meta Bug in field "Depends on".
Additionally please leave a comment here why you think that the bug
should be privileged.

See also http://wiki.documentfoundation.org/Release_Criteria
and http://wiki.documentfoundation.org/ReleasePlan
</quote from first comment>

So if you've a particular bug that you'd like to see fixed add it
there... of course after first reading:
http://wiki.documentfoundation.org/Release_Criteria
That does include information on blockers, but I've not found any wiki
pages on 'most annoying bug' criteria (yet). So I reckon that until
someone defines the MAB criteria, add your MAB to 37361.

...

Hi :slight_smile:
Yes, it's not an idea i invited out of thin air :wink: It keeps being confirmed
too. I really like it when the old familiar system is an OpenSource one and
just a variant of whatever i am migrating too.

At a guess it will be easier for people to fix long-standing bugs now that the
code is cleaner and there are more people with experience of working with the
code. I think what you are asking for is going to just happen naturally
anyway.

But i do agree that it would be nice to know that there are occasional posts to
the devs list to point out that there are some older bugs that it would be good
to work on. It probably does happen. They probably already have a system for
it but it would be nice to report that to the other lists occasionally, such as
this one. I don't think it was clear that your main concern was a lack of
verifiable info.

Regards from
Tom :slight_smile:

For 3.4:
https://bugs.freedesktop.org/show_bug.cgi?id=35673
[LibreOffice 3.4 most annoying bugs]

In news:j39a1l$oeo$1@dough.gmane.org,
NoOp <glgxg@sbcglobal.net> typed:

In news:4E577895.1020607@krackedpress.com,

...

As for releasing software with "bugs", this is normal,
even with MS products.

But MS fixes their bugs and will continue to do so until
2014 in my case. I am trying to get them to think about
the problem that lost them a lof of people in OOo, most
of which are still in LO, and if you read over to
Alexander's post to me, there seems to be no plans to
pick up the bugs and fix them. They're dangerously close
to repeating OOo's mistakes. LO is better IMO but what
it does not do is what it says it'll do.

  Many bugs are found in real world

testing that happens on some systems, but not others.
When these bugs are reported, they are placed on some
type of "bug needing to
be fixed list".

According to Alexander, no, that's not so. Again, see
his post to me. Devs only want to write new code, not
fix code, apparently not even their own.

On the OOo releases list you could nominate a bug as a
'blocker' on the list. LO doesn't have the same (that I'm
aware of), but they do have a 'most annoying bug' bug
report for releases going forward. As far as I can tell
anyone can add to that bug report with their own bug
report addition. See:

https://bugs.freedesktop.org/show_bug.cgi?id=37361
[LibreOffice 3.5 most annoying bugs]
<quote from first comment>
This is the Meta issue to track most annoying bugs for
the release of LibreOffice 3.5.x releases. It helps
developers to concentrate on bugs that are important for
users. Also it helps users to be aware of potential
problems.

If anyone wants to raise an Bug for the release, please
add the Bug ID as dependent Bug here to the Meta Bug in
field "Depends on". Additionally please leave a comment
here why you think that the bug should be privileged.

See also
http://wiki.documentfoundation.org/Release_Criteria
and http://wiki.documentfoundation.org/ReleasePlan
</quote from first comment>

So if you've a particular bug that you'd like to see
fixed add it there... of course after first reading:
http://wiki.documentfoundation.org/Release_Criteria
That does include information on blockers, but I've not
found any wiki pages on 'most annoying bug' criteria
(yet). So I reckon that until someone defines the MAB
criteria, add your MAB to 37361.

...

Thanks, Noop; I'll look into that tomorrow.

Twayne`

Hi Twayne,

But MS fixes their bugs and will continue to do so until 2014 in my case. I
am trying to get them to think about the problem that lost them a lof of
people in OOo, most of which are still in LO, and if you read over to
Alexander's post to me, there seems to be no plans to pick up the bugs and
fix them. They're dangerously close to repeating OOo's mistakes. LO is
better IMO but what it does not do is what it says it'll do.

Oh bugs do get fixed, just not necessarily the ones that any given
(sub)set of users might want fixing. An example : Base bugs - of the
more than one hundred Base bugs declared on bugzilla since the inception
of LibreOffice, only a very few have actually been fixed. The reasons
for this are multiple, but nonetheless the reality is there.

As for the longstanding OOo bugs, well like I said, a developer might
decide to try and fix one or the other because he/she has encountered
its annoying behaviour and is so hacked off about it that he/she decides
to try and sort it out.

According to Alexander, no, that's not so. Again, see his post to me. Devs
only want to write new code, not fix code, apparently not even their own.

Yes and no. It is more motivating to develop one's own code/features,
than to fix other people's bugs, especially ones where the origins of
the bug's birth may be obscur or go back to a time where programming
decisions or decision rationale was poorly documented. As for fixing
their own bugs, usually I would say that most of the devs on this
project actually take pride in doing so. However, the bugs you seemed to
be referring to as I understood it are ones that occurred during
Sun/Oracle OOo stewardship. Who is to know whence those bugs came, Sun
kept a very tight lid on outside submissions, refusing quite a few from
other contributing bodies, going so far as to even write replacement
code for that previously submitted by others to be in line with its
stewardship policy of the moment.

When a final release is targeted to go public, a list of stopper bugs is
drawn up in the hope that some will be easy to fix and thereby cleared
up rapidly. This is often the case with bugs introduced during
development since the inception of LibreOffice. However, where some of
the bugs are very old, the investment needed to correct them is often
perceived as greater than the benefit to be obtained, in fact greater
even than rewriting the whole corresponding code module. As such large
rewrites are more future oriented than bug catch-up, it is normal then
for such bugs to be placed on standby, pending further new development.
I might not like that any more than you (especially with respect to Base
in my particular case), but I can understand it from both a human
motivation and ressource allocation point of view.

Alex

Hi Twayne,

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.

I'm at times a very open critic of the project myself.

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.

Yes, I think initial marketing spin when the project started made users
of OOo who switched to LO have very high expectations - some of which
have clearly not been met IMO.

   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.

Agreed, it is worse on Mac OSX, where within LO certain printer options
are crippled, making printing envelopes and anything bar a normal letter
like jumping through rings of fire.

   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 ...

Agreed.

   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?

Not at all. I started going through the envelope bug issues the other
day checking to see what I could or could not reproduce. Like I said
above, print options within LO on Mac are somewhat limited compared to
other platforms it seems, so that makes testing/reproducing for me nigh
on impossible.

   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.

Which I perfectly understand, and as a pragmatic business user myself, I
still recommend OOo 3.2.1 for many things because the "progress" that
has been made in LO does not yet outweigh in my eyes the perceived or
real disadvantages and bugs that existed in OOo 3.2.1 (mailmerge being
one of 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.

Yes, I would agree partially - but then, with a truly free, open source
project, you can not make anyone do anything. Ultimately, as you say, it
will be a law of the jungle thing. If too many "niche circumstance"
users drop the product, then LO will shrink to be just another "close
runner up" to Word/Excel/Powerpoint, along with KOffice, Calligra and
all the other wannabes.

But again, has a CALL ever gone out for people to work on the "old" bugs?

Of course and some of them do get fixed, eventually.

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?

There is a tendency within the developer community to admit the
phenomenon known as "bit-rot" over time (which personally I find rather
worrying), and that the effort fixing an old bug may not be worth it
when a whole new module of code could be developed that would also deal
with the underlying problems having caused the old bug in the first
place. However, the new code development will only take place in the
future as and when resources can be made available. Catch 22 :-/

   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".

No that is not what I said, or at least not what I meant. Within the
framework of LibreOffice, most developers who create bugs through their
own coding efforts take pride in fixing the bugs they cause too. Bear in
mind however, that the LibreOffice project is not yet even a year old,
which brings us back to the promises made in the initial mission
statement of "preserving a 10 year investment in the OpenOffice.org
project" - which turned out not to be true, I'm afraid - and I'm the
first to admit that I too was disappointed by this). Once again,
LibreOffice is not OpenOffice.org - it is an easy cop out, in view of
the marketing hype, but that's how it is - the bugs made in a separate
project, i.e. OpenOffice.org, will not necessarily get fixed in
preference to ones created in the current LibreOffice project since it
was created last September.

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.

As already pointed out by others, there is a list of the "most annoying
bugs" nominated as blocking for each release. ANYONE can nominate their
pet LibreOffice bug (i.e. one in the LibreOffice bugzilla database) as a
blocker, but that doesn't necessarily mean that it will be fixed or even
ultimately considered a blocker (I have personally had several "blocker"
bug reports requalified as "can not block the release" or "affects only
a small group of users", etc, etc. This is where I would agree that the
boundaries between who decides what gets done and in which order are
still IMO undefined, or subjective, to say the least.

"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.

I was referring more metaphorically to holistic thoery than actual
distance :wink:

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.

I know perfectly well what I wrote. I participate in this project
because I want to, for reasons which are my own. I do not develop or
write code. I currently do bug triaging, occasionally write
documentation, and help out on the user mailing lists. I hold no
administrative office, elected or directorial position within the
project, nor do I have any desire to as yet, despite having been
propositioned to become a community member. Much as this project likes
to wears its "freedom" on its shoulder, so do I value my own freedom
with regard to my commitment to the project (indeed as with any other
open source project).

I like open source projects as a principle, but I'm not an extremist
with regard to any one in particular, and ultimately have a business to
run, with tough decisions to make like in any other business enterprise.
If the software I would like to use isn't fit for my purpose for
whatever reason, then I will change to one that is. That might even be
MS Office in the future, who knows, but I've managed to stay away from
it for nearly 20 years now, so currently I feel that would be unlikely
(but not impossible). Some might call that cynical - fine by me,
"whatever floats your boat" as they say, I prefer to see that as pragmatic.

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.

On the contrary, I consider myself to be far more of a consumer of the
"goods" as you put it than a provider. The comments I have made to you
here and previously reflect my own experience and understanding of the
project so far, in its short existence. I can only add what I have been
told by those on the steering or engineering committees : "If you want
to influence the direction that the LibreOffice project takes, become a
"member". "Membership" allows you to participate in board elections and
other administrative aspects of the project. You can become a member by
showing how you have helped the project to move forward. I believe there
is even a page on the wiki that explains how to do that :

http://wiki.documentfoundation.org/CommunityBylaws#Membership

I think you will understand from the above that I'm being neither
rhetorical or facetious - I am merely a user of the product, I help out
when I can to the extent of my capabilities, that is all, my sphere of
influence is close to zero, but that has not stopped me from voicing my
dissatisfaction when I thought it was appropriate.

Alex

If Ford did to automobiles what you suggest is proper conduct for
software development, Ford would be out of business.

If during the normal course of using a product (Ford car), the brake
pedal would periodically fall off for no apparent reason, consumers
would be outraged, Ford would put a team on it and it would get
corrected. I'm certain of it.

I and many other people use OO/LO and periodically get file corruption
rendering the document useless. I'd say that's roughly the equivalent of
the brakes falling off a car. I've reported this for years and
corruption issues persist with identical symptoms from one release to
the next, from OO to LO.

I can understand your position for nuisance items, but file corruption
is the software having a brain aneurysm. It needs emergency attention
right NOW.

I'm a professional software developer (mainframes & PC's) and I've
managed software teams to produce products sold for hundreds of
thousands of dollars per copy. The market incentive to produce a
reliable product is what is missing in open source. No ones butt is on
the line - no accountability.

As the old saying goes, "Lead, follow or get out of the way." LO has
positioned itself as an alternative office suite. It has an obligation
to produce a reliable product. Period. If that can't be achieved year
after year, then the management of that project, or lack of it is at fault.

Stop writing code. Get the project organized, possibly even create a
branch for profit, and get on with it or get out of the way.

In news:j3ap2n$4u8$1@dough.gmane.org,
Alexander Thurgood <alex.thurgood@gmail.com> typed:

Le 26/08/11 19:14, Twayne a icrit :

Hi Twayne,

But MS fixes their bugs and will continue to do so until
2014 in my case. I am trying to get them to think about
the problem that lost them a lof of people in OOo, most
of which are still in LO, and if you read over to
Alexander's post to me, there seems to be no plans to
pick up the bugs and fix them. They're dangerously close
to repeating OOo's mistakes. LO is better IMO but what
it does not do is what it says it'll do.

Oh bugs do get fixed, just not necessarily the ones that
any given (sub)set of users might want fixing. An example
: Base bugs - of the more than one hundred Base bugs
declared on bugzilla since the inception of LibreOffice,

...

Alex,

Hope this gets to you; I've never had a lot of luck with responses to the
List (I read gmane's NNTP).

ANYway, I don't disagree with anything you said, but figured it wouldn't
hurt to voice my opinions. Writer is what I use most right now and yeah,
I've seen stats on Base but I'm a one at a time kind of person <G>.
   Although I still think there is more that could be done I don't see any
dead horses around, so my stick is still put away. From my vewpoint though,
there needs to be a stop point where Writer et al are brought up to the
point where 90%+ of the users can have a relatively bug-free environment and
minimum, work-arounds pointed out for those that can't yet be fixed, for
whatever reason.
   It would save exasperation on the part of your users and put a draw to
the product that hasn't yet been seen. As an example, I don't believe it's a
product that's ready for prime time at colleges or most businesses right
now. I know of two around here who tried to implement LO and previously an
OOo. They have since tossed it out and gone back to WP and MS respectively.
A third one I know of is OK so far and not having any problems because they
arean't asking it to do much more than secretarial jobs. That's only an
experience of 3, but when you consider it, t must translate to many more. I
only know this because I have business dealings with those three places. I
might sound pretty negatve, but I want LO to become big time and I don't see
how that can happen.

Thanks for listening!

Twayne`