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 <[email protected]> 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: [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 > > -- To unsubscribe 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
