#ubuntu-reviews 2010-04-05
<mpontillo> thanks all. I read the workflow on the wiki; one question: when you add the 'patch-needswork' (or any other patch-*) tag, do you remove the 'patch' tag at that point or keep it? Looking in launchpad, I see people doing it both ways
<mpontillo> ... also, I'm trying to understand which patches should vs. should not be accepted into Ubuntu. I guess after release, if it's a higher risk item (sync from Debian for a new release) it would go into -backports, and if it's a lower-risk but higher priority (i.e. crash fix) it would go into -updates ...
<mpontillo> ... but before release, I'm assuming the general strategy is that serious things that would be -updates make it in, but things that would go into -backports we wait and sync from Debian
<nigelb> mpontillo, generally things that go into -updates and -backports need to go into a development version first
<nigelb> now, the best thing would be to forward the patches upstream
<nigelb> initially when the guide was written we planned to remove the patch tag, but that is messing up with the script that subscribes ubuntu-reviewers to bugs with patches
<mpontillo> thanks nigelb; sounds like the 'patch' tag should be left on through the entire process (until the the patch has been rejected or integrated into some release). I can clarify the text on the wiki if you like
<nigelb> I know... I wrote it :D
<nigelb> so, now you just leave the patch tag in there
<nigelb> persia, how much backlogged into mails are you?
<persia> 9 days
<nigelb> ouch, ok.  I'll not mail
<nigelb> well, updates include some pretty graphs (see topic)
<nigelb> patch day moved up to wednesday may 5th
<nigelb> and I still need to convince brian to make the script understand 'patch*' tags
<nigelb> persia, did you see ^
<persia> I did.
<nigelb> I could use some help with the convincing
<persia> Have you tried putting it on the QA team meeting agenda?
<nigelb> em, no
<persia> It's at a really inconvenient time-of-day, but maybe one of us might be awake for it sometime in the next couple weeks.
<persia> If not, perhaps someone else would be willing to present, based on some wiki page clearly stating the position.
<nigelb> I asked bryce a few days back
<nigelb> he said he'd talk to brian... but really... it would be nice to have the 3 or 4 of us
<nigelb> I wish I could be there at uds :(
<nigelb> just needs the few active people to come together and sit down and talk
<nigelbabu> did I miss something?
<nigelbabu> persia, qa team meeting is okay time for me... it generally isn't around 3 hours right?
<persia> nigelb: It usually lasts about an hour.  If it's an OK time for you, then please raise it.
<persia> nigelb: If it can't be sorted pre-UDS, I'm definitely up for trying to catch the folks involved there.
<nigelb> persia, we can try to talk to bdmurrary once before that
<persia> At least once :)
<nigelb> well, if I can get you, bryce, bdmurray, and jcastro together for 20 minutes it would be extremely productive
<nigelb> (these would be the people who are interested in getting the review queue going)
<nigelb> also, MOTU should ideally promote review queue as stepping stone to packaging training
<persia> I think we have to demonstrate that the review queue works before we can convince MOTU it's the right place to send prospective folk.
<persia> And if you don't try to include me in that list, it might be earlier, because the rest of the folks are close timezone-wise.
<nigelb> by getting the review queue down to zero?
<nigelb> yeah... well.. as many as humanely possible
<persia> Well, either down to a non-frightening number, or demonstrate sufficient progress that there is a sane expectation that it will be there soon.
<nigelb> well.... I for one think we should be focusing on the subscribed bugs
<nigelb> that is a definite way to get things moving
<nigelb> but just one person working on things isn't going to create magic overnight :(
<persia> It's not just one person though, is it?
<nigelb> well <10
<persia> That's a number I'll believe.
<persia> MOTU started with about 3 folks: it's just a matter of docs and publicity.
<nigelb> Oh!
<nigelb> In that case, I guess we still have hope
<persia> Absolutely.  My expectation is that the reviewers team will reach a state of being a first-class participant in the basic workflows sometime around November.
<nigelb> did you sign up for being a contact on patch day?
<persia> Doesn't mean that we don't have a lot to do now, but it always takes a while to get from a few interested folks to somewhere else: basically we have to demonstrate that we do enough to be worth consulting when other folks are doing stuff.
<nigelb> yes, i.e., as established reviewers
<persia> I didn't yet.  I'll take a bunch of the slots that are left open at the end: I'm flexible and in an unpopular timezone.
<persia> Right.
 * vish always wondered what timezone persia was in :)
<nigelb> vish, jp
<vish> ah..
<nigelb> that's why he's always around when we're around
<vish> hehe , i was thinking he was at the other end , alaska or somewhere ;)
<nigelb> persia, I wanted an established reviewers team member to start off patch day
<persia> I'm only 3:30 offset from there most of the time.
<persia> nigelb: Your local time at day-start is 15:30, right?
<persia> Is that bad for you?
<nigelb> yep.. I'll be at work
<persia> Maybe nhandler or bdmurray can start.  If not, I will.
<nigelb> I'll try to catch bdmurray
<nigelb> will you be up around the time he's waking up?
<nigelb> today i.e.
<persia> Maybe.  The other side of the day works better for that combination, but is bad for you :)
<nigelb> set a time...
<nigelb> I'll go to bed early if need me
<nigelb> be
<persia> I think he's usually around something like 15:00 to 28:00 or so.  I'm usually around 0:00 to 16:00 or so.
<nigelb> UTC?
<persia> Yeah.
<nigelb> so 23:00 UTC sounds fine?
 * nigelb gulps ... 3:30 am
