| === emma is now known as Em | ||
| pleia2 | AlanBell: oops, thanks :) | 03:53 |
|---|---|---|
| === head_victim is now known as Guest2055 | ||
| === jason is now known as Guest54142 | ||
| === Guest54142 is now known as jasef | ||
| === Quintasan_ is now known as Quintasan | ||
| === bulldog98_ is now known as bulldog98 | ||
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| mdz | cjwatson, hi | 16:55 |
| === TheDaniel0108 is now known as EvilDaniel0108 | ||
| pitti | hello | 17:59 |
| pitti | kees: howdy | 17:59 |
| cjwatson | mdz: hiya | 17:59 |
| cjwatson | for those at UDS, we're in Antigua 1 | 17:59 |
| * pitti waves from Antigua 4, trying to split himself | 17:59 | |
| cjwatson | soren and stgraber are here | 18:00 |
| cjwatson | kees: are you around? I think we have everyone else | 18:00 |
| soren | o/ | 18:00 |
| cjwatson | well, let's get started | 18:01 |
| cjwatson | #startmeeting | 18:01 |
| meetingology | Meeting started Thu Nov 3 18:01:16 2011 UTC. The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. | 18:01 |
| meetingology | Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired | 18:01 |
| * stgraber waves | 18:01 | |
| cjwatson | [TOPIC] Action review | 18:01 |
| === meetingology changed the topic of #ubuntu-meeting to: Action review | ||
| mdz | o/ | 18:01 |
| pitti | hey mdz, how are you? | 18:01 |
| mdz | pitti, doing well, how is UDS? | 18:01 |
| cjwatson | can somebody remind me where the last minutes were? | 18:01 |
| cjwatson | soren says he couldn't find them | 18:02 |
| mdz | no idea | 18:02 |
| pitti | who lead last time, stgraber? | 18:02 |
| pitti | or was it cancelled? | 18:02 |
| broder | the auto-generated minutes would be somewhere in http://ubottu.com/meetingology/logs/ubuntu-meeting/ i believe | 18:03 |
| stgraber | http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-10-20-18.00.moin.txt | 18:03 |
| cjwatson | thanks | 18:03 |
| soren | http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-10-20-18.00.log.txt | 18:03 |
| cjwatson | cjwatson to setup a survey for a new Technical Board meeting time | 18:03 |
| cjwatson | done last night | 18:03 |
| cjwatson | I've had five responses, will wait for the sixth | 18:03 |
| soren | I'm not sure how to answer it. | 18:04 |
| soren | It depends on whether it will be revisited once DST kicks in again. | 18:04 |
| cjwatson | Let's agree now that it will, then | 18:04 |
| soren | Cool. | 18:04 |
| pitti | is it possible to update it somehow? | 18:04 |
| pitti | (I don't see how) | 18:04 |
| cjwatson | the existing poll? | 18:04 |
| pitti | my response to it | 18:05 |
| pitti | I filled it out with DST wiggling in mind, although it only affects two slots | 18:05 |
| cjwatson | hover over your name, there's an edit link to the left | 18:05 |
| mdz | this poll definitely stretched the limits of doodle | 18:05 |
| soren | It affects at least 10 timeslots for me :-/ | 18:05 |
| cjwatson | yes, it perhaps wasn't ideal for the purpose; I was short on time last night when soren reminded me that I had this action, otherwise I might have looked into other tools | 18:06 |
| pitti | cjwatson: thx | 18:06 |
| cjwatson | anyway, let's move on | 18:06 |
| kees | here now, sorry for the delay | 18:06 |
| soren | I don't know of any better tools. It's a (surprisingly) difficult problem. | 18:06 |
| cjwatson | stgraber to contact tumbleweed and if he agrees to be on the DMB, add him to the LP team and mailing list | 18:06 |
| cjwatson | kees: hi | 18:06 |
| mdz | what was the result of the poll? | 18:06 |
| stgraber | cjwatson: done, he's now on the DMB | 18:06 |
| mdz | oh, you're waiting for one more | 18:07 |
| cjwatson | mdz: waiting for soren's input; I'll post to the list once I've collated that | 18:07 |
| broder | i've found http://www.timetomeet.info/ to be quite good for this, fwiw | 18:07 |
| cjwatson | or rather reviewed doodle's collation | 18:07 |
| soren | cjwatson: Well, it also seems pitti wants to change his response. | 18:07 |
| * pitti updated his slots for DST adaption then, currently set up for winter time | 18:07 | |
| cjwatson | broder: thanks, hopefully we'll remember to try that next time :) | 18:07 |
| soren | Ah, ok, nm :) | 18:07 |
| pitti | soren: done now | 18:07 |
| cjwatson | stgraber to update the term of the DMB members to 2 years | 18:07 |
| stgraber | done | 18:07 |
| cjwatson | stgraber to add the new members to the ARB | 18:08 |
| stgraber | done for the team, still waiting for jono to contact IS to make me the admin for the mailing-list | 18:08 |
| stgraber | so we currently need to Cc all the members which is a bit annoying, I'll poke him in person :) | 18:08 |
| * kees listens to the sounds of typing in antigua1 | 18:08 | |
| stgraber | :) | 18:08 |
| cjwatson | stgraber: OK, thanks | 18:08 |
| cjwatson | I think broder agreed to us deferring "Opening backports pocket pre-release" to next meeting, as it's a recent submission and there's been no e-mail discussion yet - is that OK with everyone? | 18:09 |
| * kees nods | 18:09 | |
| soren | yup | 18:10 |
| stgraber | yep | 18:10 |
| cjwatson | (although broder is in Antigua 1 here ...) | 18:10 |
| broder | i'm fine with that. i was mostly hoping for an opportunity to resolve objections in person with the benefits of lower latency. but we've been kicking this around for a while now, so there's no sudden rush | 18:10 |
| cjwatson | if we have time at the end we'll come back to it then | 18:10 |
| cjwatson | [TOPIC] LTS cadence | 18:10 |
| === meetingology changed the topic of #ubuntu-meeting to: LTS cadence | ||
| soren | That would be me. | 18:11 |
| soren | The e-mail says it all, really. | 18:11 |
| pitti | the stage there changed a bit with going from 3 to 5 years on non-server, but in practice it sounds fine to me | 18:11 |
| pitti | everyone was pretty much operating on that assumption anyway | 18:11 |
| cjwatson | I don't think there's much point in us revisiting the Debian angle that Mark mentioned by e-mail; we've already tried going down that road and frankly it did not go well | 18:11 |
| pitti | including our own internal planning processes | 18:11 |
| pitti | and there's still a way out with an one-time change confirmed by CC/TB | 18:11 |
| soren | The motivation was a discussion in OpenStack where we talked about designating every 4th release an LTS one to follow Ubuntu, but someone pointed out that Ubuntu doesn't promise anything about this cadence. | 18:12 |
| kees | since LTSness is really Canonical-backed, I'm not sure the TB has any control over the LTS cadence exactly. | 18:13 |
| cjwatson | I do think we should leave ourselves a bit of flexibility, but promise to give plenty of notice if we exercise it, and have a damn good reason | 18:13 |
| soren | cjwatson: When was this? | 18:13 |
| pitti | cjwatson: yes, that option was explicitly in the mail | 18:13 |
| cjwatson | soren: Debconf in Caceres | 18:13 |
| soren | cjwatson: Er... Year? | 18:13 |
| cjwatson | I can bring you up to speed out of band if you like; it's a fairly long story | 18:13 |
| cjwatson | 2009 I think | 18:13 |
| pitti | and we need that, there might always things coming up that make a plannet LTS impractical | 18:13 |
| soren | cjwatson: Ok. Since then, Debian has switched to a time based release model, right? Not as strict as ours, but close, IIUIC. | 18:14 |
| cjwatson | time-based freeze | 18:14 |
| pitti | soren: well, s/has switched/wants to/ | 18:14 |
| soren | Ah, yes. | 18:14 |
| pitti | and not time-based releases | 18:14 |
| cjwatson | important distinction :) | 18:14 |
| * skaet nods | 18:14 | |
| soren | Ok, sure, let's take this off-line. | 18:14 |
| pitti | but Debian has different "ready for release" metrics and planning processes than we | 18:14 |
| cjwatson | while it's true that Canonical offers the LTS commitment, if the Ubuntu project offered strong and reasoned advice on timing I think Canonical would accommodate it | 18:15 |
| pitti | and with my Debian hat on, I don't see Debian do predictable time-based releases in the next two years or so | 18:15 |
| soren | Good points. | 18:15 |
| cjwatson | we have not had reason to do so up to now | 18:15 |
| cjwatson | and setting expectations in advance does have its own value | 18:16 |
| pitti | kees: OTOH, Mark explicitly asked the TB | 18:16 |
| kees | pitti: I don't meant to see TB has no influence, but we don't strictly control it | 18:16 |
| kees | s/see/say | 18:16 |
| mdz | I think that, for users, the benefits of predictability outweigh the potential advantages of being able to tweak the timing to align with Debian et al | 18:17 |
| soren | Well, if we all agree, whose decision it actually is is a bit of a moot point :) | 18:17 |
| pitti | kees: right; but if we come up with a good reason why e. g. 14.04 would be bad, but 14.10 would be better, then I'm pretty sure that this will strongly be considered at least | 18:17 |
| kees | I think overall, the current cadence should be maintained if for no other reason that it seems to work well and people have come to expect it. | 18:17 |
| pitti | mdz +1 | 18:17 |
| kees | but yeah, if there's a compelling reason to change, sure. | 18:17 |
| cjwatson | the example I've been using this week is a friend of mine who supports academics, and is keen on the new five-year desktop support combined with our LTS cycle because that means he can always support a desktop for the lifetime of a PhD without major version upgrades | 18:17 |
| kees | it'll just need to be very loudly announced since many organizations now expect the current cadence. | 18:18 |
| cjwatson | that's the kind of thing that a predictable cycle enables | 18:18 |
| soren | kees: Right. And this is really about making sure that is the case. | 18:18 |
| pitti | kees: frankly, I think we'd need to do this even without a formal commitment by now | 18:18 |
| cjwatson | (well, with some optimism attached ...) | 18:18 |
| soren | kees: ...because there hasn't so far been any promise that this is how it'll be. | 18:18 |
| * kees nods | 18:18 | |
| stgraber | I think the proposal is reasonable as it's pretty much what our users expect and we have a way of changing it if really really needed | 18:19 |
| cjwatson | pitti: right, we have an implied commitment | 18:19 |
| cjwatson | I'm hearing consensus here; does anyone feel we need to vote? | 18:19 |
| pitti | seems unanimous to me | 18:19 |
| mdz | +1 | 18:20 |
| stgraber | yeah, sounds like we all agree there | 18:20 |
| pitti | +1 | 18:20 |
| soren | +1 | 18:20 |
| soren | (obviously) | 18:20 |
| pitti | but if we got asked to sign off this, we might just as well :) | 18:20 |
| kees | (there's no bot listening, but...) +1 | 18:20 |
| cjwatson | [AGREED] ratify two-year LTS cadence as proposed by soren+mark | 18:20 |
| cjwatson | #agreed ratify two-year LTS cadence as proposed by soren+mark | 18:21 |
| mdz | #agree I think | 18:21 |
| cjwatson | apparently it accepts both but gives no feedback | 18:22 |
| mdz | ah | 18:22 |
| cjwatson | anyway, bot-fettling aside, I'll follow up by mail as part of doing minutes | 18:22 |
| cjwatson | [TOPIC] Streamlining package set management | 18:22 |
| === meetingology changed the topic of #ubuntu-meeting to: Streamlining package set management | ||
| cjwatson | (anyone know what this one is about?) | 18:22 |
| * Laney comes over | 18:22 | |
| broder | https://lists.ubuntu.com/archives/technical-board/2011-October/001104.html | 18:22 |
| soren | cjwatson: In case you want to go back to the meeting time discussion at some point, I've finished filling in my data. | 18:23 |
| cjwatson | ah, right, added a link to the agenda | 18:23 |
| cjwatson | so - my view (as the person who's done a lot of packageset manipulation) is that formal DMB votes approve developers for categories of permission, but it's fine for DMB members to use common sense in tweaking permissions for trivial package name changes and the like | 18:25 |
| cjwatson | (or whoever owns the team) | 18:25 |
| cjwatson | from my perspective it's a change to require having this be discussed and aged on devel-permissions, but personally I think that's a good change, as it provides an audit trail | 18:25 |
| mdz | yes, that seemed like the de facto status quo | 18:25 |
| mdz | Q.E.D. | 18:26 |
| cjwatson | (I've often done things like adding linux-backports-modules-$VERSION to the kernel set based on IRC requests) | 18:26 |
| stgraber | This proposal is basically about making official things that we've been doing, at least for the 3 first points, the last one is a very good idea though | 18:26 |
| Laney | IMHO an important change is that we start requiring people to provide criteria | 18:26 |
| Laney | something that we can assess change requests against | 18:26 |
| cjwatson | I think three days of aging would be unnecessary for things like that | 18:26 |
| cjwatson | not sure how to codify that | 18:26 |
| Laney | currently the definitions of the sets are rather loose | 18:26 |
| mdz | asking for criteria sounds reasonable | 18:26 |
| Laney | which makes acting on changes ad-hoc | 18:26 |
| mdz | though there will certainly continue to be lots of wiggle room and judgement calls for what's appropriate to add | 18:27 |
| stgraber | cjwatson: we could add some exception for cases where we have a versioned source package? | 18:27 |
| cjwatson | another example is things like Till having approved upload access to things that are obviously part of the printing subsystem | 18:27 |
| stgraber | as in, version in the source package name | 18:27 |
| cjwatson | although in that case perhaps some more aging is appropriate since there is often more overlap between what people maintain | 18:27 |
| soren | Is there any way to see when a package gets added (and possibly by whom)? | 18:27 |
| * kees wonders about revocation a bit | 18:27 | |
| Laney | stgraber: that is the kind of thing that can go in a description | 18:27 |
| Laney | soren: not afaik | 18:28 |
| soren | If changes to package sets were announced somewhere, I wouldn't mind if there were no aging period. | 18:28 |
| pitti | devel-permissions@ is meant to be exactly that | 18:28 |
| Laney | it is just as easy to remove a package, so I guess that will be enough in case of objections | 18:28 |
| stgraber | Laney: "I think three days of aging would be unnecessary for things like that" so that's for an exception to the 3 days rule when it's just a change to the source package name (when containing the version) | 18:28 |
| soren | pitti: I meant automatic announcement when the deed is actually done. | 18:28 |
| pitti | and if something really gets objections, we can always revert | 18:28 |
| soren | pitti: Does that land on devel-permissions? | 18:29 |
| pitti | soren: no, that's quiet | 18:29 |
| Laney | ok, no need for aging then | 18:29 |
| Laney | DMB member responds on -permissions to confirm that they did it | 18:29 |
| cjwatson | I'm not sure what audit trail Launchpad keeps | 18:29 |
| Laney | (or whoever) | 18:29 |
| soren | It's just easier to revert something if you know there's something to revert. | 18:29 |
| pitti | yeah, I think foo-1.0 -> foo-2.0 is really just a technical change, not a social/policy change at all | 18:29 |
| cjwatson | I would be happy to take an action to chase that down if people think it's important to have | 18:29 |
| kees | yeah, unless it gets abused or there a lots of reverts, I don't see a reason for the waiting period. | 18:29 |
| cjwatson | (though not to fix it ...) | 18:30 |
| pitti | soren: yes, that's why I meant it should be on d-p@ | 18:30 |
| soren | pitti: Gotcha. | 18:30 |
| cjwatson | is the DMB now able to take action on all package set manipulation requests that they care about? | 18:30 |
| pitti | in general it's a lot smoother to add new packages right away, as it unblocks devs | 18:30 |
| cjwatson | or is there still a requirement for somebody with some other demigod bit to do it? | 18:31 |
| Laney | TB still owns cli-mono for some reason | 18:31 |
| Laney | actually it still owns a few: http://people.canonical.com/~stgraber/package_sets/precise/ | 18:31 |
| cjwatson | damnit. changing owners is a pain, it requires a LOSA | 18:31 |
| Laney | but for ones we own, sure | 18:31 |
| stgraber | I can do the other ones for now | 18:31 |
| stgraber | being on both TB and DMB | 18:31 |
| cjwatson | yep, if you need TB action as a workaround, feel free to mail technical-board@ too | 18:32 |
| stgraber | though this really should be fixed on LP's side | 18:32 |
| cjwatson | yes | 18:32 |
| cjwatson | anyway | 18:32 |
| cjwatson | do we have something to vote on here? agree Laney's proposal minus the aging period? | 18:32 |
| soren | Sounds good to me. | 18:33 |
| kees | +1 | 18:33 |
| stgraber | +1 | 18:33 |
| pitti | something like "changing package sets is under the DMB's discretion as long as changes get announced to d-p@"? | 18:33 |
| pitti | +1 | 18:33 |
| cjwatson | +1 | 18:33 |
| Laney | ta | 18:34 |
| cjwatson | #agreed DMB discretion for changing package sets by common sense as long as they announce it | 18:34 |
| cjwatson | (sorry, I want to keep moving here as we have a couple more things) | 18:34 |
| cjwatson | [TOPIC] Proposal for criteria to become and remain a recognized derivative flavor, and proposal for criteria to designate flavor release as LTS | 18:35 |
| === meetingology changed the topic of #ubuntu-meeting to: Proposal for criteria to become and remain a recognized derivative flavor, and proposal for criteria to designate flavor release as LTS | ||
| cjwatson | [LINK] https://wiki.ubuntu.com/RecognizedDerivatives | 18:35 |
| cjwatson | this is something skaet has been working on, and perhaps she can present it briefly | 18:35 |
| skaet | We need to clarify some processes on the criteria for a set of images to be considered a recognized derivative and what is necessary for a derivative to be designated LTS. | 18:35 |
| skaet | Have worked up some proposals for criteria and would like to get them reviewed by TB and any necessary updates made; so we have a place to point folk when the questions come up. | 18:35 |
| pitti | we already discussed it yesterday briefly, and via mail before, and this looks very thorough and clear to me | 18:35 |
| mdz | skaet, this looks very good, we were overdue for a document like this | 18:36 |
| cjwatson | my main comment (which I've made in person etc.) is that I think this is often based on a general soft sense of how a flavour is interacting with us etc.; I think we normally tend to be fairly well aligned on that, from what I can tell | 18:36 |
| cjwatson | the main change is having some formal way that a very well-organised flavour can access the LTS processes | 18:37 |
| mdz | is there anything in here which is new, as opposed to codifying existing common practice? | 18:37 |
| kees | "Minimum 1 person sponsored at UDS" ? does that mean they must always be at UDS? | 18:37 |
| pitti | one thing I'd like to add is that a derivative must have at least N non-LTS releases before | 18:37 |
| pitti | skaet: ^ | 18:37 |
| cjwatson | mdz: the LTS bit is new | 18:37 |
| pitti | to get some proven track record | 18:37 |
| mdz | still reading | 18:37 |
| skaet | recognized flavor part was codifying, what I observed through lubuntu | 18:37 |
| skaet | LTS is new | 18:38 |
| cjwatson | kees: I talked with skaet about that - I think that meant that Canonical will always be prepared to offer such sponsorship | 18:38 |
| pitti | which is needed to get some acquaintance with their developers, etc. | 18:38 |
| mdz | cjwatson, I agree with your comment, and would support swapping "criteria" for "guidelines" to reflect that | 18:38 |
| cjwatson | maybe we should be a bit clearer there | 18:38 |
| kees | ah-ha | 18:38 |
| * skaet nods | 18:38 | |
| cjwatson | mdz: yes, that would be good | 18:38 |
| cjwatson | some of the wording on image testing is somewhat new as well | 18:38 |
| cjwatson | ("flavour QA lead") | 18:38 |
| skaet | we had that in the last release | 18:39 |
| cjwatson | indeed, sorry, that's what I meant by "somewhat" | 18:39 |
| skaet | :) | 18:39 |
| skaet | There is sometimes a separation in responsibility. | 18:40 |
| cjwatson | did you get any substantive comments from folk maintaining existing flavours? | 18:40 |
| skaet | In some cases the contact also serves as the lead, but this may not always be the case. | 18:40 |
| soren | Then we should clarify that they can be the same person, but that's a minor detail. | 18:40 |
| skaet | no issues raised from stgraber and riddell when I reviewed it with them. | 18:40 |
| skaet | Have talked about it with some others, but haven't done the 1:1 with all. | 18:41 |
| skaet | soren, ok. | 18:41 |
| cjwatson | OK, I'd like to hear feedback from at least one non-Canonical person since sometimes they have different perspectives ;) | 18:41 |
| cjwatson | but that sounds plausible so far | 18:41 |
| mdz | cjwatson, representing derivatives, you mean? | 18:42 |
| cjwatson | yes | 18:42 |
| skaet | Have talked to charlie-tca as well, and he was positive. | 18:43 |
| skaet | It happened in the UDS session earlier this week. | 18:43 |
| broder | i believe highvoltage was in the room as well | 18:43 |
| mdz | having something codified seems like a good step forward, and this is close enough to existing practice that I'm not too fussed | 18:43 |
| mdz | anything which turns out to be problematic we can change | 18:44 |
| skaet | broder, yup he was. Thanks for the reminder. | 18:44 |
| cjwatson | I agree with pitti's comments about N non-LTS releases; I expect the TB wouldn't approve something that was too new and untried, but it's good to set expectations | 18:44 |
| pitti | the main thing I'd like to avoid is to bless a brand new derivative as LTS right away | 18:44 |
| cjwatson | right | 18:44 |
| pitti | just because it happened to pop up at that time | 18:44 |
| * skaet nods | 18:44 | |
| * highvoltage catches up with conversation | 18:45 | |
| pitti | and if we have a document which codifies that, I think that should be in | 18:45 |
| pitti | skaet: the document doesn't actually seem to mention that LTSness requires TB signoff; does it? | 18:45 |
| pitti | I mean, does it intend to? | 18:46 |
| skaet | pitti, use of word criteria implies it. | 18:46 |
| broder | second bullet point says TB approval | 18:46 |
| pitti | oh, ignore me | 18:46 |
| pitti | grep fail, sorr | 18:46 |
| pitti | y | 18:46 |
| cjwatson | I think it's implicit in "recommendations for Tech Board consideration" anyway, but sure | 18:46 |
| cjwatson | skaet: s/criteria/guidelines/ as suggested earlier? | 18:46 |
| pitti | cjwatson: I thought the bold text would go away once that document gets approved | 18:47 |
| skaet | cjwatson, yes. | 18:47 |
| pitti | so, with TB approval the "have N previous releases" is kind of implied, but might still be good to set an expecation | 18:47 |
| cjwatson | pitti: fair | 18:47 |
| highvoltage | For Edubuntu, we're going to apply for LTS status with some notes on how we plan to support it for 5 years. It's probably a good excercise even if it's not strictly required. | 18:47 |
| pitti | with N=2 or so? | 18:47 |
| mdz | time check: we have 12 minutes and I have a hard stop (another meeting after this). is there anything further after this topic? | 18:48 |
| cjwatson | five years, really? gosh. I wasn't expecting non-Canonical flavours to manage that. (not that I inherently object, it just seemed like a big ask) | 18:48 |
| skaet | There's a choice of saying 3 or 5 years | 18:48 |
| pitti | mdz: same here | 18:48 |
| soren | Possibly talking about the meeting time. | 18:48 |
| cjwatson | I wouldn't mind getting back to broder's proposal if we have time | 18:49 |
| mdz | pitti, ouch, another meeting? | 18:49 |
| pitti | mdz: UDS | 18:49 |
| cjwatson | soren: I'm not going to have time to look at the doodle output before the end of this meeting | 18:49 |
| soren | No worries. | 18:49 |
| mdz | oh, right, you're in a nearby TZ now :-) | 18:49 |
| cjwatson | not and pay attention | 18:49 |
| highvoltage | cjwatson: that's what LTS means now, isn't it? | 18:49 |
| cjwatson | highvoltage: you have the option of either three or five years | 18:49 |
| cjwatson | if that's not clear, we should clarify this document | 18:49 |
| highvoltage | hmm, imho 3 years would actually be more appropriate for Edubuntu. <- stgraber? | 18:50 |
| cjwatson | (or 18 months, non-LTS) | 18:50 |
| cjwatson | let's take the edubuntu LTS length discussion separately | 18:50 |
| cjwatson | we don't have to do that now :) | 18:50 |
| pitti | shall we vote on the document then? | 18:50 |
| highvoltage | yes, sorry for noise :) | 18:50 |
| cjwatson | [VOTE] approve flavour support guidelines as adjusted by comments in this meeting | 18:50 |
| meetingology | Please vote on: approve flavour support guidelines as adjusted by comments in this meeting | 18:50 |
| meetingology | Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) | 18:50 |
| stgraber | highvoltage: I'll discuss that with you and alkis and we'll propose something for the next TB meeting | 18:50 |
| pitti | +1 | 18:50 |
| meetingology | +1 received from pitti | 18:50 |
| stgraber | +1 | 18:50 |
| meetingology | +1 received from stgraber | 18:51 |
| cjwatson | +1 | 18:51 |
| meetingology | +1 received from cjwatson | 18:51 |
| mdz | +1 | 18:51 |
| meetingology | +1 received from mdz | 18:51 |
| soren | +1 | 18:52 |
| meetingology | +1 received from soren | 18:52 |
| kees | +1 | 18:52 |
| meetingology | +1 received from kees | 18:52 |
| cjwatson | [ENDVOTE] | 18:52 |
| meetingology | Voting ended on: approve flavour support guidelines as adjusted by comments in this meeting | 18:52 |
| meetingology | Votes for:6 Votes against:0 Abstentions:0 | 18:52 |
| meetingology | Motion carried | 18:52 |
| skaet | Thanks! | 18:52 |
| cjwatson | [TOPIC] Opening backports pre-release | 18:52 |
| === meetingology changed the topic of #ubuntu-meeting to: Opening backports pre-release | ||
| skaet | I'll make the changes and remove draft. | 18:52 |
| pitti | skaet: thanks to you, nice writeup! | 18:52 |
| cjwatson | I don't know if we'll have time to finish this, but perhaps we can start | 18:53 |
| broder | i realize this has potential to be a complicated topic; i wasn't expecting decisions today | 18:53 |
| cjwatson | I'm somewhat concerned about skew in developer attention | 18:53 |
| cjwatson | and possibly what users are in practice testing | 18:53 |
| broder | with NotAutomatic: yes set on backports, users would have to work to be testing everything in backports | 18:53 |
| cjwatson | regarding skew in general, I think we could really use some tools to report on this kind of thing; to some extent we already have this problem with (e.g.) oneiric-proposed vs. precise | 18:54 |
| broder | right. Laney and i discussed something vaguely similar to a MoM configuration between release and backport pockets | 18:54 |
| broder | so we could watch for that skew | 18:55 |
| cjwatson | upload privileges: the original TB approval of direct uploads to -backports explicitly applied only to -core-dev | 18:55 |
| cjwatson | I don't remember that being changed | 18:55 |
| Laney | I can definitely upload… | 18:55 |
| cjwatson | right, technically ... | 18:55 |
| broder | i may have confused requirements to be on ~ubuntu-backporters and the requirements for direct uploads | 18:55 |
| broder | i've never tried a direct upload myself... | 18:55 |
| cjwatson | we probably ought to revise that anyway, that was in like 2005 or something | 18:55 |
| cjwatson | or at least review | 18:55 |
| broder | i certainly have a fair amount of uncertainty about what the technical enforcements are on backports; i'd prefer to discuss what we'd like to see implemented and we can be responsible for aligning our implementation with that | 18:56 |
| broder | ...assuming that i can sell the board on the idea in the first place, of course | 18:56 |
| cjwatson | archive admin workload: TBH I'm not worried about that, our job is to provide that service (among others) and we should ensure that we have enough people to do so | 18:56 |
| cjwatson | I think the technical enforcements on backports are by this point incoherent | 18:57 |
| cjwatson | perhaps it would be worth starting from scratch and saying how we'd like it all to work | 18:57 |
| cjwatson | er, that's what you said | 18:57 |
| cjwatson | vociferous agreement then | 18:57 |
| cjwatson | I'm pretty sure they aren't coherently written down in one place, at any rate | 18:57 |
| pitti | sorry, can we continue this next time? really need to leave | 18:57 |
| cjwatson | OK, and we can follow up by mail too; I have to move on too, per UDS clockwork | 18:58 |
| broder | same here | 18:58 |
| cjwatson | thanks a lot to everyone for attending, and to UDS folk for skipping the plenaries to do so | 18:58 |
| pitti | thanks, good meeting! | 18:58 |
| stgraber | thanks | 18:58 |
| cjwatson | mdz, kees: we're missing you here ;-) | 18:59 |
| cjwatson | #endmeeting | 18:59 |
| === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | ||
| meetingology | Meeting ended Thu Nov 3 18:59:17 2011 UTC. | 18:59 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-11-03-18.01.moin.txt | 18:59 |
| mdz | cjwatson, likewise! | 18:59 |
| mdz | SFO next time? :-) | 18:59 |
| cjwatson | I wouldn't say no :) | 19:00 |
| kees | hehe, SFO would be cool. 1.5 hr flight :) | 19:02 |
| === Pendulum_ is now known as Pendulum | ||
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!