| 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 | 01:51 |
|---|---|---|
| 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:09 |
| 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:47 |
| 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:48 |
| 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:50 |
| nigelb | I know... I wrote it :D | 02:51 |
| nigelb | so, now you just leave the patch tag in there | 02:52 |
| 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:47 |
| 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 | 07:48 |
| nigelb | persia, did you see ^ | 09:28 |
| persia | I did. | 09:29 |
| 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:30 |
| 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:31 |
| 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:34 |
| 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:35 |
| nigelbabu | did I miss something? | 09:43 |
| nigelbabu | persia, qa team meeting is okay time for me... it generally isn't around 3 hours right? | 09:45 |
| === \vish is now known as vish | ||
| 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:57 |
| 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:58 |
| 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 | 10:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| * 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:06 |
| 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:07 |
| 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:08 |
| nigelb | yep.. I'll be at work | 11:09 |
| 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:10 |
| nigelb | set a time... | 11:11 |
| nigelb | I'll go to bed early if need me | 11:11 |
| nigelb | be | 11:11 |
| 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:12 |
| nigelb | UTC? | 11:13 |
| persia | Yeah. | 11:13 |
| nigelb | so 23:00 UTC sounds fine? | 11:13 |
| * 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:14 |
| 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:15 |
| nigelb | so tomorrow at 23:00 seems better? | 11:16 |
| persia | Why 23:00? | 11:16 |
| 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:17 |
| 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:20 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| nigelb | exactly | 11:30 |
| nigelb | which means the wording might get a lile tricky | 11:31 |
| 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:32 |
| persia | with inclusion. That works. | 11:33 |
| === etali1 is now known as etali | ||
| nigelb | yep. inclusion is what I thought too | 11:34 |
| nhandler | persia: I can only do a 15:30 on a Sunday sadly | 12:10 |
| persia | nhandler: No worries. | 12:12 |
| nigelb | I'm holding off on creating page on git and svn how-to | 13:03 |
| nigelb | each upstream might have different policies and I need to go through the bigger ones at least | 13:04 |
| 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:52 |
| nigelb | like look for a generic guide to submitting patches in git and then looking at upstream style guides | 13:55 |
| === yofel_ is now known as yofel | ||
| 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:19 |
| nhandler | nigelb: Also, what is Debian/QADelta ? Is it meant to list the reasons for diverging from Debian? | 22:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!