<nigelb> still.... it would be very productive I guess
<persia> I'm not sure it would be that productive.  I'm not that diurnal, so maybe better to schedule something for a day I'm around later.
<persia> Tuesday or Thursdays are often good candidates.
<nigelb> Tuesday is meeting horror day
<nigelb> everyone is bound to be busy
<persia> Well, there's no QA meeting, and that's what keeps me around until 17:00 or 18:00 most weeks.
<nigelb> so tomorrow at 23:00 seems better?
<persia> Why 23:00?
<nigelb> 17:00?
<persia> tomorrow at 16:00 ought be fine.
<persia> Or 17:00.
<persia> But I don't know that I'll be up that late tonight.
<nigelb> that time is fine with me too
<nigelb> so tomorrow it is
<persia> Thought so :)
<nigelb> information that needs to be added to reviewers team wiki?
<nigelb> https://wiki.ubuntu.com/ReviewersTeam/KnowledgeBase
<nigelb> I can't think of any
<persia> There's work needing doing to better integrate stuff (especially the simple patch/debdiff stuff), and it needs a pointer to the workflow, but yeah, otherwise seems complete.
<persia> Personally, I'd rather see it organised in terms of activities, but that will come with time and practice doing stuff.
<nigelb> I was thinking of having a how to generate patches from svn and git but that seemed too much
<persia> For us, yeah.
<persia> I think it's worth having that documentation in general though.
<persia> But I think it's more valuable for MOTU docs.
<nigelb> it would be appropriate for us to have it as we're the people upstreaming patches
<persia> Good point.
<persia> Although I think that the docs would be slightly different for the different audiences.
<nigelb> yes. definitely.
<persia> THe base stuff is the same, but the HOWTO differs between case A: someone has a patch and wants to apply to upstream, and generate something to send for review vs. case B: someone knows a fix is upstream and wants to cherrypick to generate a debdiff.
<nigelb> exactly
<nigelb> which means the wording might get a lile tricky
<persia> Or maybe it involves three documents.  One is "How to use the tool", and two are example workflows using the tools.
<persia> Then the dev pages *and* the reviewers pages can reference it.
<nigelb> or one "how to tool" and we'll link it up differently in 2 pages
<persia> with inclusion.  That works.
<nigelb> yep.  inclusion is what I thought too
<nhandler> persia: I can only do a 15:30 on a Sunday sadly
<persia> nhandler: No worries.
<nigelb> I'm holding off on creating page on git and svn how-to
<nigelb> each upstream might have different policies and I need to go through the bigger ones at least
<nhandler> nigelb: Instead, why not try and link to (or ask upstream to create) those guides ?
<nhandler> They will be more accurate and better maintained, and more people can benefit from them
<nigelb> when I submitted code upstream, generally, i had to look for generic guides and teak them
<nigelb> like look for a generic guide to submitting patches in git and then looking at upstream style guides
<nhandler> nigelb: Which is why you should ask the upstream that uses git to update their guides to include enough basic info about git for beginners to contribute
<nhandler> nigelb: Also, what is Debian/QADelta ? Is it meant to list the reasons for diverging from Debian?
#ubuntu-reviews 2010-04-06
<nigelb> nhandler, its meant to show list of QA packages where we have a delta from debian
<nhandler> What do you mean by QA packages nigelb ?
<nigelb> err.. packages maintained by debian QA team... the orphaned packages
<nigelb> <DktrKranz> I prepared a list of orphaned packages with Ubuntu changes: http://merkel.debian.org/~dktrkranz/ubuntu_QA   It could be interesting uploading such changes to Debian as QA uploads if feasible, thoughts?
<nigelb> <ScottK> It's a good idea.  I've been doing that as I run across such packages.
<nigelb> <DktrKranz> some packages could be candidate for removal as well, but at least there's a chance to reduce deltas a bit. Any idea how to spread it?
<nigelb> nhandler, ^
<nhandler> nigelb: Ah ,ok
<nigelb> nhandler, some of those changes need not be sent back.. hence I put it onto a wiki
<nigelb> nhandler, will you be around at 1630 UTC ?
<nigelb> persia, well, in case you're swamped by mail, brian and jcastro are +1 for 1630 :)
<nhandler> Darn, missed him.
<persia> He'll be back :)
<dholbach> good morning
<nigelb> persia, um.. can you chair the meeting?
<persia> meeting?
<persia> I thought it was a semi-informal chat
<nigelb> yeah.. someone has to semiformally lead it :)
<persia> Oh, I can do that.  Do we have some list of decisions we need made?
<nigelb> I'll make an etherpad
<persia> Sounds like a plan :)
<nigelbabu> <nigelb> http://etherpad.com/aryJjRUeik
<nigelbabu> <nigelb> anyone wants to contribute to things to be discussed, feel free to add ^
<dholbach> persia: do you know who else was invited to the meeting? is it going to be in 1h36m?
<persia> No, yes, and I only found out it was a "meeting" about 90 minutes back: I just thought it was nigelb, bdmurray, and myself talking about the patch subscribing script.
<dholbach> ok
<maco> haha
<dholbach> I'll be there too, but I think I'll go back home before the meeting starts
<persia> OK.
<persia> Apparently, I'm chairing, so I'm happy to wait :)
<dholbach> see you later :)
<nigelb> persia, anything more to add to http://etherpad.com/aryJjRUeik ?
<persia> No.
<persia> I have opinions about #2 and #3, but I'm really only around to talk about #1, which seems easy enough.
<persia> Did you ever write up the behaviour you *wanted* the script to have?
<nigelb> well, I was hoping we'd have a consensus on #2 and #3
<persia> We may :)
<nigelb> the script would consider bugs with patch* tags processed would be what I *wanted*
<nigelb> i.e. not adding patch again if another patch-* tag is present
<persia> That ought be simple enough.  HAve you found the source?
<nigelb> um, no brian has not yet shared it
<persia> Aha!
<nigelb> I had asked if he could put it in bzr and sync to the box that runs it once a day
<nigelb> that way we could request merges, etc
<nigelb> (to the script that is), but I guess he's just a bit busy with release nearing, etc
<persia> Probably.
<dholbach> I forgot again... who apart from bdmurray were we waiting on? :)
<persia> nigelb: ?
<nigelb> jcastro
<dholbach> ah ok
<nigelb> and bryceh if he's around
<dholbach> hi bdmurray
<bdmurray> hello
<nigelb> persia, I guess we can get started now :)
<persia> OK.  So nigelb twisted my arm to make me chair a "meeting", but please consider his opinions strongly, as he's the instigator of all this.
<hyperair> tsk nigelb =p
<persia> Agenda is at http://etherpad.com/aryJjRUeik
<persia> First topic is to look for changes to the patch subscription script.
<persia> nigelb: I think you wanted to have it not re-add "patch" when "patch-foo" was present?
<nigelb> yup
<persia> bdmurray: Is there a branch somewhere that could be used to make that adjustment, or do you have concerns about doing that?
<nigelb> bryce_ helped make the review guide (https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved) more prettier and some of his edits made sense.  But this version would require the script to be intellegent to all the tags
<bdmurray> there is no branch that contains that script yet additionally it checks to see if the patch tag was already there so why remove the tag?
<bdmurray> I mean I don't see a need to remove the patch tag just add patch-foo in addition to patch
<dholbach> I'm still not sure I understand what the script should be doing. :)
<persia> dholbach: Subscribing ubuntu-reviewers to a sensible subset of the patch bugs so we have a manageable target.
<nigelb> dholbach, the script subscribes ubuntu-reviewers to all bugs with patches
<nigelb> well, after a certain date
<persia> dholbach: Also, trying to merge all the different ways that patches are identified into one format.
<bdmurray> right so any new bugs with patches
<nigelb> my only worry is that LP really doesn't allow negation while searching
<persia> Which makes it hard to search for bugs that have patches but have not yet been reviewed?
<nigelb> like searching bugs with patch tag but without patch-forwarded-upstream
<bdmurray> I think negation is possible if not with the web interface with the api
<persia> Definitely with the API, and definitely not with the web interface, but most of us use the web interface.
<dholbach> I use http://people.canonical.com/~dholbach/resubscribe for a different purpose right now - maybe that can be used?
<hyperair> launchpad should sprout support for google-like syntax for searching
<bdmurray> its says right in the web interface that it works
<bdmurray> #  Find bugs that don't have the test tag:  search for -test
<persia> Ah, cool.  I never got that to work, but I haven't tried in a while.
<persia> So that makes this moot, I think.  nigelb?
<nigelb> yes, we can move on :)
<nigelb> I'll edit the review guide appropriately
<jcastro> wait!
<persia> Great.  Item 2:  Patch Day and thoughts on current implementation.
<persia> OK.  Back to item 1.
<persia> jcastro: ?
<jcastro> we already know the patches because lp figures that out for the +patches view
<jcastro> so maybe we can ask the lp team to just sub the right team when a patch is attached?
<persia> jcastro: No.  That fails in all sorts of ways.
<jcastro> ok, explain that to me after then, I don't want to hold up the agenda
<persia> I've commented at length in the various LP bugs on the subject, but essentially not every patch happens to be a text file attached with the patch flag.
<nigelb> Its a nice feature for teams like X
<bdmurray> jcastro: there are various exceptions for if the sponsors team is subscribed etc...
<nigelb> but not for others
<jcastro> ok
<persia> jcastro: Just to confirm your thoughts, that does work about 90% of the time, it's just the rest that are tricky.
<nigelb> release team subscribed, merges, etc
<persia> Anyway, item 2: Patch Day and thoughts on current implementation.
<nigelb> this is the current way we wish to implement https://wiki.ubuntu.com/PatchDay
<persia> I presume that's described at https://wiki.ubuntu.com/PatchDay
<nigelb> persia, would you like to summarize here? since it was originally your idea :)
<persia> nigelb: So, what's to discuss here?
<persia> Um, my "idea" was just that if we're going to have a patch day, we just schedule some time, have someone responsible for keeping things going in shifts, and do it.
<bryce_> personally I think it's not the best way to achieve this
<bryce_> I understand the objective is to make the bar low so many people can participate
<persia> I'm open to formalisation if someone thinks it will help, but I feel we would do better to develop policies based on what we discover to be best practices.
<bryce_> however in practice I think you find one guy that's really motivated can do more than 10 random joiners
<bryce_> so I'd suggest instead of holding a ** Day, to focus on finding and recruiting those specific super contributors
<persia> That makes more sense to me than having special days.
<bryce_> anyway, just my opinion ;-)
 * persia has the sense that special days discourage people from contributing the rest of the time
