| === menyort is now known as ApOgEE- | ||
| crimsun | Camden: the first two URLs in the topic are most relevant | 04:28 |
|---|---|---|
| crimsun | http://wiki.ubuntu.com/BugSquad and http://wiki.ubuntu.com/HelpingWithBugs | 04:28 |
| Camden | what exactly is an "ubuntu bug"? | 04:29 |
| Camden | wouldn't the bug be in some project | 04:29 |
| Camden | ? | 04:29 |
| crimsun | Ubuntu bugs are ones in Ubuntu releases and the current development version | 04:30 |
| crimsun | yes, some bugs are also in the upstream project's version(s) | 04:30 |
| Camden | what's an example of a bug, that's NOT in the upstream project? | 04:30 |
| crimsun | many times, bug triaging in Ubuntu requires coordinating supplying relevant information to upstream developers so they can fix the bugs | 04:30 |
| crimsun | Camden: well, one off the top of my head is bug 192888. | 04:31 |
| Camden | ok, so that's not exactly "fixing" | 04:31 |
| ubottu | Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents when using libflashsupport" [High,Confirmed] https://launchpad.net/bugs/192888 | 04:31 |
| crimsun | Camden: sure, it can be fixing if you directly contribute to the fix | 04:31 |
| Camden | so that is a bug in libflashsupport right? | 04:31 |
| crimsun | Camden: no, it's a multifaceted bug | 04:31 |
| crimsun | Camden: it has, as its culprits, flashplugin-nonfree, libflashsupport, alsa-plugins, and alsa-lib | 04:32 |
| Camden | meaning... we're not sure where to change the code? | 04:32 |
| Camden | which project? | 04:32 |
| crimsun | no, we already know what's broken and how to fix it | 04:32 |
| Camden | it requires changes in multiple projects? | 04:32 |
| crimsun | there are "broken" parts in all four of those source packages | 04:33 |
| crimsun | yes | 04:33 |
| Camden | and all 4 need to be fixed in order to fix this "ubuntu bug"? | 04:33 |
| Camden | and it's possible for ubuntu to fix code in other projects, independently of those upstream projects | 04:34 |
| crimsun | correct | 04:34 |
| Camden | and just leave it as an option for them | 04:34 |
| crimsun | on both | 04:34 |
| Camden | to include the change | 04:34 |
| crimsun | best practice recommends that we work with upstream projects to get vetted fixes | 04:34 |
| crimsun | that way everyone, including other Linux distributors, benefit | 04:35 |
| crimsun | (and of course users of other Linux distributors) | 04:35 |
| Camden | so it's case by case decision whether to wait on the upstream or not? | 04:35 |
| Camden | and if ubuntu does not wait, doesn't that make it a fork? | 04:36 |
| Camden | i guess forks are normal | 04:36 |
| crimsun | Camden: it can be a case-by-case, yes, but generally you want to work closely with upstream | 04:36 |
| crimsun | Camden: and no, forks aren't made just because one distro contains a fix whereas upstream doesn't | 04:37 |
| Camden | i have heard of the concept of branches and trunks... i guess this is where it comes in? | 04:37 |
| crimsun | (or further, because one distro contains a fix that another doesn't) | 04:37 |
| Camden | so it's more a "branch" than a "fork" | 04:37 |
| Camden | ? | 04:37 |
| crimsun | that's a convenient way of thinking of development, generally, but it's not necessarily the case with fixing bugs | 04:38 |
| Camden | ok but there is a different source control "branch" for libflashsupport that belongs to ubuntu | 04:38 |
| Camden | right? | 04:38 |
| crimsun | yes, there is a "source package" | 04:38 |
| Camden | different than what belongs to the libflashsupport project? | 04:39 |
| Camden | and there are presumably ways to compare them? | 04:39 |
| crimsun | correct | 04:39 |
| crimsun | yes | 04:39 |
| Camden | so this is what contributed to the openssl problem? | 04:39 |
| Camden | debian had a different package than openssl | 04:39 |
| crimsun | a non-native Ubuntu source package contains the original upstream source and, separately, any modifications Ubuntu has made | 04:39 |
| crimsun | Camden: it is not the cause, but it certainly made it more complicated | 04:40 |
| Camden | what are "native" ubuntu packages | 04:40 |
| Camden | i guess i think of ubuntu as a collection of upstream packages | 04:40 |
| crimsun | upstream packages are called non-native | 04:41 |
| crimsun | ones that are native are developed solely in Ubuntu | 04:41 |
| Camden | right , but i guess i thought that is all there is | 04:41 |
| crimsun | for instance, upstart | 04:41 |
| Camden | ok | 04:41 |
| crimsun | it happens to be that upstart is an upstream project that is developed in Ubuntu but grew an external audience | 04:42 |
| Camden | is there some mechanism to "reserve" a bug to make sure no one else works on it? | 04:42 |
| crimsun | you can assign a bug to your Launchpad user and mark the Status accordingly | 04:42 |
| Camden | ah, ok | 04:43 |
| Camden | that makes sense | 04:43 |
| Camden | and any user can do that? | 04:43 |
| crimsun | not any user | 04:43 |
| Camden | which users? | 04:44 |
| crimsun | any user can assign a bug to him-/herself, but only members with privileges can alter the Status and/or Importance | 04:44 |
| crimsun | generally, members of ubuntu-bugcontrol have those privileges | 04:44 |
| crimsun | you'll want to read http://wiki.ubuntu.com/BugSquad and http://wiki.ubuntu.com/HelpingWithBugs, as I mentioned prior | 04:44 |
| Camden | ok | 04:45 |
| Camden | is there a way to locate bugs that don't involve a big learning curve to grok all the dependencies? | 04:45 |
| crimsun | sure | 04:47 |
| crimsun | there are ones tagged "bitesize" | 04:47 |
| Camden | cool | 04:49 |
| Camden | sounds like something to try | 04:49 |
| Camden | definitely would want to have the experience of coding something that made it into a distro | 04:50 |
| Camden | even if i don't take it further than that | 04:50 |
| Camden | but of course... could be it would lead to something | 04:50 |
| crimsun | yep | 04:50 |
| Camden | i saw an interesting article about the advantage of working on OS | 04:51 |
| Camden | say, you are job hunting and you've only worked in proprietery stuff | 04:51 |
| Camden | all you have is your word | 04:51 |
| Camden | you can say "i was the main developer for microsoft excel" | 04:51 |
| Camden | and you may not be able to prove it | 04:52 |
| Camden | but if you work in OS, you can just point to all your work | 04:52 |
| Camden | anyway whatever | 04:53 |
| Camden | i'll check those links | 04:53 |
| === hggdh is now known as hggdh-away | ||
| lifeless | meh | 07:34 |
| lifeless | I hate 'pleae add data' questions | 07:34 |
| lifeless | particularly when the bug report *has enough information already* and the folk trying to help out don't have enough. | 07:34 |
| Hobbsee | lifeless: help educate the triagers :) | 07:40 |
| lifeless | well | 07:42 |
| lifeless | _how_ | 07:42 |
| lifeless | bug 44678 for instance is the most recent case | 07:43 |
| ubottu | Launchpad bug 44678 in language-pack-en "language pack replaces clauses are crufty" [Medium,New] https://launchpad.net/bugs/44678 | 07:43 |
| greg-g | yeah, the first should have checked themselves while the second was just autopilot :) | 07:44 |
| lifeless | :) | 07:46 |
| greg-g | if anyone has any suggestions on how to help educate the triagers it might help | 07:47 |
| greg-g | like a "rate this request for information" button ;) | 07:48 |
| lifeless | so the first one I meant to reply to, but was on sprint | 07:48 |
| lifeless | and things get real lossy on sprint | 07:48 |
| greg-g | yeah | 07:48 |
| lifeless | or I would have mailed back a clear statement to them | 07:48 |
| lifeless | I just got reminded on the second occurence | 07:48 |
| lifeless | I think basically its a matter of them remembering that they are not machines; they need to look and think all the time | 07:49 |
| Hobbsee | lifeless: ah yes, that sort of thing is often a problem. | 07:49 |
| Hobbsee | lifeless: somewhere along the line, triaging changed from "lets try to reproduce this bug, and then deal with it" to "lets ask the reporter if they can reproduce, as it's probably a wihle ago, and then deal with it" | 07:50 |
| * greg-g nods | 07:50 | |
| lifeless | well | 07:50 |
| lifeless | I think there is a fair concern that bugs are fixed and we have stale reports | 07:51 |
| lifeless | but auto-pinging is something for a cron script | 07:51 |
| lifeless | having a huge bug database is only _wrong_ if we don't have that many bugs | 07:51 |
| Hobbsee | i wonder abuot an auto-cron script. | 07:52 |
| greg-g | for the incomplete/no response ones? | 07:52 |
| lifeless | API's will be here soon | 07:52 |
| lifeless | you can do that then :P | 07:52 |
| Hobbsee | for ones that havent been responded to in a while. | 07:52 |
| greg-g | right | 07:53 |
| Rocket2DMn | ive actually been working on these ancient incomplete bugs | 08:04 |
| Rocket2DMn | been closing many of them | 08:04 |
| Hobbsee | OTOH, i think there would be merit in saying "okay, a person in $team_of_people_who_are_known_to_have_a_clue, can set their own bugs to triaged" | 08:07 |
| Hobbsee | and keeping on bumping the rest through the cron job. | 08:07 |
| greg-g | Hobbsee: people who have a clue can set their own as triaged now right? As in, there is no technological barrier in LP, just an accepted habit. | 08:10 |
| greg-g | (or maybe I just never tried myself and thus not seen that I can't set my own bugs as triaged) | 08:10 |
| Hobbsee | greg-g: correct. | 08:11 |
| lifeless | Rocket2DMn: well, if you closed the bug I referenced above - it wasn't incomplete | 08:43 |
| Rocket2DMn | lifeless, i got the email update, thanks | 08:44 |
| Rocket2DMn | basically just cleaning out shop, and you hadnt responded to the other triager's request to confirm that it still existed. Basically assumed you had abandoned the bug | 08:44 |
| lifeless | its not your fault, but there is a bit of an ostrich problem with closing bug reports simply because they are old - it may just mean the bug is old, and there may well be enough data to reproduce already *even if the user is no longer interested* | 08:45 |
| lifeless | Rocket2DMn: the other triager was lazy/ignorant/something - all the information needed to check was in the report already | 08:45 |
| Rocket2DMn | fair enough | 08:46 |
| lifeless | I *try* to file complete bugs - I file far too many to be retesting them myself everytime Ubuntu releases and they 'might' be fixed. | 08:46 |
| Rocket2DMn | yeah i understand | 08:47 |
| pwnguin | i only file bugs i care about | 08:58 |
| pwnguin | if i dont care enough to retest, it probably merits a "low" status anyways | 08:59 |
| lifeless | pwnguin: I do care about the bugs; its volume. Remember - all software sucks, its just that some sucks less than others. | 09:27 |
| persia | Well, some for some software, we don't know how much it sucks, which makes it harder to fix | 09:33 |
| persia | s/some/and/1 | 09:33 |
| === doko_ is now known as doko | ||
| === wgrant_ is now known as wgrant | ||
| === ogra_ is now known as ogra | ||
| seb128 | james_w: don't mark a task invalid to open a new one, change the product directly rather | 11:29 |
| seb128 | james_w: in the gnome-control-center case it means the gnome-control-center subscribers will still get the comments on the bug | 11:30 |
| james_w | seb128: sorry | 11:42 |
| seb128 | james_w: no need to be sorry, just to know for the next time ;-) | 11:44 |
| james_w | heh :-) | 11:44 |
| seb128 | that could somewhat be considered as a launchpad bug | 11:45 |
| seb128 | though you might still be interested to get comments in such cases | 11:46 |
| persia | I suspect it's one of the side effects of bug 225585 or something related | 11:49 |
| ubottu | Launchpad bug 225585 in launchpad "Ability to individually unsubscribe from bugs your team is subscribed to" [Undecided,Confirmed] https://launchpad.net/bugs/225585 | 11:49 |
| seb128 | persia: the issue is to know if invalidating a task means you don't want to get new comments about it | 11:50 |
| seb128 | in the case where you close the bug because the submitter didn't reply questions or provide enough details you might want to receive new comments | 11:51 |
| persia | seb128: Right. In siretart's recent mail about LP features for LP 3.0, the set of subscription issues was called "/IgnoreSubscriptionsRevenge". There's a few related use cases that aren't ideal now. | 11:51 |
| seb128 | but in the same where the bug has just nothing to do there that's different | 11:51 |
| seb128 | what is lacking now in my opinion is the ability to delete as task | 11:52 |
| persia | Right. I think "Invalid" often means one should still be subscribed, but currently there's no means to unsubscribe implicit subscribers (either individually or as a team), which causes some of the issues with larger task lists. | 11:52 |
| persia | Task deletion sounds like a possible solution. Hmmm.. | 11:53 |
| seb128 | 225585 would be fixed if you could delete the task, which would unsubscribe the corresponding subscribers | 11:54 |
| persia | seb128: Yep. There are a few solutions. | 11:56 |
| Syntux | Good day | 12:01 |
| Syntux | What should we do in bugs that's marked as Triaged but someone uploaded a patch or it was discussed and found as upstream bug ? | 12:01 |
| persia | Syntux: Nothing? | 12:02 |
| persia | Well, you could check the status of the patch or upstream bug, and see if it has been applied to Ubuntu. | 12:02 |
| persia | You might also try to integrate the upstream fix or patch into Ubuntu. | 12:02 |
| Syntux | hmm | 12:03 |
| Syntux | I see | 12:03 |
| persia | Syntux: Essentially bugs in that state are ready for someone (upstream or developer) to do something with them to apply the fix. There's usually not much more to triage. | 12:03 |
| Syntux | persia, shouldn't we change it into confirmed when someone uploads a patch ? | 12:05 |
| persia | Syntux: Not if it's already "Triaged". | 12:05 |
| persia | As I understand it (and there are other views), "Confirmed" means essentially "This is really a bug", and "Triaged" means "This bug is understood and needs a solution prepared". | 12:06 |
| Syntux | that's exactly what I'm saying, a triaged bug with a prepared solution should have different status | 12:07 |
| Syntux | there should be a way to distinguish between triaged bugs (bugs that is understood and needs a prepared solution) and triaged bugs that someone submitted that prepared solution | 12:08 |
| Syntux | I'm missing something here? | 12:10 |
| persia | Syntux: You and I have different definitions of "prepared solution". | 12:13 |
| Syntux | persia, it's not about us my friend :-) can you help me in understanding bugs team definition or prepared solution ? | 12:14 |
| persia | For me, a prepared solution is one of 1) A developer has a fix locally and uploads it (which sets the bug to "Fix Released" when completed, 2) Upstream has integrated a solution (which sets the upstream task to "Fix Released" and adds the bugs to the list of those "Fixed Elsewhere", or 3) Someone attaches a debdiff integrating the solution (in which case the sponsors queue should be subscribed) | 12:15 |
| persia | Well, since "prepared solution" was my language for my personal view of the definitions of the status values, it is about us :) | 12:16 |
| persia | For an official definition, read the wiki pages linked in the /topic | 12:16 |
| persia | Anyway, I don't think bugs should go from "Triaged" to "Confirmed" unless there is some new doubt cast upon the understanding of the bug (which is the opposite of that implied by a patch or an upstream fix) | 12:17 |
| Syntux | maybe should go from Triaged to In Progress. | 12:17 |
| persia | No. "In Progress" should only be set when someone is assigned and actually working on it. | 12:19 |
| persia | Leaving it alone is probably best: there are lots of other bugs. | 12:20 |
| Syntux | if someone submitted a patch it means s/he should be assigned | 12:22 |
| Syntux | it's not about a single bug, the thing is I'm hunting for small bugs so I can work on them but many of these bugs status should be changed to tell that someone has already submitted a patch | 12:22 |
| afflux | morning | 12:24 |
| afflux | Syntux: why should someone be assigned to a bug *after* submitting a patch? | 12:24 |
| persia | Syntux: No. When someone is assigned, nobody else should work on it. If someone submits a patch it is usually because they can't get any further towards fixing it themselves, and the bug now needs someone else to take over. | 12:24 |
| Syntux | afflux, I'm not proposing I'm asking what should the bug status be if someone submitted a patch. | 12:25 |
| persia | Syntux: "Confirmed" or "Triaged", depending. | 12:25 |
| afflux | ah, maybe I got you wrong. persia is right, triaged is correct in most cases. | 12:25 |
| pwnguin | is there a "how to forward bugs to debian" wiki page? | 12:35 |
| afflux | pwnguin: https://wiki.ubuntu.com/Bugs/ReportingToDebian and https://wiki.ubuntu.com/Bugs/Debian/Usertagging may be what you want | 12:37 |
| pwnguin | thanks | 12:43 |
| pwnguin | hmm. reportbug doesn't seem able to connect to bugs.debian.org via SMTP | 12:55 |
| qense | hello | 13:57 |
| nhandler | Hi qense | 13:59 |
| bddebian | Boo | 14:26 |
| === hggdh-away is now known as hggdh | ||
| === mcas_away is now known as mcas | ||
| mcas | hiho | 17:29 |
| mcas | can sameone please look at bug 254673 | 18:37 |
| ubottu | Launchpad bug 254673 in adept "Unclear fault message when apt is locked" [Undecided,New] https://launchpad.net/bugs/254673 | 18:37 |
| mcas | i am not sure if this is invalid or wishlist | 18:38 |
| techno_freak | mcas, looks more like an UI issue | 18:40 |
| mcas | UI? | 18:40 |
| techno_freak | err.. sorry | 18:41 |
| bdmurray | mcas: Why might it be Invalid? | 18:41 |
| techno_freak | it is not invalid, imho, as it makes sense | 18:41 |
| mcas | ok | 18:41 |
| mcas | do you have the rights to mark it as wishlist? | 18:42 |
| mcas | and confirmed | 18:42 |
| techno_freak | mcas, you can confirm it if yourself :) | 18:43 |
| bdmurray | It'd also be useful to tag it as string-fix as this is a simple dialog fix | 18:43 |
| techno_freak | s/if// | 18:43 |
| mcas | yes i can confirm this but i cannot change the importance | 18:43 |
| mcas | ok thanks bdmurray i will tag it | 18:44 |
| mcas | done | 18:46 |
| bdmurray | mvo: ping | 18:51 |
| mcas | bdmurray: was it wrong to confirm the bug about the adept message? | 19:12 |
| bdmurray | mcas: checking if it still existed in intrepid would have been ideal | 19:12 |
| mcas | ah ok thanks bdmurray | 19:13 |
| === jjesse_ is now known as jjesse | ||
| === Hurtz_ is now known as Hurtz | ||
| === jjesse_ is now known as jjesse | ||
| === mcas is now known as mcas_away | ||
| === Martinp24 is now known as Martinp23 | ||
| cisco_ | hi! | 23:39 |
| nhandler | Hi cisco_ | 23:39 |
| cisco_ | I'm member and manager of PuertoRicoTeam, and we want to join on the next bugjam day | 23:49 |
| james_w | cisco_: hey! the one this weekend? | 23:49 |
| cisco_ | yes | 23:49 |
| cisco_ | should we do something? | 23:49 |
| cisco_ | you know | 23:49 |
| cisco_ | like | 23:49 |
| cisco_ | subscribe the team or something like that? | 23:50 |
| james_w | there's a wiki page you can put your team on, I don't know if there are any other requirements. | 23:50 |
| ogra | fix bugs probably ? | 23:50 |
| ogra | :) | 23:50 |
| cisco_ | yep | 23:50 |
| cisco_ | I already red that,,, but should we subscribe the Team> | 23:50 |
| cisco_ | ? | 23:50 |
| cisco_ | for appear in the wiki... | 23:51 |
| james_w | cisco_: you've seen https://wiki.ubuntu.com/GlobalBugJam ? | 23:52 |
| james_w | you can put your team on the list there | 23:52 |
| cisco_ | ok...I just wanted to be sure... | 23:53 |
| cisco_ | thanks | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!