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