<dholbach> I'm not sure that's true - it can be great to get together as a team, set a goal and achieve it
<dholbach> especially if there's no team yet
<nigelb> it makes things move and help us look back to what we've achieved
<bryce_> dholbach, that has not been my experience with X
<persia> Nor mine with REVU
<nigelb> But I did see that with hugdays :)
<bryce_> possibly we're doing it wrong ;-)
<dholbach> well, I'm not saying we shouldn't have tuition sessions :)
<dholbach> I think we should have them too
<dholbach> https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved looks good already, but I guess it needs a few examples and stuff, so people know can more easily guess what we'd like them to do
<nigelb> dholbach, I'll get to work on that. :)
<dholbach> also having a XYZ Day helps with people who want to get involved but don't know who they can talk to
<persia> I guess.  I'd rather have staffed channels, but that takes more commitment from everyone involved.
<dholbach> and we can always try a few things out and see how they work
<nigelb> dholbach, Hence, the idea of rotating staffing
<dholbach> it's not like we need to keep tuition sessions or patch days going if we see they don't work
<persia> Anyway, my feeling is that if some folk want to have a "Patch Day", let's have one.  If it's a huge success, let's have more.  Scheduling for every other saturday in advance seems ambitious.
<hyperair> i think having XYZ days helps in having the channels staffed sufficiently.
<nigelb> persia, that needs to be edited.  It was the initial edit of the bug day wiki page :)
<dholbach> shall we move on or do we want to discuss date, time and organisation already?
<persia> Does may 5th work spetacularly badly for anyone?
<nigelb> Date is May 5th, jcastro and I are working on an announcement to -devel
<dholbach> ok
<persia> I strongly believe that time should be "all day, in your timezone", which makes it 50 hours.
<jcastro> I agree
<hyperair> i agree as well
<persia> For organisation, what I suggested to nigelb was based on the very old bug days, when we had a channel contact who would keep things going and hand off to the next person.
<persia> WHich I believe resulted in the big table.
<persia> Does that work for an initial day for everyone?
<dholbach> do we have enough people who know about the process and stuff?
<hyperair> big table?
<persia> hyperair: Under "Contacts" in https://wiki.ubuntu.com/PatchDay
<hyperair> hmm i see
<persia> dholbach: At the current time, I think it's semi-fluid, based on the docs written up by nigelb and bryce_ , so there's two folk who know stuff.  I'm happy to take some slots.
<dholbach> ok
<nigelb> We're also hoping to recruit after the announcement
 * dholbach marks day in calendar
