[07:26] <dholbach> good morning
[08:47] <nigelb> dholbach, hey.  got some time?
[08:47] <dholbach> nigelb: a bit, yes
[08:47] <nigelb> can you do a review of the current https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved
[08:48] <nigelb> the problem is we haven't run into all the use cases yet, so I'm still actively reviewing to come into all the use cases so I add them as examples
[08:48] <dholbach> sure
[08:48] <dholbach> who should I mail with my feedback?
[08:48] <nigelb> just ping me :)
[08:48] <dholbach> persia, bryce, bdmurray, james_w, you? somebody else?
[08:48] <nigelb> or mail me
[08:48] <dholbach> I just thought it'd be good to keep the discussion in the team going :)
[08:49] <dholbach> but I can mail just you too
[08:49] <nigelb> dholbach, if you want to start a new thread with the entire discussion, I think thats fine too :)
[08:49] <dholbach> I'll do it a bit later today, I first need to get some other stuff done
[08:49] <dholbach> but I'll definitely do it today
[08:49] <dholbach> thanks for your work on this!
[08:49] <nigelb> lot more to go :)
[08:49] <dholbach> :-)
[08:50] <nigelb> oh and just to keep the motivation going
[08:50] <nigelb> we have only 135 bugs in the "to be reviewed queue"
[08:53] <Ciemon> nigelb: are those pre-freeze reviews?
[08:54] <nigelb> Ciemon, well, we'll try to get as many before freeze as possible
[08:54] <nigelb> but I dont think much will happen
[08:54] <Ciemon> ok
[08:54] <nigelb> like, I'm working on 6 bugs now.  I'll probably try and get all of them it :)
[08:54] <Ciemon> I have some time, but my new patching knowledge often needs guidance
[08:55] <Ciemon> ask Daviey :)
[08:55] <nigelb> Ciemon, what part are you having trouble with
[08:56] <Ciemon> oh, not trouble.. just lack of knowledge.
[08:56] <Ciemon> :)
[08:57] <nigelb> you can always ask in #ubuntu-motu, the responses are fairly fast
[08:57] <Ciemon> yep, thanks
[09:04] <Daviey> Ciemon wants to close 4 bugs with his branch
[09:04] <Daviey> so that'll help the stats ! :)
[09:05] <nigelb> you can do that :)
[09:05] <nigelb> (actually encouraged, so that you dont clutter the rev numbers)
[09:06] <Daviey> nigelb: yeah, he did have it as two items.. but the first one hadn't been sponsored yet, so he cleaned it down to 1
[09:06] <nigelb> Daviey, nice :)
=== dholbach_ is now known as dholbach
[16:26] <nigelb> persia, any thoughts regarding what I PM'd you a few days back?
[16:30] <persia> So, the last couple times you asked me, I replied in /query, and it seems not to have stuck.
[16:30] <persia> Anyway, geser summed up my opinion fairly well in -motu when you asked there.
[16:30] <nigelb> it was an unsure move anyway
[16:31] <nigelb> so, any intersted devs can straight away join is better?
[16:31] <persia> No.
[16:31] <persia> But I suspect that any developer that comes by here and reads our procedures ought get in speedy-like.
[16:32] <nigelb> the trouble I'm facing is recruiting review leads
[16:32] <persia> Yeah, I'm expecting most of them to end up being me.
[16:32] <persia> Although I hope you'll fill in any times you can.
[16:32] <nigelb> I will
[16:33] <nigelb> btw, cypher_mox has agreed to help too :)
[16:33] <nigelb> and james__w and maco_ will depending on schedule then
[16:33] <persia> Be aware that some folks have nifty highlighting that _ doesn't skip.
[16:33] <nigelb> persia, I tried :D
[16:34] <nigelb> crimsun if his schedule permits though his suspects he might be busy that week
[16:34] <persia> I suspect many folks will be busy dealing with the sync flush + UDS preparation
[16:34] <nigelb> if their script catches their name, not my fault :D
[16:35] <nigelb> yup, thats what I'm afraid of
[16:39] <nigelb> persia, if its any consolation, only 132 bugs in review queue
[16:39] <nigelb> It can be reduced to 117 since a few of them are kernel or packages we need to ignore
[16:42] <persia> Cool.  I've a couple things on my plate now, but will take a swipe through sometime tonight: maybe we can get down to < 100 :)
[16:42] <nigelb> thats what I'm hoping for
[16:43] <nigelb> what happens if we get it down to 0? party? :D
[16:47] <persia> If you like, but there's still all the old patches to tackle.
[16:48] <persia> If we get *that* down to 0, someone needs to start a new patch creation initiative.
[16:48] <nigelb> yeah, its down to 1797
[16:48] <nigelb> lol, so we'll have patch creation team :D
[16:49] <persia> So, I'm expecting that in maverick+1 or maverick+2 we'll be able to have classes "How to fix bugs" for bugsquad again, and get more people contributing fixes.
[16:49] <persia> Right.
[16:49] <persia> And we'll encourage the patch creation team to follow-up with upstream, etc.
[16:49] <persia> But that's the future: let's concentrate on the bugs we have now :)
[16:49] <nigelb> we'd then we a *really really good* distro
[16:49] <nigelb> s/we/be
[16:50] <persia> I guess.  My thought is more that we ought leverage our strong point (lots of users) as much as possible to help everyone.
[16:51] <nigelb> I was thinking we move the starting date up for the script once we get to less than 20
[16:51] <persia> Sounds reasonable.
[16:51] <nigelb> Let me get to work on a few patches, some of them can still be removed from review queue
[16:52] <nigelb> ah, dan has given me more work on the wiki
[16:52] <nigelb> are you up-to-date on mails?
[16:53] <nigelb> dholbach, the patch-rejected-tag is to be used when upstream doesn't want to incorporate it in, when they want changes to it, it becomes patch-needswork.  See bug 33288
[16:54] <ubot3> Malone bug 33288 in poppler "Evince doesn't handle columns properly" [Unknown,Confirmed] https://launchpad.net/bugs/33288
[16:54] <dholbach> nigelb: right, I'm asking "when is patch-*-rejected tag going to be != patch-needswork"
[16:54] <nigelb> dholbach, I'll hunt down a use case from gnome upstream
[16:55] <dholbach> it would mean "ok we forwarded it upstream, they don't want it, but we'll use it anyway", right?
[16:55] <nigelb> its like work that ayatana does
[16:55] <nigelb> some stuff is ubuntu specific that upstream doesnt want in their code base
[16:56] <nigelb> so they reject the patch, but if its something we'd like it, we'll know it was forwarded and they didn't want it in
[16:57] <nigelb> persia, got anything to add to ^
[16:58] <dholbach> I think it'd be better if we made the decision process so that we don't need those tags :-)
[16:58] <dholbach> but it's basically just a foot note
[16:58] <dholbach> nothing too important
[16:58] <dholbach> I'd just prefer if we had less tags ;-)
[16:58] <persia> I've had patched rejected as not-needswork.
[16:59] <persia> For example, a patch to implement some feature that upstream said didn't belong in the software at all.
[16:59] <dholbach> right
[16:59] <persia> (I know: let's make dpkg a mailreader!)
[16:59] <dholbach> in that case it'd still be a patch-needswork for us
[16:59] <nigelb> hehe.  we could just change it to patch-rejected and add comments as to which upstream (debian vs all the way upstream)
[16:59] <dholbach> we have an open bug that we want to resolve somehow
[16:59] <persia> dholbach: Why?  How is adding mail reader support to dpkg "needs-work"?
[16:59] <dholbach> if upstream says "please do it differently" that's the decision we want to hear
[16:59] <persia> There's no sensible work that can improve that?
[17:00] <dholbach> ok, then we won't fix the bug too
[17:00] <nigelb> then we'd like to see why as soon as we open the bug
[17:01] <persia> But patch-rejected-upstream != patch-rejected
[17:02] <dholbach> all I'm saying is: if I have difficulties getting the sense of these tags, there will probably be a bunch of others who have more problems
[17:02] <dholbach> :)
[17:02] <persia> Quite possibly.
[17:02] <dholbach> the decision tree is not quite clear and "patch-rejected-upstream" is in no way a "final stage of the bug or patch"
[17:02] <persia> I suspect we need a significant body of data to actually interpret the tags properly.
[17:02] <dholbach> I personally would have preferred tags that indicate what needs to be done with the bug / patch
[17:02] <dholbach> so we could use them as working lists
[17:02] <persia> No, patch-rejected-upstream only says that upstream didn't want it: we might want to carry it, or we might want to rework it.
[17:03] <dholbach> but anyway
[17:03] <persia> dholbach: Do you have an alternate strategy/workflow for all the tags?  If you've a better one, I'm sure the rest of us would be willing to adjust.
[17:04] <dholbach> I proposed something in a mail I sent to the first discussions of the team
[17:04] <dholbach> but I have a call coming up now
[17:06] <persia> I see that, but I can't imagine how we can know what has been sent upstream, or what upstream responses we have with that.
[17:06] <persia> Anyway, tell me after your call if you like :)
[17:07] <nigelb> i'll try incorporate what you've suggested and yes, we're open to suggestions :)
[17:31] <nigelb> So, when to forward to debian?  When issues are in something inside /debian and when upstream is dead and we still sync from debian?
[17:50] <nigelb> persia, can reply ^ when you get time
[17:53] <persia> I think we should forward to Debian whenever the issue expresses itself in Debian
[17:53] <persia> That means testing in Debian, of course.
[17:54] <persia> If we *also* forward upstream, it's trivial to tell the Debian BTS that it's been forwarded upsteam, and the Debian maintainer can make a determination as to how to proceed.
[18:05] <nigelb> persia, lost power for 10 mins just after I asked you.  but got the answers :)
[18:12] <nigelb> ok, so replied to dholbach's mail  :)
[18:27] <nigelb> persia, we need to come up with something for bugs like bug 511502
[18:27] <ubot3> Malone bug 511502 in xdvik-ja "TeXLive 2009 transition: libkpathsea5" [Undecided,Fix released] https://launchpad.net/bugs/511502
[18:28] <nigelb> there are patches, but all sponsored, but there are open tasks, so end up in review queue
[18:28] <persia> I think the real solution is to convince people not to file those bugs, and complain when they do.
[18:28] <nigelb> huh?
[18:28] <persia> It's duplicate information (see the NBS page), and mostly useless.
[18:28] <persia> Plus it annoys all sorts of folk who are subscribed to the packages.
[18:29] <nigelb> yeah
[18:29] <nigelb> There are a couple more of those bugs.  I'm waiting for update to the script to deal with these for now
[18:29] <persia> Making them go away takes time and education.
[18:30] <nigelb> isn't it easier to open multiple bugs?
[18:30] <persia> No.  It's trivial to open a bug with lots of tasks.
[18:30] <persia> It just happens to be completely useless for that class of issue.
[18:30] <nigelb> Its mostly our developers themselves who do it :(
[18:31] <persia> I know.
[18:31] <persia> For now, I suggest the reviewers team completely ignore them.
[18:31] <persia> If I can make them go away, I will, but I'm unsure I can do that easily.
[18:31] <nigelb> or create lots of noise that people stop fililng it :D
[18:35] <nigelbabu> persia, *sigh* oh well, your point just got re-emphasized
[18:36] <nigelbabu> can PM me what you said after "nigelb> or create lots of noise that people stop fililng it :D" ?
[18:37] <persia> No, because you're not here :)  But I didn't say anything, so perhaps I can, as the receipt of nothing would comply with the request to send nothing :)
[18:38] <nigelbabu> persia, sometimes I wish you spoke English.
[18:38]  * nigelbabu smirks
[18:41] <nigelbabu> persia, so is there a way to show only 1 instace of those type of bugs?
[18:43] <persia> Search only for a given source package :)
[18:44] <nigelbabu> persia, :P  I meant in the review queue
[18:45] <persia> I don't think so: we've had that issue in the sponsoring queue before.  Since the only sensible justification for those massive bugs is to help sponsor other people's NBS work, this makes it useless even for it's intended purpose.
[18:46] <nigelbabu> sigh :x