=== menyort is now known as ApOgEE-
[04:28] <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:29] <Camden> what exactly is an "ubuntu bug"?
[04:29] <Camden> wouldn't the bug be in some project
[04:29] <Camden> ?
[04:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:47] <crimsun> sure
[04:47] <crimsun> there are ones tagged "bitesize"
[04:49] <Camden> cool
[04:49] <Camden> sounds like something to try
[04:50] <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:51] <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:52] <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:53] <Camden> anyway whatever
[04:53] <Camden> i'll check those links
=== hggdh is now known as hggdh-away
[07:34] <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:40] <Hobbsee> lifeless: help educate the triagers :)
[07:42] <lifeless> well
[07:42] <lifeless> _how_
[07:43] <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:44] <greg-g> yeah, the first should have checked themselves while the second was just autopilot :)
[07:46] <lifeless> :)
[07:47] <greg-g> if anyone has any suggestions on how to help educate the triagers it might help
[07:48] <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:49] <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:50] <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:51] <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:52] <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:53] <greg-g> right
[08:04] <Rocket2DMn> ive actually been working on these ancient incomplete bugs
[08:04] <Rocket2DMn> been closing many of them
[08:07] <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:10] <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:11] <Hobbsee> greg-g: correct.
[08:43] <lifeless> Rocket2DMn: well, if you closed the bug I referenced above - it wasn't incomplete
[08:44] <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:45] <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:46] <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:47] <Rocket2DMn> yeah i understand
[08:58] <pwnguin> i only file bugs i care about
[08:59] <pwnguin> if i dont care enough to retest, it probably merits a "low" status anyways
[09:27] <lifeless> pwnguin: I do care about the bugs; its volume. Remember - all software sucks, its just that some sucks less than others.
[09:33] <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
=== doko_ is now known as doko
=== wgrant_ is now known as wgrant
=== ogra_ is now known as ogra
[11:29] <seb128> james_w: don't mark a task invalid to open a new one, change the product directly rather
[11:30] <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:42] <james_w> seb128: sorry
[11:44] <seb128> james_w: no need to be sorry, just to know for the next time ;-)
[11:44] <james_w> heh :-)
[11:45] <seb128> that could somewhat be considered as a launchpad bug
[11:46] <seb128> though you might still be interested to get comments in such cases
[11:49] <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:50] <seb128> persia: the issue is to know if invalidating a task means you don't want to get new comments about it
[11:51] <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:52] <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:53] <persia> Task deletion sounds like a possible solution.  Hmmm..
[11:54] <seb128> 225585 would be fixed if you could delete the task, which would unsubscribe the corresponding subscribers
[11:56] <persia> seb128: Yep.  There are a few solutions.
[12:01] <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:02] <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:03] <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:05] <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:06] <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:07] <Syntux> that's exactly what I'm saying,  a triaged bug with a prepared solution should have different status
[12:08] <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:10] <Syntux> I'm missing something here?
[12:13] <persia> Syntux: You and I have different definitions of "prepared solution".
[12:14] <Syntux> persia, it's not about us my friend :-) can you help me in understanding bugs team definition or prepared solution ?
[12:15] <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:16] <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:17] <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:19] <persia> No.  "In Progress" should only be set when someone is assigned and actually working on it.
[12:20] <persia> Leaving it alone is probably best: there are lots of other bugs.
[12:22] <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:24] <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:25] <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:35] <pwnguin> is there a "how to forward bugs to debian" wiki page?
[12:37] <afflux> pwnguin: https://wiki.ubuntu.com/Bugs/ReportingToDebian and https://wiki.ubuntu.com/Bugs/Debian/Usertagging may be what you want
[12:43] <pwnguin> thanks
[12:55] <pwnguin> hmm. reportbug doesn't seem able to connect to bugs.debian.org via SMTP
[13:57] <qense> hello
[13:59] <nhandler> Hi qense
[14:26] <bddebian> Boo
=== hggdh-away is now known as hggdh
=== mcas_away is now known as mcas
[17:29] <mcas> hiho
[18:37] <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:38] <mcas> i am not sure if this is invalid or wishlist
[18:40] <techno_freak> mcas, looks more like an UI issue
[18:40] <mcas> UI?
[18:41] <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:42] <mcas> do you have the rights to mark it as wishlist?
[18:42] <mcas> and confirmed
[18:43] <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:44] <mcas> ok thanks bdmurray i will tag it
[18:46] <mcas> done
[18:51] <bdmurray> mvo: ping
[19:12] <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:13] <mcas> ah ok thanks bdmurray
=== 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
[23:39] <cisco_> hi!
[23:39] <nhandler> Hi cisco_
[23:49] <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:50] <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:51] <cisco_> for appear in the wiki...
[23:52] <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:53] <cisco_> ok...I just wanted to be sure...
[23:53] <cisco_> thanks