<dholbach> that should also leave us enough time for reviewing docs
<nigelb> also, please review the wiki for any additions/deletions
<nigelb> if some thing needs to be added, add to the TODO page
<nigelb> https://wiki.ubuntu.com/ReviewersTeam/TODO
<persia> Or just do it :)
<nigelb> yeah, that works too :)
<persia> OK.  Anything else about PatchDay?
<bdrung> nigelb: https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved -> Workflow -> first entry should have a LP link
<persia> RIght then.  Moving on: Item 3: Policy for new members to join
<dholbach> I think it'd be good if they could mention a couple of bugs they already worked on
<nigelb> bdrung, the LP subscribed bugs?
<dholbach> so they demonstrate that they know when to forward stuff to upstream and debian and how to do it, etc
<persia> My personal thought is that until we develop enough popularity that we end up being unsure, we let anyone already on the team endorse anyone else, and that lets them on the team.
<bdrung> nigelb: yes
<dholbach>  + people we know who do good work
<persia> dholbach: I don't want to add anyone to the team unless they ask.  I know folk who don't like to be on too many teams.
<dholbach> sure, that's not what I meant
<persia> Oh, yeah.  I completely agree that "people we know do good work" is the right criterion.
<dholbach> endorsements-for-people-who-asked + people-who-can-show-they-did-good-work-for-people-who-asked
<bryce_> how many people are you expecting will want to join?
<dholbach> bryce_: there's already a bunch that tried to join :)
<bryce_> dholbach, oh, how many?
<persia> bryce_: I think ~50 members would be a good target.
<dholbach> bryce_: I think 10 in the last month (and that with the little publicity the team got)
<persia> Trick being that lots of folks try to join teams like this to get their stuff reviewed, rather than review other people's stuff.
<nigelb> sorry, got disconnected
<bryce_> persia, ah, so are you assuming 50 active contributors, or 50 of which a subset is contributing?
<dholbach> so process-wise, I think we should ask people to apply for membership through LP, if we know they do good work, approve them, if not, they should come to #ubuntu-reviewers show a few bugs they worked on (regarding the review team process), then make the decision
<persia> bryce_: I'd be happy with 30 (rotating) active of 50 as a target.  I expect that's going to take > 6 months to reach.
<dholbach> so it doesn't get to heavy-weight
<persia> dholbach: Sure, but I'd like the process here to involve some *current* member (maybe an admin, maybe not) endorsing them (over IRC is fine).
<dholbach> persia: yes, sure
<dholbach> persia: who else would?
<persia> Something like "I want to join", "I know you, yeah" OR "I want to join", "what have you done?" "this" "that looks good, sure".
<persia> I'm just worried about formalisation, councils, etc.  I think we're not mature enough to need that yet, and I think it creates false barriers to entry due to individuals internal perceptions.
<dholbach> sure, that wasn't my plan
<nigelb> I agree
<nigelb> something simple but something agreed upon
<dholbach> the good thing is that nobody is blocked because of lacking team membership
<dholbach> they can still do good work
<persia> RIght.
<dholbach> ok great
<nigelb> only they can't unsubsribe, its only a matter of asking here :)
<persia> Alright then.  Anything else anyone wants to raise whilst we're all here?
<dholbach> not from me
<bryce_> I have an anecdote
<bdrung> are there any plans to create scripts?
<bdmurray> I had one question too
<bryce_> yesterday I looked through the 'audacious' bugs (a music player I use which has been quite buggy)
<bdrung> bryce_: i saw that
<bryce_> I saw half a dozen patches posted, and thought, "Wow, someone's been active, I should sponsor these!"
<bryce_> then I looked and saw they were all patches I had made and posted 1.5 yrs ago hoping someone would sponsor them :-/
<nigelb> lol
<bryce_> so... there's definitely a need for this ubuntu-reviewers team :-)
<persia> Yeah.  It's been about 1.5 years since we identified the need, but until nigelb started pushing, everyone was busy with something else.
<bryce_> on the topic of scripting...  you know I definitely am more of a fan of automation over crowd-surfing to solve problems like these
<nigelb> bryce_, if anyone can help with scripts, I'd be really happy :)
<bryce_> recruiting one guy to hack together some scripts that do the work of 10 men might be easier than finding 10 men.  But I could be wrong.  ;-)
<nigelb> bdrung, you have thoughts of a few snippets that could help?
<bryce_> I'm willing to wait and see how the crowd-sourcing works.  Certainly humans tend to be a lot better than scripts in general, so if the manpower can be had, go for it
<persia> I think we want a mix.
<bdrung> i was thinking about a python script that does following: 1. grab the patch from the lp bug 2. detect the type debdiff vs normal patch 3. apply debdiff or add patch (directly, quilt, dpatch) 4. build 5. maybe upload to ppa
<persia> As we formalise process, we can script it, but I think lots of stuff ends up being semi-dependent on a large number of variables, and we haven't identified enough of those yet.
<nigelb> bdrung, some of the patches are badly formated which needs to be manually corrected
<nigelb> I've come across a few so far
<bdmurray> How can we as a group track these variables and issues persia?
<bryce_> nigelb, right but who does that fixup?
<nigelb> I do it manually when I see that the patch doesn't apply cleanly
<bdrung> nigelb: yes, human investigation is still required.
<bryce_> nigelb, I had a similar idea as bdrung... cases where the patch is invalid, the scripts would kick back to the reporter to fix (which I'd argue is probably all the human reviewers would do anyway, but the scripts would turn things around a lot faster)
<nigelb> bryce_, most things are small enough for us to fix ourselves :)
<persia> bdmurray: What do you think about having an "automation cases log", where we document cases that seem like they didn't require thought, and add a count.  When enough folk hit a case (e.g. >15 occurances), we use a script to find and resolve the rest?
<bryce_> nigelb, fair enough
<bdrung> bryce_: and as maximum of automation: we may push all patched packages to an ppa. so the submitter can test it directly.
<bdmurray> persia: yes, something like that would be fantastic
<nigelb> bryce_, I'm for automation but probably after a little bit of human intervention...like a human okaying for auto-testing patch
<persia> nigelb: Could you organise such a wiki page?
<bryce_> nigelb, fwiw most of the time I've needed to fix patches is because the code changed while the patch waited in the queue, so if the process can be made more immediate it would make it less necessary to fiddle patches.
<nigelb> persia, yes.  definitely
<persia> Thanks.
<bdmurray> bryce_: did you do something similar for automating X bugs?
<bryce_> bdmurray, yep
<nigelb> bryce_, do you folks triage the X bugs with patches on your own? i.e. can we exclude X and kernel?
<bdrung> maybe we can take some bits from the ack-sync script
<bryce_> nigelb, don't exclude X
<bdmurray> nigelb: kernel is excluded in the script too - they go to Jeremy Foshee
<nigelb> JFO right?
<bdmurray> yeah
<bryce_> nigelb, while I have tended to the X patches I won't be doing X.org next release
<nigelb> bryce_, but would we folks know what we're doing?  I'm lost with X
<persia> I'd like to exclude the kernel, just because it's so big and so different, but most of X is just standard libraries, services, and applications.
<bryce_> nigelb, plus I'm curious to see how this process works with something like X.org
<nigelb> http://pastebin.ubuntu.com/408255/ this is an intersting pastebin of top packages with patches that the LP guys generated
<nigelb> bryce_, the X package there was a special case that you mentioned the other day?
<nigelb> where the upstream posts patches for users to test, so can we exclude them from the scope of this review?
<bryce_> nigelb, consider it a proof-test of the process then.  ;-)  But honestly X really isn't *that* different from other things.  Most of the patches we get are against easier bits like keyboard config xml fiddles or so on
<bryce_> nigelb, right that's xserver-xorg-video-openchrome
<nigelb> bryce_, I'd be happy to help with the smaller bits, but this xserver-xorg-video-openchrome can be excluded...yes?
<bryce_> nigelb, yes
<persia> I don't think we should exclude patches from upsteam.
<persia> They just get the "patch-approved-upstream" tag extra-fast.
<persia> bdmurray: You had a question at :00 ?
<nigelb> hm
<bryce_> persia, well in this case the patches aren't "approved from upstream" but rather are patches upstream is asking bug reporters to test - e.g. they add debugging stuff
<persia> Oh, I misunderstood then.  Hrm.
<bryce_> iow, patches that aren't appropriate to be sponsored
<nigelb> yeah, I saw some heated arguments on one of those bugs
<nigelb> where the reporter wanted to know how to patch, why he should do it, and if the said patch writer was an ubuntu contributor..
<bryce_> heh, yeah.  They seem to have things in hand so I just try not to interfere.  They seem to not like if we carry patches in ubuntu on top of what they provide, so we can just leave that package alone.
<bdmurray> Is anybody using the ubuntu-patch-reviews mailing list?  The only posts getting through at the moment are mine so the list just gets notified when a new bug is added to the queue and not all bug comments are making it there.
<nigelb> I'm not subscribed since it was only a bug list.  mostly the patch tag getting added
 * persia doesn't use that list
