| nigelb | nhandler, its meant to show list of QA packages where we have a delta from debian | 00:40 |
|---|---|---|
| nhandler | What do you mean by QA packages nigelb ? | 00:41 |
| nigelb | err.. packages maintained by debian QA team... the orphaned packages | 00:41 |
| 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? | 00:41 |
| nigelb | <ScottK> It's a good idea. I've been doing that as I run across such packages. | 00:41 |
| 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? | 00:41 |
| nigelb | nhandler, ^ | 00:42 |
| nhandler | nigelb: Ah ,ok | 00:42 |
| nigelb | nhandler, some of those changes need not be sent back.. hence I put it onto a wiki | 00:43 |
| nigelb | nhandler, will you be around at 1630 UTC ? | 01:21 |
| nigelb | persia, well, in case you're swamped by mail, brian and jcastro are +1 for 1630 :) | 01:21 |
| nhandler | Darn, missed him. | 03:01 |
| persia | He'll be back :) | 03:10 |
| dholbach | good morning | 08:17 |
| nigelb | persia, um.. can you chair the meeting? | 14:31 |
| persia | meeting? | 14:31 |
| persia | I thought it was a semi-informal chat | 14:31 |
| nigelb | yeah.. someone has to semiformally lead it :) | 14:32 |
| persia | Oh, I can do that. Do we have some list of decisions we need made? | 14:32 |
| nigelb | I'll make an etherpad | 14:33 |
| persia | Sounds like a plan :) | 14:33 |
| nigelbabu | <nigelb> http://etherpad.com/aryJjRUeik | 14:49 |
| nigelbabu | <nigelb> anyone wants to contribute to things to be discussed, feel free to add ^ | 14:49 |
| dholbach | persia: do you know who else was invited to the meeting? is it going to be in 1h36m? | 15:54 |
| 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. | 15:56 |
| dholbach | ok | 15:56 |
| maco | haha | 15:57 |
| dholbach | I'll be there too, but I think I'll go back home before the meeting starts | 15:57 |
| persia | OK. | 15:59 |
| persia | Apparently, I'm chairing, so I'm happy to wait :) | 15:59 |
| dholbach | see you later :) | 16:13 |
| === yofel_ is now known as yofel | ||
| nigelb | persia, anything more to add to http://etherpad.com/aryJjRUeik ? | 17:13 |
| persia | No. | 17:14 |
| persia | I have opinions about #2 and #3, but I'm really only around to talk about #1, which seems easy enough. | 17:14 |
| persia | Did you ever write up the behaviour you *wanted* the script to have? | 17:14 |
| nigelb | well, I was hoping we'd have a consensus on #2 and #3 | 17:15 |
| persia | We may :) | 17:15 |
| nigelb | the script would consider bugs with patch* tags processed would be what I *wanted* | 17:15 |
| nigelb | i.e. not adding patch again if another patch-* tag is present | 17:15 |
| persia | That ought be simple enough. HAve you found the source? | 17:16 |
| nigelb | um, no brian has not yet shared it | 17:16 |
| persia | Aha! | 17:16 |
| nigelb | I had asked if he could put it in bzr and sync to the box that runs it once a day | 17:16 |
| nigelb | that way we could request merges, etc | 17:16 |
| nigelb | (to the script that is), but I guess he's just a bit busy with release nearing, etc | 17:17 |
| persia | Probably. | 17:17 |
| dholbach | I forgot again... who apart from bdmurray were we waiting on? :) | 17:20 |
| persia | nigelb: ? | 17:20 |
| nigelb | jcastro | 17:20 |
| dholbach | ah ok | 17:20 |
| nigelb | and bryceh if he's around | 17:21 |
| dholbach | hi bdmurray | 17:22 |
| bdmurray | hello | 17:22 |
| nigelb | persia, I guess we can get started now :) | 17:24 |
| 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. | 17:25 |
| hyperair | tsk nigelb =p | 17:25 |
| persia | Agenda is at http://etherpad.com/aryJjRUeik | 17:25 |
| persia | First topic is to look for changes to the patch subscription script. | 17:26 |
| persia | nigelb: I think you wanted to have it not re-add "patch" when "patch-foo" was present? | 17:26 |
| nigelb | yup | 17:26 |
| persia | bdmurray: Is there a branch somewhere that could be used to make that adjustment, or do you have concerns about doing that? | 17:26 |
| 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 | 17:27 |
| 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? | 17:27 |
| bdmurray | I mean I don't see a need to remove the patch tag just add patch-foo in addition to patch | 17:27 |
| dholbach | I'm still not sure I understand what the script should be doing. :) | 17:28 |
| persia | dholbach: Subscribing ubuntu-reviewers to a sensible subset of the patch bugs so we have a manageable target. | 17:28 |
| nigelb | dholbach, the script subscribes ubuntu-reviewers to all bugs with patches | 17:28 |
| nigelb | well, after a certain date | 17:28 |
| persia | dholbach: Also, trying to merge all the different ways that patches are identified into one format. | 17:29 |
| bdmurray | right so any new bugs with patches | 17:29 |
| nigelb | my only worry is that LP really doesn't allow negation while searching | 17:29 |
| persia | Which makes it hard to search for bugs that have patches but have not yet been reviewed? | 17:30 |
| nigelb | like searching bugs with patch tag but without patch-forwarded-upstream | 17:30 |
| bdmurray | I think negation is possible if not with the web interface with the api | 17:30 |
| persia | Definitely with the API, and definitely not with the web interface, but most of us use the web interface. | 17:30 |
| dholbach | I use http://people.canonical.com/~dholbach/resubscribe for a different purpose right now - maybe that can be used? | 17:30 |
| hyperair | launchpad should sprout support for google-like syntax for searching | 17:30 |
| bdmurray | its says right in the web interface that it works | 17:31 |
| bdmurray | # Find bugs that don't have the test tag: search for -test | 17:31 |
| persia | Ah, cool. I never got that to work, but I haven't tried in a while. | 17:31 |
| persia | So that makes this moot, I think. nigelb? | 17:31 |
| nigelb | yes, we can move on :) | 17:32 |
| nigelb | I'll edit the review guide appropriately | 17:32 |
| jcastro | wait! | 17:32 |
| persia | Great. Item 2: Patch Day and thoughts on current implementation. | 17:32 |
| persia | OK. Back to item 1. | 17:32 |
| persia | jcastro: ? | 17:32 |
| jcastro | we already know the patches because lp figures that out for the +patches view | 17:32 |
| jcastro | so maybe we can ask the lp team to just sub the right team when a patch is attached? | 17:32 |
| persia | jcastro: No. That fails in all sorts of ways. | 17:32 |
| jcastro | ok, explain that to me after then, I don't want to hold up the agenda | 17:33 |
| 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. | 17:33 |
| nigelb | Its a nice feature for teams like X | 17:33 |
| bdmurray | jcastro: there are various exceptions for if the sponsors team is subscribed etc... | 17:33 |
| nigelb | but not for others | 17:33 |
| jcastro | ok | 17:33 |
| persia | jcastro: Just to confirm your thoughts, that does work about 90% of the time, it's just the rest that are tricky. | 17:33 |
| nigelb | release team subscribed, merges, etc | 17:34 |
| persia | Anyway, item 2: Patch Day and thoughts on current implementation. | 17:34 |
| nigelb | this is the current way we wish to implement https://wiki.ubuntu.com/PatchDay | 17:34 |
| persia | I presume that's described at https://wiki.ubuntu.com/PatchDay | 17:34 |
| nigelb | persia, would you like to summarize here? since it was originally your idea :) | 17:35 |
| persia | nigelb: So, what's to discuss here? | 17:35 |
| 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. | 17:36 |
| bryce_ | personally I think it's not the best way to achieve this | 17:36 |
| bryce_ | I understand the objective is to make the bar low so many people can participate | 17:36 |
| 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. | 17:36 |
| bryce_ | however in practice I think you find one guy that's really motivated can do more than 10 random joiners | 17:37 |
| bryce_ | so I'd suggest instead of holding a ** Day, to focus on finding and recruiting those specific super contributors | 17:38 |
| persia | That makes more sense to me than having special days. | 17:38 |
| bryce_ | anyway, just my opinion ;-) | 17:38 |
| * persia has the sense that special days discourage people from contributing the rest of the time | 17:38 | |
| dholbach | I'm not sure that's true - it can be great to get together as a team, set a goal and achieve it | 17:39 |
| dholbach | especially if there's no team yet | 17:39 |
| nigelb | it makes things move and help us look back to what we've achieved | 17:39 |
| bryce_ | dholbach, that has not been my experience with X | 17:39 |
| persia | Nor mine with REVU | 17:39 |
| nigelb | But I did see that with hugdays :) | 17:40 |
| bryce_ | possibly we're doing it wrong ;-) | 17:40 |
| dholbach | well, I'm not saying we shouldn't have tuition sessions :) | 17:40 |
| dholbach | I think we should have them too | 17:40 |
| 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 | 17:40 |
| nigelb | dholbach, I'll get to work on that. :) | 17:41 |
| dholbach | also having a XYZ Day helps with people who want to get involved but don't know who they can talk to | 17:41 |
| persia | I guess. I'd rather have staffed channels, but that takes more commitment from everyone involved. | 17:42 |
| dholbach | and we can always try a few things out and see how they work | 17:42 |
| nigelb | dholbach, Hence, the idea of rotating staffing | 17:42 |
| dholbach | it's not like we need to keep tuition sessions or patch days going if we see they don't work | 17:42 |
| 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. | 17:42 |
| hyperair | i think having XYZ days helps in having the channels staffed sufficiently. | 17:43 |
| nigelb | persia, that needs to be edited. It was the initial edit of the bug day wiki page :) | 17:43 |
| dholbach | shall we move on or do we want to discuss date, time and organisation already? | 17:43 |
| persia | Does may 5th work spetacularly badly for anyone? | 17:44 |
| nigelb | Date is May 5th, jcastro and I are working on an announcement to -devel | 17:44 |
| dholbach | ok | 17:44 |
| persia | I strongly believe that time should be "all day, in your timezone", which makes it 50 hours. | 17:44 |
| jcastro | I agree | 17:44 |
| hyperair | i agree as well | 17:45 |
| 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. | 17:45 |
| persia | WHich I believe resulted in the big table. | 17:45 |
| persia | Does that work for an initial day for everyone? | 17:45 |
| dholbach | do we have enough people who know about the process and stuff? | 17:46 |
| hyperair | big table? | 17:46 |
| persia | hyperair: Under "Contacts" in https://wiki.ubuntu.com/PatchDay | 17:46 |
| hyperair | hmm i see | 17:46 |
| 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. | 17:47 |
| dholbach | ok | 17:47 |
| nigelb | We're also hoping to recruit after the announcement | 17:47 |
| * dholbach marks day in calendar | 17:47 | |
| dholbach | that should also leave us enough time for reviewing docs | 17:48 |
| nigelb | also, please review the wiki for any additions/deletions | 17:48 |
| nigelb | if some thing needs to be added, add to the TODO page | 17:48 |
| nigelb | https://wiki.ubuntu.com/ReviewersTeam/TODO | 17:48 |
| persia | Or just do it :) | 17:48 |
| nigelb | yeah, that works too :) | 17:49 |
| persia | OK. Anything else about PatchDay? | 17:49 |
| bdrung | nigelb: https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved -> Workflow -> first entry should have a LP link | 17:50 |
| persia | RIght then. Moving on: Item 3: Policy for new members to join | 17:50 |
| dholbach | I think it'd be good if they could mention a couple of bugs they already worked on | 17:50 |
| nigelb | bdrung, the LP subscribed bugs? | 17:51 |
| dholbach | so they demonstrate that they know when to forward stuff to upstream and debian and how to do it, etc | 17:51 |
| 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. | 17:51 |
| bdrung | nigelb: yes | 17:51 |
| dholbach | + people we know who do good work | 17:51 |
| 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. | 17:52 |
| dholbach | sure, that's not what I meant | 17:52 |
| persia | Oh, yeah. I completely agree that "people we know do good work" is the right criterion. | 17:53 |
| dholbach | endorsements-for-people-who-asked + people-who-can-show-they-did-good-work-for-people-who-asked | 17:53 |
| bryce_ | how many people are you expecting will want to join? | 17:53 |
| dholbach | bryce_: there's already a bunch that tried to join :) | 17:53 |
| bryce_ | dholbach, oh, how many? | 17:53 |
| persia | bryce_: I think ~50 members would be a good target. | 17:54 |
| dholbach | bryce_: I think 10 in the last month (and that with the little publicity the team got) | 17:54 |
| 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. | 17:54 |
| nigelb | sorry, got disconnected | 17:55 |
| bryce_ | persia, ah, so are you assuming 50 active contributors, or 50 of which a subset is contributing? | 17:55 |
| 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 | 17:56 |
| 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. | 17:56 |
| dholbach | so it doesn't get to heavy-weight | 17:56 |
| 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). | 17:57 |
| dholbach | persia: yes, sure | 17:57 |
| dholbach | persia: who else would? | 17:57 |
| 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". | 17:57 |
| 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. | 17:58 |
| dholbach | sure, that wasn't my plan | 17:58 |
| nigelb | I agree | 17:58 |
| nigelb | something simple but something agreed upon | 17:58 |
| dholbach | the good thing is that nobody is blocked because of lacking team membership | 17:58 |
| dholbach | they can still do good work | 17:58 |
| persia | RIght. | 17:59 |
| dholbach | ok great | 17:59 |
| nigelb | only they can't unsubsribe, its only a matter of asking here :) | 17:59 |
| persia | Alright then. Anything else anyone wants to raise whilst we're all here? | 17:59 |
| dholbach | not from me | 17:59 |
| bryce_ | I have an anecdote | 17:59 |
| bdrung | are there any plans to create scripts? | 17:59 |
| bdmurray | I had one question too | 18:00 |
| bryce_ | yesterday I looked through the 'audacious' bugs (a music player I use which has been quite buggy) | 18:00 |
| bdrung | bryce_: i saw that | 18:00 |
| bryce_ | I saw half a dozen patches posted, and thought, "Wow, someone's been active, I should sponsor these!" | 18:00 |
| bryce_ | then I looked and saw they were all patches I had made and posted 1.5 yrs ago hoping someone would sponsor them :-/ | 18:00 |
| nigelb | lol | 18:01 |
| bryce_ | so... there's definitely a need for this ubuntu-reviewers team :-) | 18:01 |
| 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. | 18:01 |
| 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 | 18:01 |
| nigelb | bryce_, if anyone can help with scripts, I'd be really happy :) | 18:02 |
| 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. ;-) | 18:02 |
| nigelb | bdrung, you have thoughts of a few snippets that could help? | 18:03 |
| 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 | 18:03 |
| persia | I think we want a mix. | 18:03 |
| 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 | 18:03 |
| 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. | 18:04 |
| nigelb | bdrung, some of the patches are badly formated which needs to be manually corrected | 18:04 |
| nigelb | I've come across a few so far | 18:04 |
| bdmurray | How can we as a group track these variables and issues persia? | 18:04 |
| bryce_ | nigelb, right but who does that fixup? | 18:04 |
| nigelb | I do it manually when I see that the patch doesn't apply cleanly | 18:05 |
| bdrung | nigelb: yes, human investigation is still required. | 18:05 |
| 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) | 18:05 |
| nigelb | bryce_, most things are small enough for us to fix ourselves :) | 18:06 |
| 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? | 18:06 |
| bryce_ | nigelb, fair enough | 18:06 |
| bdrung | bryce_: and as maximum of automation: we may push all patched packages to an ppa. so the submitter can test it directly. | 18:07 |
| bdmurray | persia: yes, something like that would be fantastic | 18:07 |
| nigelb | bryce_, I'm for automation but probably after a little bit of human intervention...like a human okaying for auto-testing patch | 18:07 |
| persia | nigelb: Could you organise such a wiki page? | 18:07 |
| 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. | 18:07 |
| nigelb | persia, yes. definitely | 18:07 |
| persia | Thanks. | 18:07 |
| bdmurray | bryce_: did you do something similar for automating X bugs? | 18:07 |
| bryce_ | bdmurray, yep | 18:08 |
| nigelb | bryce_, do you folks triage the X bugs with patches on your own? i.e. can we exclude X and kernel? | 18:08 |
| bdrung | maybe we can take some bits from the ack-sync script | 18:09 |
| bryce_ | nigelb, don't exclude X | 18:09 |
| bdmurray | nigelb: kernel is excluded in the script too - they go to Jeremy Foshee | 18:09 |
| nigelb | JFO right? | 18:09 |
| bdmurray | yeah | 18:09 |
| bryce_ | nigelb, while I have tended to the X patches I won't be doing X.org next release | 18:09 |
| nigelb | bryce_, but would we folks know what we're doing? I'm lost with X | 18:10 |
| 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. | 18:10 |
| bryce_ | nigelb, plus I'm curious to see how this process works with something like X.org | 18:10 |
| nigelb | http://pastebin.ubuntu.com/408255/ this is an intersting pastebin of top packages with patches that the LP guys generated | 18:10 |
| nigelb | bryce_, the X package there was a special case that you mentioned the other day? | 18:11 |
| nigelb | where the upstream posts patches for users to test, so can we exclude them from the scope of this review? | 18:11 |
| 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 | 18:11 |
| bryce_ | nigelb, right that's xserver-xorg-video-openchrome | 18:12 |
| nigelb | bryce_, I'd be happy to help with the smaller bits, but this xserver-xorg-video-openchrome can be excluded...yes? | 18:12 |
| bryce_ | nigelb, yes | 18:12 |
| persia | I don't think we should exclude patches from upsteam. | 18:13 |
| persia | They just get the "patch-approved-upstream" tag extra-fast. | 18:13 |
| persia | bdmurray: You had a question at :00 ? | 18:15 |
| nigelb | hm | 18:15 |
| 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 | 18:15 |
| persia | Oh, I misunderstood then. Hrm. | 18:15 |
| bryce_ | iow, patches that aren't appropriate to be sponsored | 18:15 |
| nigelb | yeah, I saw some heated arguments on one of those bugs | 18:15 |
| 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.. | 18:16 |
| 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. | 18:16 |
| 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. | 18:16 |
| nigelb | I'm not subscribed since it was only a bug list. mostly the patch tag getting added | 18:17 |
| * persia doesn't use that list | 18:17 | |
| nigelb | ah, bdmurray ... question | 18:17 |
| nigelb | is it possible for your script to use a different username? (so that we know its the script) | 18:18 |
| bdmurray | probably but why? | 18:19 |
| 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. | 18:19 |
| nigelb | ah. | 18:19 |
| nigelb | forget then. | 18:19 |
| nigelb | bdmurray, you had a question earlier? | 18:21 |
| 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" | 18:22 |
| thekorn | just my 50cent ;) | 18:22 |
| persia | I really prefer when scripts don't add such comments: it tends to send me lots of unwanted bugmail. | 18:22 |
| bdmurray | well its already sending e-mail due to adding the tag | 18:23 |
| nigelb | yeah, as such the patch tag addition is a bit of unwanted mail :D | 18:23 |
| bdmurray | so what's a few characters more ;-) | 18:23 |
| bdmurray | nigelb: I asked it earlier about the mailing list | 18:24 |
| persia | Somehow it seems like I don't get email for tags / status changes, but mostly just for comments. | 18:25 |
| persia | Maybe it's just me (or my memory) | 18:25 |
| nigelb | bdmurray, I'm undecided whether to join or not | 18:25 |
| persia | OK. If everything has been asked, I think we're done. Thanks everyone! | 18:25 |
| nigelb | just a momment | 18:26 |
| nigelb | https://wiki.ubuntu.com/ReviewersTeam/KnowledgeBase | 18:26 |
| 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? | 18:26 |
| nigelb | If anyone feels something needed to be added to the knowledge base please add or let me know what is to be added :) | 18:26 |
| persia | bryce_: We'd have to teach LP about it first, but after that it's easy. | 18:26 |
| bryce_ | hmm | 18:27 |
| bryce_ | kind of a "minor edit" type flag | 18:27 |
| bdmurray | a new X-Launchpd header? | 18:27 |
| nigelb | thank you folks for the time.. :) | 18:27 |
| bryce_ | thanks | 18:27 |
| 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. | 18:27 |
| persia | bdmurray: Precisely. | 18:27 |
| persia | I don't think it should be for every API change though, because of tools like groundcontrol and bughugger | 18:28 |
| 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 | 18:29 |
| bryce_ | or maybe the latter wouldn't need a flag | 18:29 |
| persia | I think the latter wouldn't get the flag, because you *want* to notify the user | 18:31 |
| bryce_ | persia, yeah so just a "minor automatic edit" type flag is needed. | 18:34 |
| nigelb | persia, that was truly *awesome*. Now, we have some sort of coordination and agreement to things ) | 18:34 |
| persia | That would be my preference. | 18:35 |
| bryce_ | such could be handy for apport-collect too, when it does a separate email for each attachment | 18:35 |
| persia | nigelb: And next time, you get to chair the meeting :p | 18:35 |
| persia | apport would be a huge user. | 18:35 |
| nigelb | persia, no thanks. :D | 18:35 |
| nigelb | jcastro, if you've got time we'll finish off the work on the mail now :) | 18:35 |
| jcastro | yeah | 18:39 |
| jcastro | basically I think just adding some spice in there would help. | 18:39 |
| nigelb | I'll toss it into an etherpad, so we can all edit | 18:39 |
| jcastro | yeah | 18:39 |
| jcastro | hey, ubuntu-uk has an etherpad btw | 18:40 |
| nigelb | it does? linky? | 18:40 |
| jcastro | http://pad.ubuntu-uk.org | 18:41 |
| nigelb | http://pad.ubuntu-uk.org/aSZVcm7UE9 | 18:42 |
| jcastro | on it | 18:42 |
| jcastro | nigelb: link me to your blog pls | 18:42 |
| nigelb | yes | 18:43 |
| nigelb | jcastro, http://justanothertriager.wordpress.com/2010/03/16/1801-bugs/ | 18:43 |
| nigelb | jcastro, I think we can use bryce's anecdote too | 18:43 |
| jcastro | nigelb: paste it in there and I'll work it in | 18:44 |
| nigelb | okay :) | 18:44 |
| 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" ? | 18:44 |
| nigelb | thekorn, generally upstream commits to svn or git immediately | 18:45 |
| nigelb | but yes, that counts too :) | 18:46 |
| persia | I'd call that patch-accepted-upstream even. | 18:46 |
| nigelb | yep I second ^ | 18:46 |
| persia | I consider patch-forwarded-upstream an intermediate state, indicating we're waiting for an upstream accept/reject still. | 18:46 |
| thekorn | right , forwarding and accepting are two different things, | 18:47 |
| thekorn | now the question is: what do we want to indicate in the review workflow | 18:47 |
| persia | To me the important things are: | 18:47 |
| persia | 1) I'm on it. | 18:47 |
| jcastro | nigelb: ok how's that? | 18:48 |
| persia | 2) Someone qualified is looking at it | 18:48 |
| nigelb | jcastro, its awesome :) | 18:48 |
| persia | 3) It's good/bad | 18:48 |
| nigelb | persia, anything to add/edit to http://pad.ubuntu-uk.org/aSZVcm7UE9 ? | 18:49 |
| persia | I thought it was May 5th, not May 6th. | 18:50 |
| nigelb | corrected | 18:50 |
| 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 | 18:51 |
| 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. | 18:51 |
| jcastro | "we will try" | 18:51 |
| jcastro | :p | 18:51 |
| 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. | 18:51 |
| persia | "try" works :) | 18:51 |
| 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. | 18:52 |
| nigelb | thekorn, I'll add use cases over this week | 18:52 |
| 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. " | 18:52 |
| nigelb | thekorn, what parts are most confusing? | 18:53 |
| nigelb | thekorn, I'll add more details to those. | 18:53 |
| persia | Last bits edited inline. | 18:53 |
| thekorn | nigelb, for me there are so many bold bits in the workflow section | 18:54 |
| thekorn | nigelb, but otherwise it is looking great | 18:54 |
| thekorn | and I think concrete examples will help alot | 18:54 |
| nigelb | thekorn, all tags are bolded to mark them as tags | 18:54 |
| nigelb | looks like I'll need to make some changes to the wiki first | 19:02 |
| 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.""" | 19:03 |
| 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 | 19:04 |
| thekorn | s/envolve/involve | 19:05 |
| nigelb | ok, its like this. a bug is in review queue | 19:05 |
| persia | The entirety of the process. "This patch has been handled". | 19:05 |
| persia | Rejected upstream/debian/ubuntu or accepted upstream, etc. | 19:05 |
| nigelb | yeah.. the simple explanation :) | 19:05 |
| nigelb | persia, I think reviewers can be unsubscribed when patch-needswork. can be resubscribed once work done? | 19:10 |
| nigelb | also... um, how to do negative searches again? | 19:10 |
| bryce_ | nigelb, prepend a - | 19:10 |
| bryce_ | so like "foo bar -baz" | 19:10 |
| bryce_ | also make sure to set the tag combinator thingee to 'All' rather than 'Any' | 19:10 |
| persia | nigelb: Works for me. | 19:11 |
| nigelb | brian also suggested the same for forwarded upstream | 19:11 |
| persia | I don't think we want to unsubscribe for forwarded-upstream. Maybe accepted-upstream or accepted-debian. | 19:12 |
| persia | TO me, forwarded-upstream implies we're still responsible for the patch. | 19:12 |
| nigelb | then I need to do the negation | 19:12 |
| nigelb | https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers&field.tag=patch&field.tag=-patch-forwarded-upstream&field.tags_combinator=ALL | 19:12 |
| nigelb | This is supposed to work ^ | 19:13 |
| persia | Launchpad doesn't understand the form data submitted in this request. | 19:13 |
| nigelb | yeah | 19:13 |
| nigelb | ah, figured it out | 19:14 |
| nigelb | so joining is apply and prove work you've done or apply and get an ack from current member | 19:20 |
| persia | or come hang out here and do stuff until someone gets annoyed and bugs an admin to add you. | 19:23 |
| nigelb | yes, that is indeed needed :D | 19:24 |
| nigelb | tweaked a bit https://wiki.ubuntu.com/ReviewersTeam | 19:31 |
| vish | jcastro: damn you are fast! , i just about to warn you about the typo and got your second mail :) | 20:43 |
| jcastro | it happens every time. :D | 20:43 |
| vish | hehe.. | 20:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!