| bigpod | alkisg: well flavours/distros sometimes patch in things or affect change with compile flags so some bugs related to software can be flavour/distro specific | 00:00 |
|---|---|---|
| guiverc | thanks bigpod | 01:09 |
| alkisg | bigpod, indeed, hence the "test if it happens in other distributions" | 02:37 |
| alkisg | That part should be up to the reporter, not the bug triager or maintainer | 02:38 |
| guiverc | alkisg, Getting a end-user to verify on another OS they don't use I think it asking a bit much of end-users; I'm happy if end-users make and effort & just report. If their bug report is understood, I don't mind helping verify etc.. ie. a 'team' effort I think is good | 04:07 |
| alkisg | guiverc: there is one maintainer per 1000 users. So yes, I think that asking the users to help more is how to save launchpad | 04:28 |
| alkisg | Booting a live cd and testing if the bug exists elsewhere takes e.g. 5 minutes. It's not a very big deal. | 04:29 |
| alkisg | While when the users see that in 90% of the cases, noone in launchpad answers to their bug reports, or just puts their bugs to "does it still happen? => incomplete" every year, that's just nonsense | 04:29 |
| alkisg | It was so annoying to have to say "yes, it still happens => state = new again" every year, and see no maintainer work on the bug, ever | 04:30 |
| alkisg | Issues on github projects DO get answered, because they're managed by the people that write the software | 04:30 |
| alkisg | If the issue is in an ubuntu-specific patch, then it should be filed on launchpad, and there the person that wrote the ubuntu-specific patch WILL care more to handle it | 04:31 |
| alkisg | It's very important that bugs reach the person that writes the code. Currently launchpad does NOT help there at all. | 04:31 |
| alkisg | At the very least, there should be a clear procedure to tag bugs as "ubuntu-specific: needs to be solved here", or "distro-agnostic: please report it upstream, and put a bug link here (launchpad does have upstream bug tracker links" | 04:38 |
| alkisg | Currently people don't even realize where the bug will be solved... | 04:38 |
| alkisg | Bug triagers (as launchpad calls them) should be able to help with this task, when simple users can't. But there are no instructions to do that. | 04:39 |
| guiverc | a large number of valid & very true points alkisg | 05:08 |
| alkisg | 👍️ | 05:09 |
| guiverc | upstream always want the latest; so they'd need documentation to tell them how to get a daily with the latest code (not always lubuntu though; I find tumbleweed best as it's rolling; but I don't know if dailies exist for it; nor where to find them).. nor with specific software to be tested pre-installed.. there's no doco telling users where to look for, or what do to I ack. and many users would likely help with that! but not all | 05:11 |
| alkisg | Many upstream projects, like libreoffice or gnome or the kernel, have a field "happens on version: X" when filling out bug reports. It's not always necessary to reproduce on the latest version | 05:15 |
| alkisg | But even so, when I report something upstream with my ubuntu version, a bit later an arch user comes in and triages and says "verifying that it happens on the latest upstream version on arch linux" | 05:16 |
| alkisg | I.e. at that point, users of different distributions cooperate to triage the bug; and then the software maintainer is usually more inclined to answer | 05:16 |
| guiverc | ack. depends on project (re: version) | 05:16 |
| guiverc | it's really WONDERFUL to see users co-operating; acting as community | 05:18 |
| alkisg | https://packages.ubuntu.com/impish/xorg => the "report a bug" there links to launchpad only. It would be nice to raise awareness that there are 3 maintainers involved: upstream xorg, debian xorg packagers, ubuntu patches on top of debian xorg | 05:19 |
| alkisg | And, to ask bug triagers to forward the issue appropriately. Now we can't even find that information, the links of these 3 maintainers, on launchpad | 05:20 |
| alkisg | Anyways, all I'm saying is that it would be nice to start such a discussion somewhere where launchpad maintainers would listen and modify the UI accordingly | 05:21 |
| alkisg | I would be more than happy to participate in such a discussion, but I've too much on my plate to start it myself | 05:21 |
| guiverc | the detail on your link is there for those that understand; it links to Debian X Strike Force; even has link to Xorg homepage; but most wouldn't notice it | 05:22 |
| Mekaneck | superkuh: makes no sense.... MATE = Gnome 2. At least it has been forked from Gnome 2 and being continued. They only switched MATE to GTK3. | 07:17 |
| superkuh | Yep. And then in 2014 they started removing features from GTK3 and so MATE lost them too. | 11:31 |
| superkuh | They being GNOME. mclasen in particular. | 11:32 |
| iLinux-OS-User | You can add features in Mate via Apps executing Scripts & Caja Actions. | 11:34 |
| iLinux-OS-User | iLinux OS developers have done a great job on this: https://ilinuxos.com/control-center.html - https://ilinuxos.com/amazing-right-click-menu-and-super-actions.html | 11:35 |
| Aro | ^ Is that guy loitering and soliciting? | 13:57 |
| bigpod | alkisg: im not sure it should be on end user who encounters a bug to test if this bug is for upstream or distrospecific | 15:28 |
| alkisg | bigpod: what you're saying is what already exists in launchpad. Currently it's not working. | 15:45 |
| alkisg | I mean, as well as it should; now more than half of the bugs get no feedback | 15:45 |
| alkisg | If ubuntu had thousands of paid bug triagers, then sure it could work; those would be the ones to test if the bug is distro-specific or not. Noone else would... | 15:47 |
| alkisg | (and then the users would report the bug upstream anyway, to provide logs and feedback) | 15:53 |
| iLinux-OS-User | Ubuntu is a bug factory nowadays... | 16:19 |
| alkisg | As opposed to? | 16:22 |
| alkisg | 95% of the bugs are upstream bugs, they affect everyone | 16:22 |
| sixwheeledbeast | how can you say that, what specific Ubuntu only packages have these "bugs" | 16:28 |
| bigpod | alkisg: sure but at the same time we should not and can not expect of end users to do this. | 16:29 |
| bigpod | because reality is most bugs are encountered when you want to get things done so if people report a bug at all(which forcing them to check whether bug appears in other distros will make a barrier to entry in reporting bugs higher) they basicly go report then they continue doing their work if that means that becuase of bug preventing them to do what | 16:32 |
| bigpod | they planed they just do something else | 16:32 |
| alkisg | bigpod, at that point they shouldn't report it at all | 16:42 |
| alkisg | If the bug won't reach a maintainer that will solve it, it's wasted effort for everyone | 16:42 |
| alkisg | 10 years ago when I hadn't yet understood how launchpad works, I reported many many bugs, and a lot of them were just stalling there. I was so disappointed that for a while I considered stopping reporting bugs | 16:43 |
| alkisg | I imagine that this happens to many users. Fortunately, I understood how it works later on, so I started reporting bugs only to their "upstreams", (even to launchpad when it's upstream for something) | 16:44 |
| alkisg | That's what I'm proposing, to raise awareness so that user effort isn't wasted, and they don't get disappointed, and they don't step participating because of bad organization | 16:44 |
| alkisg | Btw if Linux ever gets more apps, like e.g. android play store, then what I'm proposing will be the normal thing to do; launchpad won't be able to handle millions of apps. Microsoft/windows doesn't accept bug reports for 7zip; google/android either; so advising launchpad users to contact 7zip directly wouldn't be unusual | 16:51 |
| vkareh | the difference is shared libs - each distro tracks their own versions (sometimes with different patches) of libs, and bugs often happend _specifically_ because that. Upstream devs cannot really do much about it until downstream can confirm that it's not on their side. | 16:53 |
| vkareh | mate has plenty of bugs reported upstream that I cannot reproduce, no matter what I try - it only happens on 1 or 2 distros, and sometimes within installations of the same distro the bug may or may not be present. Then we advise them to report downstream | 16:54 |
| alkisg | Absolute bug confirmation only happens when the offending code line is pinpointed. If the bug is in an Ubuntu patch, of course it should be reported to launchpad; but then it wouldn't happen in another distro, which is the first confirmation step | 17:09 |
| alkisg | The whole point is "try to report it to the one that wrote the code of the offending line", whatever that entails | 17:10 |
| alkisg | Currently launchpad doesn't help with that | 17:10 |
| bigpod | ok but still it shouldnt be on user to test if bug exists in other distro sorry maybe launchpad should not even have bug tracking functionality and all bugs to be reported to upstream but guess what we get to same problem just from other side so unless we put a lot more work on users themselfs which we absolutly should not no matter what you think | 17:20 |
| bigpod | someone somewhere will need to classify whether bugs should go to upstream or be fixxed in downstream. | 17:20 |
| bigpod | so if you ask me launchpad needs easy way to send the bug to upstream(maybe it even has that IDK) | 17:20 |
| bigpod | and personaly i think most of bugs should first land in downstream for reason chared by vkareh and then be moved to upstream. you know why windows and or android dont accept bug reports for apps not owned by them becuase its upstream who is compiling/packaging them not microsoft/google here in linux it isnt upstream who is packaging said apps thats | 17:24 |
| bigpod | the difference | 17:24 |
| alkisg | "someone somewhere will need to classify" => unfortunately that someone never came... :) | 18:10 |
| vkareh | there is often no "offending line" of code for a bug - it's an interplay between libraries that cause a misbehaviour. Also, who will triage that? I wonder if there can be a simple flowchart to determine whether to report upstream vs downstream. If, for example, the application behaves correctly, but does the wrong thing (e.g. mate-calc says 2+2=5), it's upstream. If the application misbehaves (crashes when maximizing window), then it's downstream. It | 18:24 |
| vkareh | won't be 100% accurate, but can help a bit. | 18:24 |
| vkareh | but even within upstream, users often report bugs in the wrong package | 18:25 |
| alkisg | By "offending line" I mean where the patch that solves the bug will land. If the patch that will solve the bug goes in a library, in mate-calc, in graphics drivers, in xorg etc, then ideally the bug should have been reported there in the first place | 18:42 |
| alkisg | Sure, it's very often hard to tell; but currently there's not even an attempt to instruct users to do so | 18:43 |
| alkisg | Many people expect "someone else" to do that. I believe noone else will; and it's a task for users; with the help of bug triagers etc. | 18:44 |
| superkuh | I use lots of caja/nautilus scripts but none of them will bring back the Gtk3 removed ability to type or paste into a File->Open dialog without hitting a number of other key sequences first. | 18:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!