<nigelb> ah, bdmurray ... question
<nigelb> is it possible for your script to use a different username? (so that we know its the script)
<bdmurray> probably but why?
<persia> That gets all sorts of complicated in terms of LP permissions and stuff.  I'd rather run scripts as real people, unless they are LP-internal.
<nigelb> ah.
<nigelb> forget then.
<nigelb> bdmurray, you had a question earlier?
<thekorn> but maybe it would be nice if this script could also add a comment, like "this tag was added by a script following the process on the wiki page"
<thekorn> just my 50cent ;)
<persia> I really prefer when scripts don't add such comments: it tends to send me lots of unwanted bugmail.
<bdmurray> well its already sending e-mail due to adding the tag
<nigelb> yeah, as such the patch tag addition is a bit of unwanted mail :D
<bdmurray> so what's a few characters more ;-)
<bdmurray> nigelb: I asked it earlier about the mailing list
<persia> Somehow it seems like I don't get email for tags / status changes, but mostly just for comments.
<persia> Maybe it's just me (or my memory)
<nigelb> bdmurray, I'm undecided whether to join or not
<persia> OK.  If everything has been asked, I think we're done.  Thanks everyone!
<nigelb> just a momment
<nigelb> https://wiki.ubuntu.com/ReviewersTeam/KnowledgeBase
<bryce_> I wonder if there's a special codeword or flag or something we can put in with emails from automated processing, to clue in procmail or whatever to ignore the email?
<nigelb> If anyone feels something needed to be added to the knowledge base please add or let me know what is to be added :)
<persia> bryce_: We'd have to teach LP about it first, but after that it's easy.
<bryce_> hmm
<bryce_> kind of a "minor edit" type flag
<bdmurray> a new X-Launchpd header?
<nigelb> thank you folks for the time.. :)
<bryce_> thanks
<persia> Basically have some API-settable flag that indicates automated processing, and then have mailed updates based on changes with that flag have another header.
<persia> bdmurray: Precisely.
<persia> I don't think it should be for every API change though, because of tools like groundcontrol and bughugger
<bryce_> persia, there's really two flags, one for "minor automated bug changes" like adding tags, and one for "major automated changes" like marking your bug report invalid since you didn't respond in N days
<bryce_> or maybe the latter wouldn't need a flag
<persia> I think the latter wouldn't get the flag, because you *want* to notify the user
<bryce_> persia, yeah so just a "minor automatic edit" type flag is needed.
<nigelb> persia, that was truly *awesome*. Now, we have some sort of coordination and agreement to things )
<persia> That would be my preference.
<bryce_> such could be handy for apport-collect too, when it does a separate email for each attachment
<persia> nigelb: And next time, you get to chair the meeting :p
<persia> apport would be a huge user.
<nigelb> persia, no thanks.  :D
<nigelb> jcastro, if you've got time we'll finish off the work on the mail now :)
<jcastro> yeah
<jcastro> basically I think just adding some spice in there would help.
<nigelb> I'll toss it into an etherpad, so we can all edit
<jcastro> yeah
<jcastro> hey, ubuntu-uk has an etherpad btw
<nigelb> it does? linky?
<jcastro> http://pad.ubuntu-uk.org
<nigelb> http://pad.ubuntu-uk.org/aSZVcm7UE9
<jcastro> on it
<jcastro> nigelb: link me to your blog pls
<nigelb> yes
<nigelb> jcastro, http://justanothertriager.wordpress.com/2010/03/16/1801-bugs/
<nigelb> jcastro, I think we can use bryce's anecdote too
<jcastro> nigelb: paste it in there and I'll work it in
<nigelb> okay :)
<thekorn> If upstreams comments on a bug like "I'll take care of this patch, and apply it to the next release", does this qualify as "patch-forwarded-upstream" ?
<nigelb> thekorn, generally upstream commits to svn or git immediately
<nigelb> but yes, that counts too :)
<persia> I'd call that patch-accepted-upstream even.
<nigelb> yep I second ^
<persia> I consider patch-forwarded-upstream an intermediate state, indicating we're waiting for an upstream accept/reject still.
<thekorn> right , forwarding and accepting are two different things,
<thekorn> now the question is: what do we want to indicate in the review workflow
<persia> To me the important things are:
<persia> 1) I'm on it.
<jcastro> nigelb: ok how's that?
<persia> 2) Someone qualified is looking at it
<nigelb> jcastro, its awesome :)
<persia> 3) It's good/bad
<nigelb> persia, anything to add/edit to http://pad.ubuntu-uk.org/aSZVcm7UE9 ?
<persia> I thought it was May 5th, not May 6th.
<nigelb> corrected
<thekorn> ok, I think I got it now. 1) and 2) is -forwarded-upstream, 3) AND good is -accepted-upstream, 3) AND bad is -needswork or even -rejected-upstream
<persia> I don't think we can commit to "weÂ  will get the patch applied in Ubuntu immediately" unless we first ensure we have sufficient quorum of uploaders to be around.
<jcastro> "we will try"
<jcastro> :p
<persia> thekorn: Something like that.  nigelb and I went through about 20 use cases to establish the tag set, but I forget all the details.
<persia> "try" works :)
<persia> "We'd like your help to get these submissions reviewed and if necessary sent upstream so that they don't bitrot and to encourage people to continue helping us improve open source software.Â " Feels run-on.
<nigelb> thekorn, I'll add use cases over this week
<persia> How about "We'd like your help to get these submissions reviewed and if necessary sent upstream so that they don't bitrot.  We believe this helps to encourage people to continue helping us improve open source software.Â "
<nigelb> thekorn, what parts are most confusing?
<nigelb> thekorn, I'll add more details to those.
<persia> Last bits edited inline.
<thekorn> nigelb, for me there are so many bold bits in the workflow section
<thekorn> nigelb, but otherwise it is looking great
<thekorn> and I think concrete examples will help alot
<nigelb> thekorn, all tags are bolded to mark them as tags
<nigelb> looks like I'll need to make some changes to the wiki first
<thekorn> for me this sentence is also a bit confusing """When a review of the patch is done, unsubscribe ubuntu-reviewers from the bug. The tags will help us catch the bug for clean up later."""
<thekorn> what exactly does """review """ mean here? does review envolve upstream action, or is it just the review process described in the first two items
<thekorn> s/envolve/involve
<nigelb> ok, its like this.  a bug is in review queue
<persia> The entirety of the process.  "This patch has been handled".
<persia> Rejected upstream/debian/ubuntu or accepted upstream, etc.
<nigelb> yeah.. the simple explanation :)
<nigelb> persia, I think reviewers can be unsubscribed when patch-needswork.  can be resubscribed once work done?
<nigelb> also... um, how to do negative searches again?
<bryce_> nigelb, prepend a -
<bryce_> so like "foo bar -baz"
<bryce_> also make sure to set the tag combinator thingee to 'All' rather than 'Any'
<persia> nigelb: Works for me.
<nigelb> brian also suggested the same for forwarded upstream
<persia> I don't think we want to unsubscribe for forwarded-upstream.  Maybe accepted-upstream or accepted-debian.
<persia> TO me, forwarded-upstream implies we're still responsible for the patch.
<nigelb> then I need to do the negation
<nigelb> https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers&field.tag=patch&field.tag=-patch-forwarded-upstream&field.tags_combinator=ALL
<nigelb> This is supposed to work ^
<persia> Launchpad doesn't understand the form data submitted in this request.
<nigelb> yeah
<nigelb> ah, figured it out
<nigelb> so joining is apply and prove work you've done or apply and get an ack from current member
<persia> or come hang out here and do stuff until someone gets annoyed and bugs an admin to add you.
<nigelb> yes, that is indeed needed :D
<nigelb> tweaked a bit https://wiki.ubuntu.com/ReviewersTeam
<vish> jcastro: damn you are fast! , i just about to warn you about the typo and got your second mail :)
<jcastro> it happens every time. :D
<vish> hehe..
#ubuntu-reviews 2010-04-07
<nigelb> persia, brian put up the script in bzr... I think a few things can be changed... take a look? http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/annotate/head%3A/launchpadlib-scripts/patch-subscriber.py
<nigelb> maco, can I convince you to sign up for an hour or 2? https://wiki.ubuntu.com/PatchDay ?
<maco> when?
<nigelb> May, 4, 5,6 total of 50 hours... so take your pick :)
<nhandler> nigelb: I can't do 16:30
<nigelb> nhandler, someone will..  Just pick a few slots which you're comfortable :)
<nigelb> if no one will, I'll take a day off from work and be here then :)
<nhandler> I'll start with one. I'll claim more when we get closer
<nigelb> nhandler, great :)
 * nhandler wishes he could take a day off of school for that
 * nigelb pokes maco again
