[00:09] regarding 162841 seems https://wiki.ubuntu.com/Bugs/Responses#Packages%20not%20provided%20by%20Ubuntu ? [00:09] regarding bug 162841 seems https://wiki.ubuntu.com/Bugs/Responses#Packages%20not%20provided%20by%20Ubuntu ? [00:09] Launchpad bug 162841 in vmware-server (Ubuntu) "Instructs users to upgrade it outside of the packaging system (heat: 3)" [Undecided,New] https://launchpad.net/bugs/162841 [00:19] rusivi: re. 162841 -- this would be the wrong answer. The bug is about the VMware that was packaged for Ubuntu (via partnership) [00:20] hggdh: k do you have a recommendation? [00:21] fyi I marked a couple bugs recently invalid, I should not have, my mistake I'll avoid in the future. [00:21] not sure right now, I will have to query the folks about the status (but I think it will be closed wontfix, eventually). So, for now, please leave it be [00:21] Just a couple or so [00:22] hggdh: roger [00:22] just subscribed to it [00:22] rusivi: Remember you don't have to change a bug that you're unsure about [00:23] penguin42: I just realized invalid was the wrong way to go [00:23] I'm like ugh J.H.C. [00:23] rusivi: if you marked a bug wrongly, just go ahead and redo it (and add a comment stating it was wrongly marked). No problems [00:23] it happens to the best of us ;-) [00:23] hggdh Where do I go to see bugs I marked invalid? [00:24] penguin42: yo [00:24] G: Did you see the comment on the Maverick SDL/kvm thing [00:24] penguin42: yeah, can't decide if it's bull or not [00:25] rusivi: go to bugs.launchpad.net/~rusivi1 -> advanced search -> filter for status invalid [00:25] hggdh: ty [00:25] G: It sounds like a reasonable explanation - it's a bit of a nasty outcome though [00:25] penguin42: the fact of the matter is that none the less, the XAUTHORITY env variable is still wrong [00:26] penguin42: if you run 'env' and look at what you have, compared to what gets passed to KVM you can kinda see [00:26] G: But I think Marc is saying even if it was right it wouldn't be able to read it [00:26] rusivi: or use this: http://tinyurl.com/3a8j2nt [00:26] hggdh: oh wow only 357 :P man I got a lot of self-help to do! [00:27] actually, these are the bugs you acted on that are set to INVALID [00:27] hggdh: I'm going to review all my invalid bugs right now before I start anything more [00:27] penguin42: sure, and thats something that needs to be sorted w/ a facl [00:27] ordered most recently changed [00:27] G: Yeh, it's probably not trivial though - IMHO even if that's going to be a pain to fix, if it couldn't be done for maverick it could do with a fix that refuses rather than blatting X [00:28] G: what's bull? [00:29] penguin42: imo if it ain't working it's fairly serious [00:29] mdeslaur: I can't decide because I haven't had the chance to go back and take a look [00:29] G: Yeh I agree, but I can see that if it's the increased security that's broken it I'd keep the security and tell people to use the VNC one until fixed [00:30] mdeslaur: I've been out of power for a while [00:30] although the VNC one is a bit laggy [00:30] G: I honestly don't know why that makes your X crash though [00:31] penguin42: well this is what bugs me, because the default is use VNC it'd never be considered as serious [00:31] mdeslaur: I think it's SDL falling back to framebuffer [00:31] mdeslaur: because, as it can't find the right XAUTHORITY it's attacking framebuffer [00:31] and as root, it can to rather drastic results [00:32] G: Except it isn't root if it's dropping to that other user - so.... [00:32] oh, right...that makes sense... [00:32] penguin42: true, but it highlights the problem perfectly well imo [00:32] mdeslaur: If there was a way just to stop it falling back to frame buffer it would be a big improvement; failing to work is one nasty problem, but nuking X is a real nasty [00:32] if it's got the right XAUTHORITY it works perfectly [00:33] (even as root) [00:33] penguin42: yeah...it doesn't nuke my X...what video driver do you have? [00:33] mdeslaur: Radeon (open source) - it only nuked the X sometimes [00:34] we could remove the framebuffer permissions from the apparmor profile...that would stop it from at least nuking X [00:34] mdeslaur: put simply: {lib,}virt* should pass the right XAUTHORITY, and do what it's done for isos etc and set a facl so that it can be accessed [00:34] G: It's not that simple [00:34] mdeslaur: I think that would be an improvement [00:35] G: libvirt actually does a chown libvirt:kvm to isos and image files...I don't think you'd want it to do that to your xauth file [00:35] mdeslaur: not a chown no... facl [00:36] chown/chmod would be wrong, it should be owned by $USER:$GROUP, at least setting a facl for the KVM binary would be better [00:36] mdeslaur: Erk! That's nasty [00:37] G: it doesn't fo a facl AFAIK [00:37] mdeslaur: What happens if my ISOs are on something like an NFS repo I don't have write to (or worse I do have write to!) [00:37] penguin42: yes, it's _really_ ugly [00:37] penguin42: everything blows up [00:37] mdeslaur: I'm talking about instead of chown for $XAUTHORITY [00:37] penguin42: what's really cool is when you specify /dev/cdrom [00:38] G: that's only one part of the probem [00:38] mdeslaur: Would this work if something passed it an open fd for the .Xauthority? [00:38] (ditto for image files and cds ?) [00:39] penguin42: it chowns /dev/cdrom to libvirt:kvm, and if something goes wrong, it never changes it back [00:39] * penguin42 finds a bucket [00:39] mdeslaur: I await the hundreds of random CDROM access bugs with joy [00:40] penguin42: IMHO, it should at least _add_ the required permissions with extended acls, like consolekit does...that would be better [00:40] mdeslaur: Hmm that's a security hole (either way) [00:41] mdeslaur: Two users, both allowed to run kvm, but they've each got ISOs/devices they're allowed to see - run kvm and it means that the other users kvm can see it [00:41] penguin42: well, adding a user to the libvirt group basically gives up security anyway [00:42] why? [00:42] oh something is giving it block device access? [00:42] among other things [00:43] from the readme.Debian file: "Adding users to the libvirtd group effectively grants them root access." [00:43] it shouldn't chown the cdrom if it's all read anyway [00:43] that sucks [02:57] Hello does anyone know of a outstanding Malone bug regarding "poster's remorse"? [02:59] rusivi: bug 80895 [02:59] Launchpad bug 80895 in malone (and 1 other project) "Give people five minutes to edit/delete their comment (affects: 40) (dups: 8) (heat: 230)" [Low,Triaged] https://launchpad.net/bugs/80895 [02:59] micahg: ty [03:39] bug 418090 should be wishlisted on both yelp & WINE [03:40] Launchpad bug 418090 in wine (Ubuntu) "wine instalation problem (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/418090 [03:42] rusivi: none of the above [03:43] rusivi: do you understand what wishlist is? [03:43] micahg: yes that's why I asked for ti [03:43] ti = it [03:43] rusivi: no, you don't [03:43] do you understand WINE project [03:43] ? [03:43] :) [03:43] this is an installation issue [03:43] I disagree still should be in yelp [03:43] rusivi: people commonly report bugs against yelp and firefox since that's where report a problem links are in older installs [03:44] and? [03:44] rusivi: and the problem here is that wine can't be installed apparently on jaunty [03:45] It was a matter of user familiarity but for a first-timer it can be a huge deal breaker [03:45] ? [03:45] I'm trying to overcome those hurdles for them [03:45] not for the people who already know ;) [03:45] no, what you wrote didn't help [03:45] ok disagree but respect your opinion [03:46] ty for checking [03:46] rusivi: first question to ask is to provide the output of: apt-cache policy wine [03:46] rusivi: that will tell us which version is to be installed [03:46] since there is no libfontconfig package in the archive, it's probably a PPA, but we ask to make sure [03:47] ok np [03:47] :) [03:47] alos, the user might have upgraded already since this bug is a year old [03:47] very valid point. [03:48] I'll leave me post where it stands. I do very much appreciate you checking into it. [03:48] rusivi: please don't nominate things randomly [03:49] lifeless: example(s)? [03:49] rusivi: particularly you need to check the release process for the product first [03:49] rusivi: launchpad. bug 80895 [03:49] Launchpad bug 80895 in malone (and 1 other project) "Give people five minutes to edit/delete their comment (affects: 41) (dups: 8) (heat: 256)" [Low,Triaged] https://launchpad.net/bugs/80895 [03:49] oh come on with that [03:49] I am very secure it my nomination. [03:49] and my post. [03:49] rusivi: launchpad is a web service, it has no backports. [03:50] lifeless: your saying my nomination was for a previous version of Malone? [03:50] the 'nomination' process is always for backports. [03:50] (doh) [03:50] 2.1 was years ago [03:51] and as its a web service it has no meaning. [03:51] well I'm lost b/c nominations for packages are for forward versions and backwards. [03:52] they may mean something different than you think they mean. [03:52] we should perhaps restrict nomination use to the bug control & driver teams. [03:52] rusivi: nominations work differently in malone than Ubuntu [03:53] micahg: duly noted [03:54] lifeless: that's for you to decide. I think it's a good idea, despite my unfamiliarity. [03:54] to allow newbs = me, to nominate [03:55] I'll tell you this if I could not nominate I would be very salty about it [03:55] I just should be more careful in the future [03:55] innocent mistake [03:58] rusivi: 99% of nominations are noise in the system. [03:58] rusivi: because of various reasons: [03:58] - they are for bugs that are not severe enough to risk a SRU [03:58] - they are for bugs where the fix is too big and no developers are going to redo it [03:58] SRU = ? [03:59] - they are simply marking enthusaism or interest from users, which doesn't actually alter what gets done [03:59] stable release update [03:59] k ty [04:06] rusivi: we are trying to help you understand what is done, why it is done, and how it is done. [04:06] hggdh: and I am very appreciative of it! [04:06] rusivi: I agree beforehand that we are not always correct, but please [04:06] ty [04:06] I apologize if I seem a little overbearing [04:07] try to understand the process. Otherwise all you will achieve is a lot of noise [04:07] rusivi: I think the feature you were looking for on the malone bug was marking as affecting me, not a nomination [04:08] hggdh: I am trying to fully understand the processes everyone notes. [04:10] rusivi | lifeless: that's for you to decide. I think it's a good idea, despite my unfamiliarity. [04:10] it is not a good idea, and we have been trying to tell you so [04:11] hggdh: What is not a good idea. [04:12] your iteraction with lifeless just a few ago [04:14] sorry lifeless if you feel insulted [04:14] why would I? [04:14] hggdh is saying that having non bug-control/drivers doing nominations is a bad idea [04:15] which I agree with based on the fact that most nominations are not useful in the system [04:15] I don't know if the nominations in Ubuntu are an issue per say, but in Malone they don't make any sense [04:15] *se [04:16] most nominations in Ubuntu are not useful [04:16] and I am trying to point out that -- even when people with more experience on triaging on Ubuntu tell you something was not quite good -- you still do not heed it [04:16] noniminations in projects that don't do SRU's are also not useful [04:16] +1 [04:16] and nominations in web services are never useful [04:16] I'm not going to have an involved discussion about nominations by community members. I was wrong. It got denied. I learned my lesson. end of story. [04:16] lifeless: true, but we need some way to know if a bug is even wanted on a previous release, don't we? [04:17] micahg: do you mean 'is present in a previous release' ? [04:17] I think having it as is is fine. [04:17] micahg: if so, thats what bug tasks / infestations are for [04:17] I should have been more careful, no big deal. [04:17] lifeless: no, a bug can be present without a great need for fixing [04:17] micahg: the way we'd record that in lp today is a bugtask with 'wontfix' or 'wishlist' status [04:18] but the nominations do get abused [04:18] What up Poizhan [04:18] hello rus [04:18] yes. And we have been sort of easygoing with bad nominations [04:18] lifeless: I guess we're moving towards a task for each affected release anyways which would render nominations almost useless [04:19] Poizhan = great friend and fellow Ubuntu Community Member, welcome to the Bug Squad chat room! [04:19] =D [04:19] rusivi: we are all community here [04:20] Thanks. [04:21] Poizhan thank you very much for joining the chat room. We have a lot of great professional who are eager and capable of working together with Bug zapping procedures. [04:22] rusivi: are you trying to be sarcastic? [04:22] seriously no. [04:23] I believe rus is sincere. [04:23] I meant it. [04:23] :O [04:25] I am sorry, rusivi. I was unsure on how to consider your comments. [04:28] lifeless: what could be done re. nominations? I really would not like to limit it to -control and other restricted groups [04:29] hggdh: I don't really know; but I don't know that its doing its job either. [04:30] you can guarantee for any bug that is present when we release that someone will want it SRU'd [04:30] heh. I would not bet on that, I would lose ;-) [04:30] hggdh: wouldn't limiting it prevent people who have made patches etc nominate those patches for SRU in Ubuntu? [04:30] G: no, nominating has /nothing/ to do with the actual SRU process [04:30] What I was looking for in nominations was just asking for it to be dealt with in a particular release. I did not realize that nomination was for SRU, maybe they should put SRU Nomination in each bug ;) [04:31] in fact, for any bug, you can guarantee that its the most important thing for *some* user. [04:31] the 'affects me' is I think a much better surrogate for estimating the impact/benefits of a fix [04:31] lifeless: actually, nominating is mentioned in the SRU process [04:31] micahg: thats what I thought too [04:32] G: usually I am against restrictions on usage; but nominations are being so much abuse that they are losing their value [04:32] hggdh: exactly [04:32] micahg: its mentioned, but its not functional. [04:32] G: so, this is the rub... [04:32] why not a restriction to the bug supervisors/etc + people who have uploaded patches etc [04:32] micahg: the only functional aspect is when one is *declined*. [04:33] ^ yes. And this is sort of wrong [04:33] An approved one doesn't trigger work - the subscription and patch preparation combined do that. [04:33] I don't like restrictions either [04:33] tbh, I'm totally confused over the whole nominate stuff [04:33] I'm just saying that the benefits of it are not clearly articulated, nor the connection between the code/feature in LP and the work of the sru tea. [04:34] hum. Something to clear up [04:34] its not surprising that even old hands get confused. [04:34] Minimizing nomination eligible members to CoC signers is a great idea. [04:34] what makes the whole nomination/sru stuff even more confusing is the seperate process for Server packages [04:34] CoC = Code of Conduct [04:34] sorry Poizhan [04:34] mostly because we/some are now using it even on Maverick [04:35] rusivi: no, we're talking about reducing it to bug control members [04:35] I understood that and I'm not pleased nor do I agree :) [04:35] rusivi: *I* am not pleased [04:35] but we have to control/curb the wrong usage [04:36] CoC signers is a fair way to do it IMHO [04:36] but how does that stop people [04:36] it does not [04:36] "Error you nede to have signed the CoC" "Oh, I'll go sign it then" [04:36] G: whats the server package process? [04:36] if you do not read the documentation, it does not matter if you signed the CoC or not [04:37] lifeless: https://wiki.ubuntu.com/ServerTeam/SRUPolicy [04:37] (so I'm told) [04:37] G: CoC is more important than you may realise... if you sign because it is required, but does not follow it, I will personally ban you from here [04:38] G: thats nice [04:38] hggdh: hey I read it, I agree with it, but what I'm saying is that is what people's attitudes will end up as [04:38] ("you" meaning "anyone", not you G actually) [04:38] be nice to consolidate the definitions [04:38] lifeless: I am starting to really think this is UDS material [04:39] hggdh: could be [04:39] hggdh: we should deifnitely have some sessions on this [04:39] hggdh: there will be an lp bugs member @ uds, and I will be there and jml too [04:39] definitely, UDS material - I agree. [04:39] hggdh: so if there are LP changes needed we can assess and help [04:39] lifeless: great! I will ask a/some track(s) from QA [04:39] UDS = ? [04:40] hggdh: All I'm saying is that if CoC becomes the sole barrier to prevent abuse of the nominations system, people will do it just so they can nominate [04:40] rusivi: Ubuntu Developer Summit [04:40] CoC isn't a useful test for this [04:40] ty [04:40] this is a knowledge/experience issue [04:40] rusivi: Ubuntu Development Summit, happens every half-year [04:40] rusivi: usually November/May [04:40] It is both CoC & knowledge/experience [04:40] + what LP presents/offers/encourages [04:40] \ [04:41] rusivi: why do you think the CoC is relevant? [04:41] micahg: willing to participate on such sessions? [04:41] hggdh: always :) [04:41] hggdh: please subscribe me [04:41] b/c that is what Ubuntu is founded on [04:42] both the philosophy and the OS [04:42] lifeless: I will submit a blueprint on that [04:42] and Canonical for that matter [04:42] hggdh: great, thanks. [04:42] but yeah, as someone that has been following bugs/providing fixes/solutions for certain packages I have experience/knowledge in the whole nomination system and different SRU policies are confusing as anything [04:42] (my personal opinion there) [04:42] G: indeed, and thank you for pointing this out [04:43] The only irk I have with sru is that someone who knows what they're doing need to be following it up. [04:43] G: I will propose a session/track on UDS to consolidate this, at least on the macroscopic level [04:43] We are far too busy to have an automatic process run. [04:43] rusivi: Launchpad hosts much more than Ubuntu; other projects have nomination issues too, the CoC wouldn't help them. Secondly, unlike Ubuntu membership or PPAs, this doesn't lead to using potentially lots of resources or franchisement. [04:43] rusivi: the CoC is totally irrelevant for this IMO [04:43] lifeless no it's not [04:44] IMHO [04:44] I'd need a much stronger argument than that to even consider accepting a patch using it as a test. [04:44] It's impossible for CoC *not* to be relevant. [04:44] I think having the opportunity to see other project's stuff and contribute is a valuable and interesting thing [04:45] yes, neither of those need a CoC signature [04:45] I learned a lot about, granted mis-posting, to projects I never even heard of [04:45] the CoC is important as a ethic [04:45] hggdh: as an example https://bugs.edge.launchpad.net/ubuntu/+source/seabios/+bug/589063 [04:45] Ubuntu bug 589063 in seabios (Ubuntu) (and 1 other project) "Windows Server 2008 won't boot with more than 4 vCPUs (affects: 4) (heat: 52)" [Undecided,Confirmed] [04:45] The morality portion of the CoC. [04:45] G: ohhh, this bug... yes... [04:46] hggdh: I was told to nominate it via the u-server mailing list and never heard a thing (and I haven't seen the list of SRU bugs etc since) [04:46] * hggdh works with the server team [04:46] but the CoC is only relevant to Ubuntu and maybe launchpad itself [04:46] unlesss morality is at issue in the thing being restricted, the CoC isn't particularly relevant; morality isn't relevant for clicking on 'nominate for'. [04:46] hggdh: ahhh yes I've seen your name in a few libvirt bug e-mails :) [04:46] (just checked /whois) [04:47] What realm of interaction are we talking about, that doesn't include the ubuntu community or the facilitation of launchpad? [04:47] if someone is being abusive and clicking all over the place, folk will complain and the account will be banned. [04:47] which is sad. [04:47] G: can you please forward me your email? hggdh2 at ubuntu dot com [04:47] sigh, I've better things to do, sorry. [04:47] hggdh: I'll have a hunt for it, it's on my old g-mail server I think :) [04:47] hggdh: G: It will be nice to get some clarity on this; please subscribe me to the spec. [04:48] lifeless: roger wilco [04:48] hggdh: yes, please subscirbe me ona spec even though I won't be attending UDS [04:48] (dev-nigelj) [04:48] oh, another nigel :) [04:49] G: will do [04:49] nigelb: heh :) [04:50] (the irc nick 'G' doesn't make that too obvious I admit) [04:50] heh, true [04:50] rusivi: the CoC is more a philosophical stand than anything else. We do follow and abide by it, but it does not replace documentation [04:51] Poizhan: for your question: all that is needed to do a lot of things in LP is an LP account [04:51] hggdh: thank you for the clarification [04:51] speaking of which, is it just me or the tracks a bit different from the usual this time? [04:51] Poizhan: a perfect example is, indeed, rusivi -- s/he is not a member of the bugSquad [04:52] * nigelb doesn't see things like 'kernel', 'qa', etc [04:52] hggdh: but I do my best to abide by your wishes and principles about BugSquad'ing [04:52] nigelb: the tracks are different, it will be more on areas of interest than on specialty groups [04:52] hggdh: That does not mean one cannot be a valueable member of the community no? [04:53] hggdh: heh, that's confusing ;) [04:53] rusivi: I did not mean anything else, I was just pointing that you do not need to be a member of the bugSquad to work on bugs [04:53] nigelb: yes, UDS has a new structure [04:54] Poizhan: indeed. The community is comprised of all the users [04:54] hggdh understood [04:54] lifeless: should be interesting. At least this time it should be easier to choose sessions to attend. [04:54] or not... [04:54] rusivi: why are you marking package installation bugs incomplete asking for people to test with the devel release? [04:55] hggdh: haha [04:55] rusivi: bug 623927 [04:55] Launchpad bug 623927 in vlc (Ubuntu) "package mozilla-plugin-vlc 1.0.6-1ubuntu1.1 failed to install/upgrade: unable to install new version of `/usr/lib/mozilla/plugins/libvlcplugin.so': No such file or directory (affects: 1) (heat: 147)" [Undecided,Incomplete] https://launchpad.net/bugs/623927 [04:55] micahg: yes I know it seems troll/spam'ish [04:55] hggdh: every UDS participant feels he/she had access to a time machine. [04:55] but I felt compelled based on my actions to give them the opportunity to solve their own problem not just shut them down [04:55] lock stock and barrel [04:56] I'm reviewing all my bugs I invalidated for mis-invalidation [04:56] rusivi: it doesn't help, package installation bugs need to be dealt with in the release they occur in [04:56] micahg: That is why I prefaced with the troll spam'ing remark [04:57] rusivi: well, please stop [04:57] ok sorry [04:57] I'll move forward then [04:57] bugs that are confirmed or triaged *should not be changed to incomplete* [04:57] ever [04:57] I'm not going into a habit of posting then going back on posts [04:57] I'm in a learning process [04:58] yes, OTOH you've touched nearly 1500 bugs [04:58] I understand it may be frustrating but it has revealed alot about what I don't know and sparked my interest in a ton of projects, ideas, and packages! [04:58] I think you need to touch less, with more mentoring, or something. [04:58] closer to 2k actually from what I can tell [04:58] learning is good [04:59] I'm very open to being mentored more focusedly [04:59] micahg: What would be a more effective action path in order to address stale or unresolved bugs, I'm assuming posting to 4-5 year old bugs is frowned upon in the same way necroing a 5 year old forum thread would be, correct me if I'm wrong. [04:59] I'm still learning a ton, micahg has been holding me very accountable to my actions and I have learned a great deal from this [05:00] Poizhan: depends on the bug, posting if the bug still occurs when recreate steps are present or easily inferable is frowned upon [05:00] Poizhan: checking for the same bug upstream is a good start, then we can link it and mark our bug triaged [05:00] micahg: That's some what ambiguous [05:00] Poizhan: if you ask a question on a bug you should subscribe to it -- otherwise what is the meaning of asking the OP for something if nobody is going to read it? [05:01] Why retain a bug if no one plans to ever resolve it, let alone fix it? [05:01] Poizhan: and -- when the OP answers -- you should act on it [05:01] michag: I understood/understand it is, but Launchpad is a community effort and as part of the community even if I cannot go through all the involved processes of recreating the bug and dealing with I feel it is of significant contribution to ask if their problem is still outstanding. It is acknowledging thier problem was and is important shows the community is behind them! [05:01] Poizhan: we forward most bugs upstream if they are inherent in the software and not related to or changes [05:01] Poizhan: this does not justify a fire-and-forget action [05:02] micahg: respecting the BugSquad process of if your not going to fix it don't bother [05:02] rusivi: no, that is not appropriate and against current bug squad policy [05:02] rusivi: you misunderstand triage [05:02] hggdh: I agree with you, restraint is always productive, should there not be some measure of accountability on the OP to resolve the issue, or at least maintain the bug upstream? [05:02] it just serves to annoy the reporter [05:03] I'm actually surprisd that no bug reporter hasn't trolled you yet. [05:03] nigelb: it's happened [05:03] Poizhan: the majority of bugs are opened by casual users, not experts on Linux/Ubuntu. You cannot require from them doing this all. [05:03] and upstream triagers as well [05:03] Poizhan: this is why there is triage [05:04] hggdh: duly noted [05:04] micah: Yes the risk of pissing people off exists but I should not feel uncomfortable asking if their problem is resolved in a judicious manner (like when it is 1-4 years old with no patch, comments, zilch) [05:04] rusivi: this seems very reasonable [05:04] rusivi: you should be etrying to recreate and see if the bug exists, not ask. [05:04] rusivi: that's not true, that's what we've been trying to tell you, if there are recreate steps, they've done their part [05:05] rusivi: if you don't have time to reproduce, work on bugs that don't require it [05:05] the issue here is of perception: an user opened a bug years ago. It went on undeteted; then somebody asks if it is still an issue, and there is no follow-up [05:05] end result: we are worse off [05:06] hggdh: please explain *worse off* [05:06] hggdh: yes just asking inquiring for inquiry sake is waste of time. But providing some sort of suggestion to move forward is good [05:06] hggdh: every post I do, I have done this. [05:06] hggdh: even ones I misposted too [05:07] worse off -- the poor user opened a bug years ago, nobody looked at it; then somebody asks if it is still an issue, and then -- again! -- nothing [05:07] hggdh: agreed on that point [05:08] this is why we recommend subscribing to the bug. If one cannot bother to subscribe, then one should not bother to comment [05:08] hggdh / Poizhan we have to give them something to move forward with. If your BugSquad you recreate or don't post. [05:08] hggdh: btw, SRU policy says that the modification of verification-needing tags should be done by the SRU Verification team, do yuo want to leverage my comments in 455832 & 571093 to get the libvirt update out? [05:08] bug 455832 [05:08] Launchpad bug 455832 in libvirt (Ubuntu Karmic) (and 3 other projects) "segfault when attaching disk with same physical device (affects: 2) (heat: 29)" [High,Won't fix] https://launchpad.net/bugs/455832 [05:08] bug 571093 [05:08] Launchpad bug 571093 in libvirt (Debian) (and 4 other projects) "[SRU] multipath + libvirtd eats away more memory over time (affects: 8) (heat: 73)" [Unknown,Fix released] https://launchpad.net/bugs/571093 [05:09] I've found a lot of people who were both thankful and noted their problem was fixed or moved forward with it on my inquiring with helpful suggestion. Granted I did not, from my skill level, reinvent the wheel, but it still has contribution value. [05:09] rusivi: yes, but there were a large portion annoyed by the efforts as well, that's why we don't think it's worth the tradeoff [05:09] This empathy is also what the CoC is all about [05:10] micahg: I see. [05:10] micahg: then I beg your pardon if I have annoyed many people it was certainly not my intention to do so. [05:11] micahg: that is why I am striving to continue to improve in my post judiciousness. [05:11] micahg: Who is being annoyed? [05:11] micahg: This is what I was talking about when I first join the channel a week ago, sub-triage but above-spam [05:11] rusivi: Why are you annoying people :( [05:11] Poizhan: reporters, Ubuntu triagers/developers, upstream triagers/developer [05:12] micahg: How would you suggest rusivi move forward, as a community member, who is interested in addressing unresolved or buried bugs? [05:13] Poizhan: instead of asking, try to recreate [05:13] Poizhan: do not mark incpmplete bugs that have been confirmed/triaged [05:13]