=== johnc4510-laptop is now known as johnc4510[A] === johnc4510[A] is now known as johnc4510-laptop === Pere_Noel is now known as illovae === Varka_ is now known as Varka === johnc4510-laptop is now known as johnc4510[A] === johnc4510[A] is now known as johnc4510-laptop === asac_ is now known as asac === Riddelll is now known as Riddell === _czessi is now known as Czessi === sladen_ is now known as sladen [16:40] When's the next meeting [16:40] ? [16:40] @now [16:40] Current time in Etc/UTC: December 15 2007, 16:40:29 - Next meeting: Server Team meeting in 2 days [16:41] thank you === \sh_away is now known as \sh === Mamarok is now known as markey === \sh is now known as \sh_away === bigon_ is now known as bigon === alleeHol is now known as allee [21:00] @now [21:00] Current time in Etc/UTC: December 15 2007, 21:00:21 - Next meeting: Server Team meeting in 2 days [21:00] @later [21:00] :p [21:00] DktrKranz , LaserJock , ummm [21:00] whoelse we need ? [21:01] heya nixternal [21:01] themuso and jdong [21:01] wasabi...impromptu meeting? [21:01] nixternal: well kinda, we dident put it on the fridge but yea [21:02] afk one sec, ping me when all showup [21:06] What meeting is this? [21:07] the 3 of the Apocalypse [21:07] wasn't is about some Sergio Leone's spaghetti western? [21:07] s/is/it/ [21:08] yes [21:08] I've seen them too many times I'dont even remember [21:09] have you been cleaning the u-u-s queue recently? Seems to be getting back to a reasonable size again [21:09] A couple of bugs, yes [21:10] tell Mario that if he requests sponsoring for another desktop/icon file I'm personally going to find him in his house and burn it down [21:10] LOL, why? [21:11] its about time he starts doing something ... hmmmm ... with more meat in it [21:11] Mario who? [21:12] norsetto, time for him to do something more "useful" [21:12] Sorry I'm late guys. [21:12] Not at all :) [21:12] lol [21:13] ok, TheMuso jdong DktrKranz , how does this look https://wiki.ubuntu.com/StableReleaseUpdates/imbrandon [21:13] we've just finished and uploaded almost everything [21:13] well ... its not that what he did was not useful, at least it was for him, but after the 256785th one it gets on my nerves [21:13] :P [21:13] ok shhhhh [21:13] please :) heh lets do the stuff at hand for the SRU team then we'll chit-chat :) [21:13] TheMuso: no worries :) [21:13] imbrandon: looking... [21:14] looking [21:14] * DktrKranz looks [21:14] basicly the changes i made were to 1) wipe out the old universe update proceedure and 2) make 2 amendments for universe , otherwise its exactly the same as main [21:14] * norsetto sleeps [21:14] imbrandon: where on the page should I look [21:15] ah ok [21:15] TheMuso: #universe [21:15] this way we can stay as close to main sru policy as possible, i realy dont see much of a reason to diverge, only we do the work vs the main sru team [21:16] splitting the workload etc [21:16] SOunds good. [21:16] imbrandon: yeah, sounds good to me, too -- I like how closely it follows the -main procedure [21:16] Likewise. [21:17] there's another difference [21:17] it's about verification [21:17] yea really we just add a few more "when" clauses [21:17] in main, it is done by SRU verification team, in universe by two persons [21:18] we can also handle the verification, they do in main also its just not updated on the page [21:19] basicly verification is just bug triageing [21:19] if you look [21:19] How do we indicate an ack? [21:19] And what gets done when theres a second ack? [21:19] so, no more "two works for me" ? [21:19] I'd like to propose another exception [21:19] well the packages in -universe might not be as easy for team members to do as in main, IMO [21:19] i.e. we should let any ordinary Joe help with verification [21:20] but perhaps make ~motu-sru final say in whether or not we're satisfied with the verifications [21:20] TheMuso: just by one of us explisitly saying ACK on the bug [21:20] right [21:20] tags should also be differents (motu-verification needed and motu-verification-done) ? [21:20] ok [21:20] norsetto, indeed [21:20] somerville32, which one? [21:22] DktrKranz, Packages containing purely documentation [21:23] I see that a reason for an SRU is also FTBFS. Does it only apply when old binaries exist or also when the packages FTBFS from the beginning? [21:23] that seems reasonable to me [21:23] geser: either [21:23] how is ~motu-sru notified of a proposal pending approval? [21:23] is it a issue going for the NEW queue? [21:24] (for new binaries) [21:24] does the nominate for $release functionality already ping us? [21:24] DktrKranz: no shouldent be a problem [21:24] jdong: huh? [21:24] no ~motu-sru is subscribed to the bug [21:24] e.g. email [21:25] imbrandon: ok, so the subscription is done manually by the filer. gotcha [21:25] jdong, does that feature generate any bugmail? I was not aware of that [21:25] * TheMuso wonders whether we have anything else to discuss. [21:25] DktrKranz: apparently not. It would be nice if it did, though :) [21:25] I need to head off for a bit soon. [21:26] Should I modify /imbrandon to state the doc exception? [21:26] ok so addition of the doc only packages, and motu specifc tags, anything else ? [21:26] somerville32: i got a lock on it [21:26] IMO if it can be as close to main as possible, thats a good thing [21:26] TheMuso: yup thats the goal [21:26] sounds great to me [21:26] the only remaining issue is verification, then [21:27] somerville32: Mind explaining the doc exception? [21:27] we need to diverge in some way [21:27] DktrKranz: verification is done by motu-sru as i said [21:27] TheMuso, If a package contains only documentation, it is an exception to the SRU rational [21:27] and we need to include it as well [21:27] somerville32: How so? [21:27] DktrKranz: sure [21:28] TheMuso, ie. A package containing only documentation does not have to meet the normal rational for an SRU [21:28] somerville32: we need to check on that one, it might botch translations [21:28] somerville32: But what might need changing? [21:28] I'm not saying I don't agree, I'd just like some good reasoning as to why we should make it an exception. [21:29] TheMuso, We've already had cases where we've needed to do an SRU for docs and Pitti said he had no problem approving them [21:29] somerville32: What needed changing? [21:29] I would have to look up the changelog [21:29] somerville32: all we're asking is for an example [21:30] somerville32, in that case, pitti uploaded packages straight to -updates? [21:30] i would also want to make sure it dosent botch translations to a stable release too [21:30] imbrandon: Agreed. [21:30] DktrKranz: no [21:30] DktrKranz, No, it went through normal testing. [21:30] DktrKranz: exceptions mean tey are eligable for a sru [21:30] ok, thanks [21:31] NOTHING goes right to -updates hehe [21:31] Although this doesn't apply to Universe, I know that the server team wants to do an SRU for their docs [21:31] imbrandon, and it's a great thing! :) [21:31] I was worried :) [21:32] laser should be here in moments [21:32] ok I can't stay long though [21:32] anyhow i think we pretty much have it down pat [21:32] Hi all [21:32] just those few changes [21:32] agreed? tag changes and those fre exceptions [21:32] few* [21:32] +1 [21:33] +1 [21:33] +1 [21:33] +1 :) [21:33] -1 [21:33] just wanted to be different, of course +1 [21:33] * somerville32 slaps nixternal with a wet noodle [21:33] nixternal: lol [21:33] hehe [21:34] LaserJock: just to recap, i have a working doc at wiki/SRU/imbrandon , basic changes are throw out any old universe sru policy and go with mains with only 2 exceptions, more SRU worthy updates ( noted on wiki ) and motu specific tags [21:34] what about pending SRUs? do they follow old policy or should we take them into account? [21:34] its unamimous if you +1 it [21:34] http://people.ubuntu.com/~ubuntu-archive/pending-sru.html [21:34] DktrKranz: I'd say keep them as is [21:34] these --^ [21:35] DktrKranz: the pending sru's on that page are already uploaded, ones in the QUEUE on LP should be updated to follow this meetings decision [21:35] imbrandon: it seems our policy really doesn't differ from Main, do we need a separate section? [21:36] LaserJock: For tags and our extra exceptions. [21:36] IMO [21:36] LaserJock: no i'm gonna update the page so it looks better, and intergrate it with one policy and just NOTE: sections for universe [21:36] after we all agree [21:37] that was just how the old page did it so i quickly updated it [21:37] durring the meeting [21:37] imbrandon: do we really have extra exceptions? [21:37] cleanup and beuitification can be done after :) [21:37] LaserJock: yes [21:37] Do we keep minimum aging period? I think main does not have something like that [21:37] DktrKranz: yes they do [21:37] imbrandon: doesn't look like it to me [21:38] imbrandon, yes, I overlooked :) [21:38] LaserJock: FTBFS, cannot install, and segfault on startup ( e.g. completely un-usable ), and documentaion only packages [21:38] I think those are all SRUable in Main [21:38] not currently [21:38] it widens it just a tad [21:38] Whats written down and what actually happens is a bit different [21:38] ummm [21:39] e.g. not all FTBFS are regressions and such, so no not all those in main [21:39] Main only says high-impact bugs [21:40] right [21:40] FTBFS, segfault, uninstallable in general seem high-impact [21:40] not always in the eyes of the main sru team, this we are stateing them explisitly [21:40] if they do fall into some overlap no loss, we just adding some verbage [21:41] Ok guys, I gotta run. [21:41] TheMuso: cool [21:41] * TheMuso will leave this channel open and read later [21:42] should we cover bugs similar to malone 176435? it renders package unusable [21:42] Launchpad bug 176435 in twill "python-twill missing a dependency" [Undecided,Confirmed] https://launchpad.net/bugs/176435 [21:42] this one is a missing dep [21:42] DktrKranz: that falls under uninstallable [21:42] correct? [21:42] well, I'm just worried if we have delta from Main [21:43] imbrandon, it is installable, but not usable at all [21:43] DktrKranz: i would have to look closer but it seems like it would [21:43] I think we should agree on the kinds of things we think should be SRU internally [21:43] but I like vague language on the SRU wiki page [21:44] DktrKranz: that would be a regression [21:44] LaserJock: umm yea thats what the doc and meeting is about hehe, it seems we are all on the same page but imho DktrKranz needs a bit og hand holding as he is very green [21:44] no offense DktrKranz :) [21:44] :) [21:44] s/og/of [21:45] * DktrKranz takes his gun and loads it with some bullets [21:45] anyhow LaserJock yes there would be a delta from main but pitti has already signed off on it as "ok" and the other sru team members, i dont think the delta is that large, infatc it is very very very small compared to even what pitti proposed on the ML [21:46] indeed [21:46] I was thinking we should just s/~ubuntu-sru/~motu-sru/ [21:46] does that not work? [21:47] yes it does, but in addition to ( since universe doesnt get as much QA ) we should have these [21:47] have what? [21:47] the extra SRU canidate rules [21:47] the only delta [21:47] but they aren't [21:47] but they ARE [21:47] the Main SRU policy would cover those [21:48] the only actual policy there is that it must be "high impact" [21:48] but what that actually means is up to us [21:48] LaserJock: not in the main sru teams eyes they arent, and not all of them are, we are hurting nothing by explisitly stating them if you think they overlap [21:48] so why not keep it that way? [21:49] plus there is no doc exception [21:49] well, my concern would be that people see that as saying that you *can't* do those types of SRUs in Main [21:49] which is just not true [21:49] no not at all, and either way its not our problem [21:50] main sru can choose to clarify too if they feel the need to [21:50] but why do we need to clarify? I guess that's my question [21:51] I don't really get why we need to explicitly mention those. Is it because people don't know they can? [21:51] ummm i explained this 3 or 4 times already , main sru team dosent ALWAYS acept those as canidates, we are explitily saying we will [21:51] hmm, I don't think we should *always* either [21:51] they should all be case-by-case [21:52] but in general yes, I would be all for those kinds of exceptions [21:52] s/exceptions/SRUs/ [21:52] then whats the problem i dont get your reasoning [21:52] that we'd be creating needless diff and confusing the issue [21:53] the language is intentionally vague, IMO [21:53] ok then all i can say at this point is its been +1'd by all , propose your only changing the team name and see what everyone thinks, i personaly think this is a important verbage cahnge [21:54] well, that's what I'm trying to get at [21:54] obviously people like the change, so I'm trying to understand it [21:55] I'm not sure how the verbage is gonna change [21:55] well they like it because it does clairify the diffrence, your looking at it from a no diff, diff is "OK" if its minimal and servers seomthing, in htis case its both [21:55] well, I'm actually saying there really isn't any diff [21:56] I've seen every case we're talking about as "exceptions" done in Main [21:56] LaserJock: there IS, in your opinion there might not be, but not everyone will interret it the way you do so its GOOD to clarify [21:57] ok, so what if we talked to ~ubuntu-sru about these and perhaps expand the examples? [21:57] those are just examples, not an exhaustive list or anything [21:57] what does that matter to us? [21:57] because we have the same issues before us [21:57] an SRU really shouldn't matter if it's in Main or Universe [21:58] ugh no we dont inhaently we have very diffrent issues [21:58] sure it does [21:58] * TheMuso is back. Took less time than I thought [21:58] my experience is that Main does the same kinds of SRUs that Universe does [21:58] so why create diff where it doesn't really exist [21:59] ugh LaserJock ok my point here is we need to decide on a policy, if later someone wants to do the legwork and see if "upstream would like to merge" sweet , i'm all for it, but it should NOT be a blocker for us [21:59] imbrandon: right, I'm saying our policy is the same as Main's [21:59] but you're wanting to add some more examples [22:00] and i'm saying it is "alomst" and it needs to be clarified and these words added [22:00] which is fine, I agree with you there [22:00] alright, well whatever, it's not a biggie [22:00] and if you feel main would benifet from those changes too cool, propose them to them, but why does that stop us from doing it now [22:00] it doesn't [22:01] they're only freaking examples :-) [22:01] it's not policy [22:01] well thats the thing, this IS policy [22:01] well, that's what I was trying to say earlier [22:01] or is going to be [22:01] we should have internal polices of what we want to take [22:02] ????????? [22:02] i'm hearing you in circles now [22:02] but the SRU wiki page shouldn't have an exhaustive list of what we'll take [22:02] because then there's no point in having MOTU SRU [22:02] the whole point of having the team is that these need to be decided on a case-by-case basis [22:03] I'm sure there will be some high-impact bugs that we'll reject [22:03] because the changes are just to invasive for us to do [22:03] right if it falls into one of those categorys, its not an exasutive list it is a list of acceptable categorys [22:03] right [22:04] but the categorys have to be defined exastively [22:04] not "examples" [22:04] and I find that so trivial (and the same as Main) so I don't see why it justifies a diff [22:04] no [22:04] that's not true [22:04] those categories are examples [22:05] not exhaustive, even of types of SRU [22:05] as far as I understand [22:05] anyway, we can talk to Ubuntu SRU about that later [22:05] this is such a trivial thing we don't need to argue over it [22:05] i have no desire to talk to Ubuntu SRU about it, but feel free to, i'm here to solidify our policy [22:06] my point exactly [22:06] ok [22:06] so my question would be, are we gonna take SRUs that would not fall in those categories or do we want to talk them over? [22:07] if it dosent fall into one of those categorys , yes i think a consensus is needed, but that my 0.2c [22:07] seems reasonable [22:07] ok, any other diff? [22:07] motu specific tags [22:08] is the only other thing [22:08] why do we need motu specific tags? [22:08] i dident think so but the rest of the team did so i went with it, cant hurt, only makes it easier to seperate them on lp [22:09] hmm, I don't really see the point [22:09] imbrandon: Yes, there is the searching side of things that separates them a lot more easily. [22:09] seems like added confusion [22:09] because how else are we gonna find them LaserJock [22:09] mh, that's a good point, is MOTU tags really needed? [22:09] you can do the same thing [22:09] you can search for the tag + Universe component [22:09] so we'd just have a tinyurl for that [22:09] that would do the same thing as a motu-specific tag no? [22:10] but is main gonna be "ok" filtering out our stuff from their searches [22:10] they're gonna have to be ;-) [22:10] this is the whole point of being able to do such searches [22:10] you can have a tag and then filter the specific responses you want [22:11] ok i have no opinion either way, either seems just as easy, so i'm +0 , yall ? [22:11] I seriously doubt Ubuntu SRU can claim exclusivity to "verification-needed" [22:11] heh [22:12] and really, the point is for people testing [22:12] yea seems eassy enough if we can also filter by component [22:12] and I don't see why they'd really care what component it's in [22:12] * TheMuso is not fussed either way [22:12] I have no problem using the same tags, but we should update our links [22:12] DktrKranz: we will [22:12] and eventually ask pitti to adjust his script [22:13] I think it consider universe SRUs verified by looking at verification-motu-done [22:13] DktrKranz: what would he have to adjust? [22:13] DktrKranz: thats alll tech stuff that can follow policy, policy shouldnt follow tech :) [22:13] of course :) [22:15] ok, so ... [22:15] okies we 're going just over an hoour here, i think we're all on the same page, we just add a few exmples ( and LaserJock can poke the main sru if they want them also ) and s/ubuntu-sru/motu-sru , other than that we stuck with main policy [22:15] darn, I messed everything up [22:15] everyone good with that ? [22:15] yep [22:15] imbrandon: do you have text for the exceptions? [22:15] sure [22:15] LaserJock: give me 2 seconds and i will [22:16] I still don't like it but hopefully Ubuntu SRU would agree to absorb the changes [22:16] FTBFS, cannot install, and segfault on startup ( e.g. completely un-usable ), Documentation only packages [22:17] right, but I was actually thinking how we were gonna word the intro to those [22:17] but whatever, I'll get over it ;-) [22:17] ahh ummm [22:17] cause I can't really see how "In addition, for Universe the following examples:" [22:18] is gonna work [22:19] anyway, +1 from me [22:19] "In Universe ... also qualifies as high-impact-bugs " or similar [22:19] i would think [22:19] ... can also qualify as ... [22:20] yeah [22:20] I don't like the high-impact part as well though for doc-only SRUs [22:20] usually they aren't high-impact, more low-rish [22:20] ok so +1 from all but jdong and afaik he is afk, seems like he is outvoted either way, we'll note him as abstaining [22:20] *risk [22:20] imbrandon: aaah just got back [22:20] heh [22:21] hehe [22:21] just in time :) [22:21] * jdong reads scrollback [22:21] * DktrKranz gotta go [22:21] or does someone wanna summarize for me? [22:21] yeah [22:21] I'll read log later [22:21] everyone good with that ? [22:21] err [22:21] okies we 're going just over an hoour here, i think we're all on the same page, we just add a few exmples ( and LaserJock can poke the main sru if they want them also ) and s/ubuntu-sru/motu-sru , other than that we stuck with main policy [22:21] jdong: ^ [22:21] but, +1 for me [22:22] see you [22:22] yeah +1 as I said [22:22] +1 [22:22] +1 [22:22] imbrandon: yeah, that sounds good to me [22:22] +1 [22:22] \o/ [22:22] Good job. :) [22:23] \0/ , okies i'll have the page updated within ~20 minutes ( spellchecked hehe ) [22:23] See you. [22:23] yay, now back to this 24oz steak.... [22:23] and someone is free to mail the ML if they want [22:23] *i dunt wanna* lol [22:23] oh, wondered if we wanted some sort of "goal" for turnaround [22:23] *I wondered [22:23] who and huh? [22:23] like turnaround time? [22:23] oh we [22:24] yeah [22:24] ummm i dont think we should try since we're all un-paid [22:24] imho [22:24] agreed [22:24] other than "best efforts" [22:24] just as a goal, so we're on the same page [22:24] I think 1 week for decision, 2-3wks for verification sounds reasonable as a GUIDELINE [22:24] but best effort otherwise [22:24] heh [22:25] I was thinking 1 day for straight approval, 2 if it takes discussion, but maybe that's unreasonable [22:25] LaserJock: wow, ambitious [22:25] well, there are 5 of us and it only takes 1 [22:25] and all we need to do is "paperwork" [22:26] LaserJock: yea i think thats a bit ambisious, i think "best effort" is good , we're all not persia hhehe [22:26] lol, true that [22:26] most approvals should be a 10-minute deal on our part.... but it's best not to rush it with a time factor IMO [22:26] but one week is a fair "goal" as a guideline imho [22:26] if on average an approval takes more than a week, I think that's a warning flag that ~motu-sru isn't working well [22:26] thats even if we're all busy [22:26] as long as *we* aren't bottlenecking SRUs [22:26] Yeah [22:26] right [22:27] ok, so what's happening to the existing SRUs? [22:27] if things on avg are takin more than a week we'll get the MC to step in and get us some help [22:27] sounds good [22:27] LaserJock: well we agreed i think earlier that ones already with an uplaod will follow the old way, ones in the queue now on LP should be updated to the new policy [22:27] I still think best effort [22:28] realy, if it takes over a week, it takes over a week [22:28] TheMuso: yea [22:28] TheMuso: well.. yeah... not like the MC can come and put us in jail if we take too long [22:28] or suspend our paychecks :) [22:28] My point exactly. [22:28] but that doesn't mean we shouldn't have a guideline for how long it should acceptably take [22:28] TheMuso: my only real problem with that is consistency, people start getting upset when their SRU took 2 weeks and somebody else's take 2 days [22:28] I know that I may not be able to get to them all all the time [22:29] I realize we're all volunteers and best effort is as good as we can do [22:29] LaserJock: So what. Seriously, we are all volunteers. [22:29] TheMuso: volunteers can still measure how well they are doing thier work [22:29] People need to get over it if something takes shorter than someting else [22:29] jdong: that was more my reasoning [22:30] TheMuso: the guideline will strictly be a way we can assess how well the team is working, and if we need to change the process or recruit, etc [22:30] if we have a goal and we're consistently not getting there then maybe we need an adjustment [22:30] TheMuso: it's not designed to be a hard deadline to punish us [22:30] jdong: I know that. [22:30] anyway, we sounds like we should try to take no longer than a week [22:30]