<maco> nigelb: yes, beginning of may i should have a slightly saner (ie, done with senior design) workload
<nigelb> maco, oh yaay! :)
<nigelb> so please sign up as many
<nigelb> I'm hoping to sign up for a few more... just waiting to know when they are needed
<dholbach> good morning
<Daviey> Hey Ciemon
<Ciemon> Morning Daviey
<Ciemon> Been learning about patching and building, so I'll have some work for this team shortly
<Ciemon> :)
<Daviey> Ciemon: you've got over the tough bit of the learning curve :)
<bdrung> wow. you can find the patch day in the Linux press: http://www.pro-linux.de/NB3/news/1/15520/ubuntu-patch-day-am-5-mai.html
<dholbach> I think we need to beef up the docs with examples before we re-announce
<dholbach> or re-blog, etc
<nigelb> Ciemon, great to see you here :)
<Ciemon> nigelb: thanks.. it's just a question of time before I get deeper into all this :)
<nigelb> Ciemon, :)
#ubuntu-reviews 2010-04-08
<nigelb> hyperair, hey :)
<nigelb> nhandler, can you sign up on the wiki for the hours that you can ... helps me when i try to convince another person :)
<nhandler> I'll take a few more.
<nigelb> perfect.
 * nigelb moves to next target :D
