Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


Hi :)
I think there might be a few different things going on there.

Firstly i have no idea how the devs think or work.  Clearly they think very
differently from most users.  What seems obvious and makes sense to us is
clearly 'wrong'.

To me, i'd agree with you, that if it's annoying in one branch and still
exists in the next then it's likely to be annoying in that branch too.
Clearly the devs don't think like that at all.  Trying to argue the point
is likely to get you in trouble here.  It's one of the reasons i am under
moderation or even chucked off mailing lists here.


What normal users, like us, tend to think of as bugs or stability issues is
often technically called something else.  So far i can only think of 5 but
i'm sure there are more.  The most frequent type of 'bug' reported by
normal users is often really a "broken feature".  That is very different
from what the devs would call a "bug", as far as i can make out.  It's
certainly NOT a stability issue.  Very few bugs are anything to do with
stability.  So when something is broken we have to try to figure out
whether the devs would call it;
1.  something that behaves differently from certain other programs (but the
LO way might well be better)
2.  something behaving weirdly
3.  something that changed behaviour
4.  a broken feature/thing
5.  a bug
or
6.  a bug causing a stability issue

Sometimes there is no practical difference between 1 and 2 or it might be
just a difference of opinion, ie immensely long and argumentative threads.

We rarely discuss items such as 3 because we mostly just adapt or new
people are unaware it used to be any different.  Sometimes it's intriguing
or interesting.  Occasionally a change in behaviour only happens to 1
person and indicates weird things going wrong which all gets fixed by
renaming the User Profile.  More usually it's a positive thing that a few
people find annoying but most people either don't care or find it an
improvement.  (like when some obscure graphs got smoothed out in a better
way that gave better results and looked nicer (i think in 3.4.0)).

Mostly what we get here is 4.  A long running feature/thing suddenly stops
working in a new branch.  We try renaming the User Profile jic it's that
(despite it seeming really unlikely) and post a bug-report only to find we
gets loads of aggro from devs telling us to fix it ourselves or that
individuals should pay to get it fixed.  Sometimes it gets all bitter and
unnecessary blaming individuals who are all trying to do a good job but
that sometimes leads to unexpected complications "out in the wild".  Maybe
we should post these as "feature request"s and pretend that it's new in
order to avoid hurting anyone's feelings?

Very occasionally we get a real 5 but it's actually quite unusual, and
quite difficult to spot since everything else is also called by the same
name by most normal users.

We seem to get a real 6 much more often than a real 5 but then it turns out
to be a Java or other 3rd party issue.  We still quite often help fix it.
I think one time it turned out to be a wobbly graphics card and another
time a defective fan but usually it's just a case or trying a different
version of either Java or LibreOffice.


Unfortunately pretty much all those things can only be reported by posting
a bug-report.  Feature requests use the bug-reporting systems.  In that
system one of the drop-downs has an option labelled "feature request".  We
can often help with most of them, especially 1 and 2 and even 6 but the
only route to escalate problems is to post a bug-report.  I tried liaising
with other mailing lists to see if they could help with other issues but it
earned me a bad reputation so i wouldn't advise it!


Now is the ideal time to take the 4.4.0 for a test-drive.  It's the number
1 time that the most devs are looking for problems in the new branch.  It's
also THE best time to get stuff fixed.  New stuff is still fresh in
people's minds so they might instinctively put their finger right on the
source of the problem even if the code seems fine to everyone else.

So, please do take the 4.4.0 for a test-drive now and post bug-reports
about whatever you find (maybe ask here first maybe) even if it doesn't
really seem to be a bug and seems to fall into one of the other categories
i made-up on the spot there or some other not-quite-a-bug-really type
category.

This is also a good time to join in with the QA team to help do routine
office type work to help make sure the different bugs are all neatly filed
and stuff so that the devs can focus on the coding rather than getting
bogged won with filing and routine stuff.
Regards from
Tom :)





On 21 November 2014 20:07, CVAlkan <foberle@enteract.com> wrote:

Hi:

I'm using 64 bit Ubuntu 14.04 with a parallel installation of LibreOffice
Version: 4.4.0.0.alpha2+
Build ID: d273a60bfdbf9bb7623bed38667ec0647753157c - TinderBox:
Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-20_03:05:21 -
Locale: en_US

I installed this in parallel with my 4.3 installation mostly because of
having been burned so many times in the past by new bugs, but the recent
commentary on what are apparently "fixes" to the pdf export function
compelled me to try this alpha just to see; I often need to transfer pdfs
of
documents and reducing sizes is important. (I often wondered why the files
were so huge, but never thought to question the sizes)

I can confirm that the 4.4 alpha does indeed produce significantly smaller
pdf sizes with (as far as I can tell) the same quality as earlier versions
have produced.

BUT - as usual, there is a huge caveat ... When I first tested this, I
thought that perhaps the smaller size resulted from the fact that Writer
just left out quite a few of my graphics, which didn't appear in the pdf. A
little further exploration, however, showed that they were not visible in
the document either, although were in fact still there - just hidden under
totally (and newly) opaque frames. Thinking that maybe this was a result of
some sloppy formatting on my part, I changed a few of the frames to 100%
transparency - permitting the graphic, which was already marked as "on top"
to be displayed in Writer and saved the file (yes - under a new name - I
have used betas before). I generated a new pdf and - viola - the graphics
whose frames I had "fixed" showed up in the pdf.

However, when reloading the document, all of the frames were again totally
opaque. To cut this short, I checked and changed the style for frame
contents to 100% transparency, but that did made no difference in the
results.

So, as they say (or paraphrase), the developers giveth and the developers
taketh away.

Which brings up an interesting and related question ... On the "most
annoying bugs for 4.3 section (under DEV), there are several comments where
a moderator (?) chastised several folks for posting about 4.2 bugs,
although
the submitters all seemed to be reporting 4.2 bugs that were still present
(and annoying at least to them) in 4.3. This is confusing to me, and I
can't
quite figure out what the development process is. I poked around, but all
the discussions I've run across are not at all clear. Is there a
description
somewhere about how all this works?

My questions - in no particular order - are:

Why would a bug that is annoying in one version (e.g. 4.2 above) not be
given some sort of priority or at least inclusion in a later version's
(e.g.
4.3) list?

Is there any form of regression testing involved in assessing bug fixes?

Are these "versions" treated as separate "forks" and handled by separate
developers?

How do "fixes" in one version make their way into other versions? And how
are dependent "fixes" tracked to insure that something that fixes one
branch
doesn't improve but still break a different branch?

I guess my overall observation based on using LO since somewhere in the
early 3.x versions is that every time some bug that annoys me (or precludes
me from being able to use earlier documents without having to tweak the
heck
out of them) is "cured," some other feature that previously worked just
fine
becomes broken.

I'm not trying to be a wet dish rag here - and I certainly appreciate the
level of work involved, but I can't help but suspect that there is some
issue with the PROCESS of development and testing when these sorts of
things
continue to happen. That's why I'd like to understand more about the whole
process.

Thanks for listening ...




--
View this message in context:
http://nabble.documentfoundation.org/Comments-on-pdf-file-size-in-4-4-alpha-and-a-new-bug-tp4129842.html
Sent from the Users mailing list archive at Nabble.com.

--
To unsubscribe e-mail to: users+unsubscribe@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



-- 
To unsubscribe e-mail to: users+unsubscribe@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.