[01:51] <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
[02:09] <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 ...
[02:09] <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
[02:47] <nigelb> mpontillo, generally things that go into -updates and -backports need to go into a development version first
[02:47] <nigelb> now, the best thing would be to forward the patches upstream
[02:48] <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
[02:50] <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
[02:51] <nigelb> I know... I wrote it :D
[02:52] <nigelb> so, now you just leave the patch tag in there
[07:47] <nigelb> persia, how much backlogged into mails are you?
[07:47] <persia> 9 days
[07:47] <nigelb> ouch, ok.  I'll not mail
[07:47] <nigelb> well, updates include some pretty graphs (see topic)
[07:48] <nigelb> patch day moved up to wednesday may 5th
[07:48] <nigelb> and I still need to convince brian to make the script understand 'patch*' tags
[09:28] <nigelb> persia, did you see ^
[09:29] <persia> I did.
[09:30] <nigelb> I could use some help with the convincing
[09:30] <persia> Have you tried putting it on the QA team meeting agenda?
[09:30] <nigelb> em, no
[09:31] <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.
[09:31] <persia> If not, perhaps someone else would be willing to present, based on some wiki page clearly stating the position.
[09:34] <nigelb> I asked bryce a few days back
[09:34] <nigelb> he said he'd talk to brian... but really... it would be nice to have the 3 or 4 of us
[09:35] <nigelb> I wish I could be there at uds :(
[09:35] <nigelb> just needs the few active people to come together and sit down and talk
[09:43] <nigelbabu> did I miss something?
[09:45] <nigelbabu> persia, qa team meeting is okay time for me... it generally isn't around 3 hours right?
[10:57] <persia> nigelb: It usually lasts about an hour.  If it's an OK time for you, then please raise it.
[10:57] <persia> nigelb: If it can't be sorted pre-UDS, I'm definitely up for trying to catch the folks involved there.
[10:58] <nigelb> persia, we can try to talk to bdmurrary once before that
[10:58] <persia> At least once :)
[10:58] <nigelb> well, if I can get you, bryce, bdmurray, and jcastro together for 20 minutes it would be extremely productive
[10:59] <nigelb> (these would be the people who are interested in getting the review queue going)
[10:59] <nigelb> also, MOTU should ideally promote review queue as stepping stone to packaging training
[11:00] <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.
[11:00] <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.
[11:00] <nigelb> by getting the review queue down to zero?
[11:01] <nigelb> yeah... well.. as many as humanely possible
[11:01] <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.
[11:01] <nigelb> well.... I for one think we should be focusing on the subscribed bugs
[11:01] <nigelb> that is a definite way to get things moving
[11:02] <nigelb> but just one person working on things isn't going to create magic overnight :(
[11:02] <persia> It's not just one person though, is it?
[11:02] <nigelb> well <10
[11:02] <persia> That's a number I'll believe.
[11:03] <persia> MOTU started with about 3 folks: it's just a matter of docs and publicity.
[11:03] <nigelb> Oh!
[11:03] <nigelb> In that case, I guess we still have hope
[11:04] <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.
[11:05] <nigelb> did you sign up for being a contact on patch day?
[11:05] <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.
[11:05] <nigelb> yes, i.e., as established reviewers
[11:05] <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.
[11:05] <persia> Right.
[11:06]  * vish always wondered what timezone persia was in :)
[11:06] <nigelb> vish, jp
[11:06] <vish> ah..
[11:06] <nigelb> that's why he's always around when we're around
[11:07] <vish> hehe , i was thinking he was at the other end , alaska or somewhere ;)
[11:07] <nigelb> persia, I wanted an established reviewers team member to start off patch day
[11:08] <persia> I'm only 3:30 offset from there most of the time.
[11:08] <persia> nigelb: Your local time at day-start is 15:30, right?
[11:08] <persia> Is that bad for you?
[11:09] <nigelb> yep.. I'll be at work
[11:10] <persia> Maybe nhandler or bdmurray can start.  If not, I will.
[11:10] <nigelb> I'll try to catch bdmurray
[11:10] <nigelb> will you be up around the time he's waking up?
[11:10] <nigelb> today i.e.
[11:10] <persia> Maybe.  The other side of the day works better for that combination, but is bad for you :)
[11:11] <nigelb> set a time...
[11:11] <nigelb> I'll go to bed early if need me
[11:11] <nigelb> be
[11:12] <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.
[11:13] <nigelb> UTC?
[11:13] <persia> Yeah.
[11:13] <nigelb> so 23:00 UTC sounds fine?
[11:14]  * nigelb gulps ... 3:30 am
[11:14] <nigelb> still.... it would be very productive I guess
[11:14] <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.
[11:14] <persia> Tuesday or Thursdays are often good candidates.
[11:15] <nigelb> Tuesday is meeting horror day
[11:15] <nigelb> everyone is bound to be busy
[11:15] <persia> Well, there's no QA meeting, and that's what keeps me around until 17:00 or 18:00 most weeks.
[11:16] <nigelb> so tomorrow at 23:00 seems better?
[11:16] <persia> Why 23:00?
[11:17] <nigelb> 17:00?
[11:17] <persia> tomorrow at 16:00 ought be fine.
[11:17] <persia> Or 17:00.
[11:17] <persia> But I don't know that I'll be up that late tonight.
[11:17] <nigelb> that time is fine with me too
[11:17] <nigelb> so tomorrow it is
[11:17] <persia> Thought so :)
[11:20] <nigelb> information that needs to be added to reviewers team wiki?
[11:20] <nigelb> https://wiki.ubuntu.com/ReviewersTeam/KnowledgeBase
[11:20] <nigelb> I can't think of any
[11:26] <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.
[11:26] <persia> Personally, I'd rather see it organised in terms of activities, but that will come with time and practice doing stuff.
[11:26] <nigelb> I was thinking of having a how to generate patches from svn and git but that seemed too much
[11:27] <persia> For us, yeah.
[11:27] <persia> I think it's worth having that documentation in general though.
[11:27] <persia> But I think it's more valuable for MOTU docs.
[11:27] <nigelb> it would be appropriate for us to have it as we're the people upstreaming patches
[11:28] <persia> Good point.
[11:28] <persia> Although I think that the docs would be slightly different for the different audiences.
[11:28] <nigelb> yes. definitely.
[11:29] <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.
[11:30] <nigelb> exactly
[11:31] <nigelb> which means the wording might get a lile tricky
[11:32] <persia> Or maybe it involves three documents.  One is "How to use the tool", and two are example workflows using the tools.
[11:32] <persia> Then the dev pages *and* the reviewers pages can reference it.
[11:32] <nigelb> or one "how to tool" and we'll link it up differently in 2 pages
[11:33] <persia> with inclusion.  That works.
[11:34] <nigelb> yep.  inclusion is what I thought too
[12:10] <nhandler> persia: I can only do a 15:30 on a Sunday sadly
[12:12] <persia> nhandler: No worries.
[13:03] <nigelb> I'm holding off on creating page on git and svn how-to
[13:04] <nigelb> each upstream might have different policies and I need to go through the bigger ones at least
[13:52] <nhandler> nigelb: Instead, why not try and link to (or ask upstream to create) those guides ?
[13:52] <nhandler> They will be more accurate and better maintained, and more people can benefit from them
[13:52] <nigelb> when I submitted code upstream, generally, i had to look for generic guides and teak them
[13:55] <nigelb> like look for a generic guide to submitting patches in git and then looking at upstream style guides
[22:19] <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
[22:20] <nhandler> nigelb: Also, what is Debian/QADelta ? Is it meant to list the reasons for diverging from Debian?