<nhandler> I might need to reschedule a slot, but I'll leave it the way it is for now
<nigelb> ah, thanks, so thats less slots to fill in
<nigelb> I think I'll make it standard format to put IRC nick as display :)
<nigelb> maco, um... if your schedule permits, can you sign up for a few hours on the patch wiki?  If its too undecided, later is fine too :)
<nigelb> but it would really help me when I'm trying to recruit when a few people have already signed up
<maco> nigelb: saturday may 5th?
<maco> nigelb: check your calendar
<dholbach> good morning
<dholbach> wow
<dholbach> the patch day is getting more and more publicity
<dholbach> it's on major german news sites
<dholbach> we better ramp up docs and stuff a bit
<nigelb> dholbach, you wanted a rewrite of the review guide (was reading logs earlier today) ?
<nigelb> maco, oops.  thanks, I'll correct it now :)
<dholbach> nigelb: not rewrite it, but add examples, etc
<nigelb> dholbach, ah, I'll try to work it in today :)
<nigelb> dholbach, I need some help with rectruiting too
<dholbach> nigelb: I suggest that before we start recruiting, we have a look at the docs together
<dholbach> like all of us
<nigelb> dholbach, I already started.  I'll put the docs into an etherpad :)
<dholbach> I would have preferred them to be in tiptop shape before we announce, so that people who look at it directly get it and get all their questions answered
<dholbach> but hey, we can always send another announce :)
<nigelb> I did the announce hoping I'd get to work on the wiki in a few hours
<nigelb> but yday was a bad day at work + no power here
<nigelb> and yes we can do another announce, since I missed the last classroom session I planned due to now power :(
<persia> Docs first.  Another announce later.
<nigelb> yup
<nigelb> http://pad.ubuntu-uk.org/qIEl4uiI8v
<persia> Saturday, May 5th needs some help though :)
<nigelb> here's the etherpad.. lets dive in
<nigelb> I'm getting to the saturday thing
<nigelb> I lost power before I saw her reply
<persia> heh.  You're good at that, but you can't catch me this evening.
<nigelb> persia, busy evening?
<persia> I have a few things I want to get done for tomorrow.
<nigelb> sure, daniel's around :)
<dholbach> errr :)
<dholbach> I'll try, need to get a few other things out of the way first
<nigelb> I'll work on it, you folks can review when you get the time :)
<dholbach> super :)
<nigelb> persia, i'm so sorry I wasn't around for the class last night
<persia> Happens sometimes.  No worries.  Just reschedule it.
<nigelb> yea, I have reschedule around some uncertain power situations.
<nigelb> btw, did you get time to take a look at the script?
<nigelb> I have so many things to change in that...
<nigelb> ok, I'm still unsure.  do we edit the script to make sure it recognizes patch-* tag (now that I can see the script code) or we dont do it?
<persia> I thought the decision was that we didn't bother, and changed the process, since LP was cooler than previously thought.
<nigelb> what irks me is since I can see the code, why not change it
<persia> Extra work for no extra value?
<nigelb> I need to get a few changes in anyway
<nigelb> like that pacakge bryce said we can ignore
<persia> Either way.
<nigelb> so, the thing is... I want to know comments on this line
<nigelb> As you complete each step of the process, you will mark your process by adding an appropriate 'patch-*' tag and removing the old one, however the 'patch' tag is NEVER removed from the bug.  Make sure to ALWAYS include a comment when you change the tag just like you would if you changed the bug status, so it's clear to later reviewers what happened.
<nigelb> does the last bit stay or go?
<persia> I like it, but I tend to be over-verbose when concision would be more effective.
<nigelb> um.. the last bit of first line :D
<nigelb> motu-sru is kinda gone right?
<nigelb> also is ubuntu-ma-sponsors?
<nigelb> so, can I have the script ignore redudant teams?
<persia> nigelb: Rather than ignoring outdated teams, we especally want to know about those so we can move stuff to the right teams (and then ignore them).
<persia> Workflow there is probably: subscribe the right team, remove the patch tag.
<nigelb> persia, ouch
<persia> (because with the right team subscribed, the script would then ignore the bug)
 * nigelb doesn't know enough of LP API to get this right :)
<persia> ouch?
<nigelb> but we could probably have another script based on this one to subscribe new teams for the old bugs?
<persia> I think dholbach has a script that does that: maybe we should extend that, and have the reviewers team script continue to ignore the old teams.
<dholbach> http://people.canonical.com/~dholbach/resubscribe maybe?
<persia> That'd be it :)
<nigelb> well, if that works, then I can remove the old teams?
<nigelb> dholbach, or you can have that run with this script too :)
<persia> I'd check with the team owners.  I'd be pleased if ubuntu-universe-sponsors was automatically unsubscribed when ubuntu-sponsors was subscribed.
<persia> I can't say for other teams.
<nigelb> I thought dholbach 's script did that?
<dholbach> if ubuntu-{universe,main}-sponsors are subscribed to an open bug, they'll be unsubscribed and ubuntu-sponsors will be subscribed instead
<persia> Right, but the trick is to check with other potentially obsolete team owners before doing the same thing to those teams.
<dholbach> oh sure, it's just for that use-case
<nigelb> persia, ah.  that way, so talk to other obsolete team owners and get their teams to work the same way, gotcha :)
<persia> But I think it's sharable to e.g. motu-release or motu-sru, assuming someone does the porting and legwork to communicate with the team owners.
<persia> nigelb: You probably want to get the other team owners to run the script themselves every once in the while.
<persia> dholbach: IN case I haven't said so recently: thanks for including u-u-s in your script :)
<nigelb> persia, I'll add that to my things to do :D
<dholbach> persia: it was since the beginning - it just wasn't executed because of a bug :)
<persia> dholbach: Still, I appreciate you running it so I needn't :)
<nigelb> I've pushed my changes, so take a look
<dholbach> no worries :-)
<nigelb> http://bazaar.launchpad.net/~nigelbabu/ubuntu-qa-tools/patch-review-script/annotate/head%3A/launchpadlib-scripts/patch-subscriber.py
<persia> nigelb: You might also want to add linux-ti-omap to the subscribe-JFo set.
<nigelb> aha, getting done.. minute
 * persia hopes we have a good plan for kernel reduction for one of the next cycles: too many trees is too confusing
 * nigelb refuses to go into kernel, even though tempting
<persia> No, leave that to the kernel folks.  We just have *lots* of different kernel trees.  Last UDS we managed to kill one (linux-lpia), but we got more.
<nigelb> the temptation to fix broken stuff is highly tempting
<nigelb> wonder how core-devs manage to control the impulse :D
<nigelb> ok, so added and new revision
<nigelb> http://bazaar.launchpad.net/~nigelbabu/ubuntu-qa-tools/patch-review-script/annotate/head%3A/launchpadlib-scripts/patch-subscriber.py
<nigelb> dholbach, ok, I need some idea of what kind of examples you're looking for...
<nigelb> like add a test scenario to each case?
<dholbach> nigelb: like bug X with a patch that needed some work, like bug Y with a patch that needed to go to debian, was forwarded there, etc.
<dholbach> if you've never done it it will be hard to figure out for you what you need to do
<nigelb> dholbach, um, those statuses are sort of dynamic
<nigelb> so by the time someone actually looks into it patch-needswork will be patch-forwarded-upstream or patch-accepted-upstream
<dholbach> yes
<dholbach> I thought that a bug which tells a story of "here's what happened" might be helpful in teaching that
<nigelb> ah, I'll look for those
<dholbach> I'll have a look over it tomorrow
<nigelb> so, I'll add specific examples below the current ones
<nigelb> i.e. the current rule-stlyle ;)
<nigelb> dholbach, I'll nag persia to look at it today :D
<dholbach> awesome
 * dholbach has to head out and tend to a few other things
