| === ePirat- is now known as ePirat | ||
| === mfisch is now known as Guest41550 | ||
| teward | hey, stupid question, but is there a hierarchy of bug triage such that someone else in the chain has higher priority decision over bug importance / triage for a given package than others? | 17:14 |
|---|---|---|
| penguin42 | teward: Well there is bugsquad and bug-control and the package-maintainers for a particular package, and then there is bdmurray | 17:18 |
| teward | penguin42: so essentially, higher-to-lower is... bdmurray (ultimate final authority), package-maintainers/uploaders, bug-control, bugsquad, in that order? | 17:19 |
| teward | 'cause i have issues with how Alberto handles triage | 17:19 |
| teward | trying to determine the hierarchy of authority for the package i have issues with how he handled the bug | 17:20 |
| penguin42 | teward: I'm not sure what the formal way to moan is | 17:20 |
| teward | mmm | 17:20 |
| teward | well he's caused strife before... enough evidence of that lying around | 17:20 |
| penguin42 | I've also had issues with some peoples triaging mechanisms, but I can't say I know how to referee it | 17:21 |
| penguin42 | teward: If you've already asked nicely and not got anywhere, I'd say ask bdmurray, as the owner of bugcontrol team | 17:22 |
| teward | penguin42: you know what the problem is? Alberto's a hard one to find | 17:23 |
| teward | i also think 'high' importance is dependent on being able to reproduce the bugs - I fail to see any evidence where Alberto went and actually did any reproduction tests | 17:23 |
| teward | meh, maybe i'm just griping for the sake of griping :/ | 17:23 |
| penguin42 | teward: I wouldn't necessary try to reproduce for a 'high' if the problem sounds grim enough | 17:24 |
| teward | penguin42: the big problem I have is systemd now - it doesn't actually output useful information | 17:24 |
| teward | https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1447294 is the bug if you want to take a look | 17:24 |
| ubot5 | Ubuntu bug 1447294 in nginx (Ubuntu Vivid) "package nginx-full 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] | 17:24 |
| teward | i don't have an issue with "High" but there's zero useful data from the dpkg history | 17:24 |
| penguin42 | teward: and anyway, if it's failing for a bunch of people but as a triager you can't reproduce it, then you can't dismiss the bug just because you can't reproduce it | 17:24 |
| teward | penguin42: two people is a bunch? | 17:24 |
| teward | penguin42: i'm not dismissing the bug - i'm dismissing Alberto's actions | 17:25 |
| * penguin42 looks | 17:25 | |
| teward | penguin42: you can even see I asked for more information to try and deduce *what* caused dpkg to fail | 17:25 |
| teward | penguin42: also why i asked in -devel if there's a way to force apport to run certain additional commands to get information | 17:25 |
| teward | (if apport gave us information for nginx that actually helped debug it, that'd be one thing, but in this case, it gave us zero truly useful information) | 17:25 |
| teward | i agree that "High" is valid, but the problem being that there's no debug data of use (and Alberto should know this) | 17:26 |
| teward | is why i'm complaining. | 17:27 |
| penguin42 | teward: I'd have to agree that a package like nginx failing to install/uninstall is probably a high | 17:27 |
| teward | *cough* [2015/04/25 13:26:52] <teward> i agree that "High" is valid, but the problem being that there's no debug data of use (and Alberto should know this) | 17:27 |
| teward | penguin42: i'm complaining that Alberto just set importance and did no additional triage work | 17:27 |
| penguin42 | teward: Right, but the fact you don't have any debug data doesn't change the importance | 17:27 |
| teward | penguin42: at what point did i say that | 17:27 |
| teward | i'm complaining that alberto could have gone a step further and actually bothered to do triage work | 17:27 |
| penguin42 | teward: I think it's OK to set importance and not to do further triage | 17:28 |
| teward | i think that's what annoys me most - i fail to see him doing anything else but setting importance and such | 17:28 |
| teward | maybe i'm biased by upload privs for it, but meh | 17:28 |
| penguin42 | teward: While I'd agree it would be nice to do more triage, maybe he felt he doesn't know nginx well enough and it's better to leave it to those who do | 17:28 |
| teward | (the consideration point being, if users see an importance set they thin that means "Oh, nice, someone's actually working to test and reproduce." and gives them a false view on it. | 17:28 |
| teward | penguin42: IMO he should just stop touching server bugs, his focus seems to be GUI *shrugs* | 17:29 |
| teward | maybe i'm just having a bad week | 17:29 |
| teward | although he gets on my radar as an irritant far too often | 17:29 |
| penguin42 | teward: It would be worse if he was to ask irrelevant questions on the package to triage it | 17:30 |
| teward | well, then i'd be bothering bdmurray and saying he shouldn't have bug control, but that's a different story altogether | 17:30 |
| penguin42 | teward: If he knows he doesn't know the package but sees the bug looks important it seems reasonable to triage; and then let the package owner decide otherwise | 17:30 |
| * teward shrugs | 17:30 | |
| teward | penguin42: what's interesting is the latest failures there are dpkg failures, either because they used nginx.org's packages, or because of a nondeterministic failue due to no debug info | 17:30 |
| teward | i really wish we could tell apport what to actually get for a given package's failures | 17:31 |
| teward | (i'd love the systemd status for bugs :/) | 17:31 |
| penguin42 | teward: I'm not sure of the details of apport but I think you can add stuff | 17:31 |
| teward | mmm, i might suggest that to Debian, since that's their systemd script | 17:31 |
| penguin42 | teward: A lot of package installation failures are random installation screwups, disk fulls etc - but sometimes you do get things where a package assumes things about the /etc config files for the package and fails to install/uninstall - and those are valid bugs | 17:32 |
| penguin42 | brb - I just need to check on my sorbet | 17:32 |
| teward | penguin42: given that there's usable debug data, then yes | 17:32 |
| teward | however in a fresh installation like was above, where none of the apt history shows nginx being installed, that adds to the complexity | 17:32 |
| penguin42 | hmm, still sorbifying | 17:34 |
| penguin42 | teward: Well, it could be something like a missing dependency depending what packages people chose | 17:35 |
| teward | penguin42: well they installed nginx-full, which called in the dependency for nginx-common - and that did install (see the dpkgterminalhistory) | 17:35 |
| teward | based on the info available i really wish I could force Apport to get additional data, but meh | 17:36 |
| teward | (systemd is giving me headaches >.<) | 17:36 |
| penguin42 | teward: I'm fairly sure that's possible; but need to check with the apport guys | 17:36 |
| teward | here's the journal errors... | 17:36 |
| teward | Apr 22 14:24:32 hostname systemd[1]: Failed to start A high performance web server and a reverse proxy server. Apr 22 14:24:32 hostname systemd[1]: nginx.service failed. | 17:37 |
| teward | ^ nothing useful | 17:37 |
| teward | just like dpkg's output | 17:37 |
| teward | i think i need to talk to the apport people | 17:37 |
| penguin42 | teward: I'd consider journalctl -u nginx or something like that | 17:37 |
| penguin42 | teward: but that depends where nginx sends it's logs | 17:38 |
| teward | penguin42: /var/log/nginx/* i think is still the log dir, but a service failure... no idea. | 17:38 |
| teward | the systemd stuff is new enough that it's a headahce :P | 17:38 |
| teward | (back later) | 17:38 |
| === Guest41550 is now known as mfisch | ||
| === wgrant_ is now known as wgrant | ||
| === kees_ is now known as kees | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!