<dholbach> so have a great rest of your day
<dholbach> and see you soon again! :)
<nigelb> later dholbach :)
<dholbach> rock on
<nigelb> persia, how long more will you be up?
<persia> longer than you.
<nigelb> can talk to brian about my edits?  I'm dead on sleep already.
<nigelb> james_w, can you sign up for a few hours of review leading? https://wiki.ubuntu.com/PatchDay
<james_w> not right now
<nigelb> well 1 hour is fine too :)
<james_w> I'll look closer to the time
<nigelb> sure, thank you :)
<persia> nigelb: Sure.
<nigelb> persia, thank you :)
 * nigelb is off.  rest of wiki edits in the morning
#ubuntu-reviews 2010-04-09
<nigelb> bdmurray, I did some edits to the patch subscription script and pushed to my own branch.  can take a look?
<nigelb> http://bazaar.launchpad.net/~nigelbabu/ubuntu-qa-tools/patch-review-script/annotate/head%3A/launchpadlib-scripts/patch-subscriber.py
<bdmurray> nigelb: seems fine but I don't see any reason to reduce the list of workflow_teams as they might be subscribed to old bug reports and it doesn't hurt does it?
<nigelb> bdmurray, I wanted to talk to the old workflow teams and help extend dholbach's resubscribe script for those teams too
<nigelb> like subscribe ubuntu-sru where motu-sru is subscribed etc, persia_ encouraged me to talk to the team owners about that
<nigelb> and i've added one more package to jfo's list and one more package to be ignored :)
<bdmurray> okay but if an old team is subscribed to a bug with a patch and then the reviewers team gets subscribed to it what will the reviewers team do?
<bdmurray> nigelb: yes I saw those other changes too thanks!
<nigelb> No, what I meant is, daniel's script subscribes sponsors if u-u-s or u-m-s is subscribed to a bug
<nigelb> so if we can give the old teams an extend of that script to be run occasionally, they can take care of it
<nigelb> we might not have anything to review on a motu-sru bug, we'll just delay it
<bdmurray> right and if a bug with u-u-s subscribed shows up in our search results with your branch the reviewers team will be subscribed to it
<bdmurray> because your branch removes u-u-s from workflow teams
<nigelb> aah. ok.  common sense.  I should have left them there :D
<bdmurray> so if you fix that I'll be happy to merge it
<nigelb> ubuntu-ma-sponsors should be ubuntu-main-sponsors?
<bdmurray> why yes!
<nigelb> ok, so here goes
<nigelb> http://bazaar.launchpad.net/~nigelbabu/ubuntu-qa-tools/patch-review-script/annotate/head%3A/launchpadlib-scripts/patch-subscriber.py
<nigelb> shall I request a merge?
<dholbach> good morning
<nigelb> I'm slowly working on the https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved to incorporate examples.  If someone would like to give suggestions, correction, please let me know
<nigelb> hyperair, poke
<nigelb> bdmurray, you want me to request a sync for the script?
<bdmurray> nigelb: a merge proposal would help thanks
<nigelb> bdmurray, will do.  I wasn't sure how to go about it :)
<nigelb> persia, https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved
<nigelb> any more suggestions?
<nigelb> bdrung, got a minute?
<bdrung> nigelb: at least three seconds ;)
<bdrung> *at most
<nigelb> can sign up for a few hours at  https://wiki.ubuntu.com/PatchDay?
<nigelb> bdrung, ^
<bdrung> nigelb: will have a look at it later
<nigelb> bdrung, thank you :) even 1 hour is much appreciated :)
 * nigelb notes that there is still 40 slots open
<Ciemon> nigelb: I just had a look at PatchDay, I wonder if that's something for someone with minimal experience.. like me?
<nigelb> Ciemon, yep it is.  you're welcome to contribute
<nigelb> you need to be able to test patches and if working, encourage patch author to forward to upstream bug tracker
<nigelb> Ciemon, the reviewers team doesn't have too much requirements, see https://wiki.ubuntu.com/ReviewersTeam
<Ciemon> OK, I'll have had more practice my then; and I see the "bugs with patches added" link.
<Ciemon> yeah, I've read ReviewersTeam before.. interesting that you've said that the patch author shold forward upstream. Is that "policy"?
<Ciemon> It's something I want to make happen with the batch I'm working through at the moment.
<nigelb> Ciemon, the idea is the author should be able to respond to feedback
<nigelb> Ciemon, but if patch author shows no response, we'll have to forward
 * Ciemon ponders
<nigelb> Ciemon, upstream might ask for changes or give comments, its easier if the patch author does it him/her-self
<Ciemon> ok
<nigelb> I'm off.  ask any questions here, I'll reply in scroll back if noone else does :)
<Ciemon> Thanks.. no questions for now, just practise.
#ubuntu-reviews 2010-04-10
<vish> persia: hi.. got a min for a pm?
<vish> per_sia: unping ;)
<persia> vish: unping works better when you highlight me :)
 * persia doesn't like contentless pings anyway, and encourages blind /queries
<vish> ;) hehe actually i was moving away for a bit ..
 * vish queries
<nigelb> persia, if you're around.. any thoughts on what I asked you in the morning?
<nigelb> jcastro, ping
<vish> nigelb: hey , WIP > http://dl.dropbox.com/u/1325768/Reviewers.png  what do you think of the idea?
<vish> having a bandaid alone seemed odd ,
<nigelb> not bad, but the band-aid seems too small.  any way to enlarge?
<vish> nigelb: its a WIP , just throwing in the idea
<vish> will try with a bigger bandaid too
<nigelb> I like the concept :)
#ubuntu-reviews 2010-04-11
 * nigelb pokes hyp
<nigelb> bah, he isn't hee
<nigelb> here
