20:08:51 #startmeeting 20:08:51 Meeting started Mon Sep 17 20:08:51 2012 UTC. The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 20:08:51 20:08:51 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 20:08:54 I guess we have quorum 20:09:02 #topic action review 20:09:30 The last minutes I see are ancient: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-May/000958.html 20:09:51 So I'm going to assume that we've just been quiet for that long and have no actions to review at this point; shout if that's untrue 20:10:07 #topic nvidia/fglrx expedited SRUs (bryce) 20:10:17 didn't we have some brainstorm review pending? 20:10:33 I'll have a look and get back to that later, then 20:11:16 #topic action review 20:11:27 #action stgraber to try and find all the places to update the TB meeting time to 20:00 UTC 20:11:31 now that I found the IRC logs 20:11:34 stgraber: did that happen? 20:11:54 yep, fridge was updated and wiki too, not aware of any other place to change 20:12:01 OK 20:12:37 soren_: so, this brainstorm review ... 20:12:48 (async ping as he doesn't seem to be here) 20:13:23 #topic nvidia/fglrx expedited SRUs (bryce) 20:14:01 bryceh: would you like to hash this out any more here? we don't seem to have consensus yet on the issue of unsubstantiated regressions 20:14:06 this was discussed on the ML for a bit already, but the fundamental stability vs. fast turnaround conflict remains 20:14:18 hi 20:14:29 I'm not sure I see that as the principal conflict :) 20:14:42 but I think the whole point of this request was to get leniency on stability there, so I guess we should rather discuss how to get back to the "normal" driver as quickly as possible? 20:14:43 cjwatson, yeah I was distracted writing a reply to that email 20:14:53 well, I did only send my reply earlier today 20:15:29 in general I'm supportive of being able to be a bit more relaxed about -updates SRUs, but I want to ensure that we aren't causing problems by doing o 20:15:32 *so 20:15:38 * bryceh nods 20:15:49 yes, I understood the goal to be to offer an alternative update stream which users could opt in to, with a greater tolerance for possible regressions in favor of compatibility with newer apps 20:16:11 right, *if* users understand that that's what they're opting into 20:16:30 yes 20:16:38 a warning would be appropriate 20:16:39 my concern is that if nvidia-current is busted for a user and nvidia-current-updates works, then their perception will be "this is the one that works" and will be discombobulated when it breaks 20:16:49 at the time when they need it, they probably won't have much incentive to not use it 20:17:29 this would be a lot easier if we could start things off this way as of (say) quantal, with update-manager having reset people to non-updates on upgrade 20:17:47 is that a feasible thing to do, or do we really really need this for precise? 20:17:51 bryceh: I did understand that for -experimental we do want to get back to the "regular" driver on every dist-upgrade; is that planned for -updates as well? 20:17:57 mdz, we are adding a warning for the nvidia-experimental package; currently there is no warning on nvidia-current-updates, although I think we could use the same mechanism to add one. 20:18:54 well, I do think that regression reports for -updates should at least hold the line, as usual for SRUs; for -experimental, being quick is the very point of the exercise, so that's where the leniency comes in, no? 20:19:00 pitti, right, plan is that we're doing that for -experimental. Whether to do that for -updates is open for discussion. 20:19:22 I'm not sure I see how the mechanism pitti proposes will achieve this 20:19:51 the proposal is that, at release time, -experimental is an empty transitional package depending on nvidia-current 20:19:51 cjwatson: I'm mostly concerned about enabling this for your favorite game of the day, and then forgetting about it, so that you keep having the risk for all eternity 20:20:06 and that later -experimental becomes a real package and drops the Depends 20:20:24 But that doesn't help, because everyone who had -experimental installed earlier still has it installed, transitional package or not 20:20:39 So the upgrade will turn it from transitional to real and we have the same problem 20:20:44 that would only work for dist-upgrades until there is a newer -experimental in the newer release, yes 20:20:48 so that does need u-m support 20:21:01 The only way I can see this working properly is bryceh's suggestion of changing package names for each nvidia series 20:21:21 Which is somewhat inelegant, but perhaps the best we can do? 20:21:22 cjwatson, to your earlier question, yes it's strongly wanted for the LTS 20:21:56 we did have that in the past, and for some reason that was changed to the -current name; but yes, -NNN would ceratainly make these upgrades work with pure apt 20:22:34 -current makes more sense for "the one we want most people to use" 20:22:39 yep 20:23:23 one question I don't have a good opinion on, so would like advice: 20:23:52 so yes - if we can start from a clean slate, and ensure that anyone who installs the given package has seen a warning (or had to go to effort to preseed it away), then I'm moderately sanguine about some reasonable approach to handle regressions that we can't substantiate with reasonable effort 20:24:09 once the beta is done and an official version is released by NVIDIA, should we update nvidia-experimental to the release version or leave it at whatever old beta driver it was on? 20:24:33 nvidia-NNN-experimental, no? 20:24:54 (or similar naming) 20:24:54 or nvidia-experimental-NNN 20:25:24 there doesn't seem much point in leaving it at a beta version for the sake of it, really 20:25:40 assuming that in general official > earlier-versioned-beta ... 20:26:02 why do we need both "-experimental" and "-NNN"? I thought -NNN would suffice? 20:26:05 cjwatson, so like if we have nvidia-experimental-123, and 123.11, 123.22, 123.33 are the beta version, with 123.44 being the official release, should we leave it to 123.33 or go to 123.44 (which would also presumably appear in nvidia-current-updates at some point) 20:26:42 is there a reason why people might want 123.33 not 123.44? 20:26:51 I think we should update betas to finals 20:27:05 chances are that some games need the fixes anyway? 20:27:15 yeah that's what I'm thinking... 20:27:17 Make nvidia-experimental-123 transitional and have it depend on nvidia-current-updates once the release is done. 20:27:27 and if we don't release beta->final to experimental due to caution, why would we do that for -updates? 20:27:40 right, I have trouble thinking of a reason why we wouldn't; although I wonder whether that should be done by depending on nvidia-current-updates (thus making it mean ">= 123") or freezing it at a particular 123 subversion 20:27:45 IYSWIM 20:27:46 ok great 20:28:21 so why do we need the "-experimental" suffix if we already have a -NNN? am I missing something? 20:28:41 I think we do need the -NNN for ensuring that upgrades always reset to the stable one 20:28:52 * bryceh ponders 20:29:05 I'm not fussed about -experimental if there's a warning saying as much 20:29:23 there is some messaging value to -experimental, for people who might not read the warning but would see the package name, however technically I don't see any reason to favor that over just -NNN 20:30:09 if it is -NNN then people may expect us to update it with post-release updates of the driver 20:30:25 whereas I'd sort of prefer to be done with the package once the beta is over 20:30:56 compare gcc-snapshot 20:31:05 different audience there of course 20:31:35 ok, if it's just for the warning effect (not for some dependency magic), I'm fine with that 20:33:02 pitti, fine with that being to keep -experimental or exclude it? 20:33:33 bryceh: with either really; I was mostly curious for what exactly we need the -experimental suffix 20:33:50 actually 20:34:00 it's helpful to have it for ubuntu-drivers-common 20:34:06 ok 20:34:17 it currently filters "experimental" on the package name to sort it last in the "recommended version" list 20:34:28 aha, good. 20:34:36 so, is there any remaining dissent here which we need to vote on, or do you think we're good to go on this? 20:34:41 so that it only ever installs that if no other version supports your card 20:35:17 do we have consent on the SRU verification? cjwatson's last mail sums it up pretty well IMHO 20:38:27 ScottK: does this discussion meet the concerns you expressed on the list - that is, weaken handling of hard-to-substantiate regressions (but don't ignore them entirely) for nvidia/fglrx packages where users have previously been warned about potential instability? 20:38:43 (which is about the best one-sentence summary I can come up with) 20:39:10 cjwatson: I'm concerned that if we make a special rule for unsubstantiated regressions for one package, it'll spread. 20:39:24 I'd much rather say for this one package, a certain degree of regression is OK. 20:40:33 It's a binary blob video driver, so we can't fix it anyway, it's optional, and video drivers very rarely are 100% improvement for alll hardware. 20:41:17 So you'd rather not include a rationale with the policy in case it's taken as a general example, basically? 20:41:25 I can live with that. 20:42:26 yeah, fine for me as well; if we say "this package will always be the latest beta driver", this states it's very reason of existance, and implicitly contains that it won't stop upgrading 20:43:19 Or "the latest beta driver in series NNN" or whatever. 20:43:31 I think I'm happy to leave that part up to the teams dealing with it. 20:44:37 this all sounds great :-) 20:48:42 OK, let's move on 20:48:54 #topic Scan the mailing list archive for anything we missed 20:49:28 Edubuntu Sponsorship Process 20:49:45 Has a couple of +1s although I concur with Mark's comment that this is more a matter for trademark@ 20:50:03 highvoltage: ^- if you feel this needs more, please follow up 20:50:19 Extension of term lengths - done 20:50:46 And I don't see anything else of any note 20:50:51 neither do I 20:50:58 the rest was handled by mail 20:51:02 transferring the kernel packageset 20:51:08 I didn't see any comment on that in my mail 20:51:12 admittedly it was tacked on to the end 20:51:13 community bugs, just the usual takes-ages-to-resolve 20:51:16 Laney: URL? 20:51:31 cjwatson: ah, it's been handled by mail, thanks 20:51:48 http://mid.gmane.org/20120827200048.GB14343@orangesquash.org.uk 20:51:50 if that works 20:51:51 (at least, I believe so) 20:52:43 Laney: well, we first need a way of actually doing that ;) 20:52:55 that'll be landed soon 20:53:00 if changing owner is a part of that branch 20:53:39 not sure what's in the branch, ideally we'd need to have the delete function mapped and make all the attributes read/write 20:53:45 so, if you could agree it then someone can JFDI when it becomes possible 20:53:56 if this is in that branch then great, otherwise SMOP 20:55:38 Makes sense to me for DMB to own the kernel set 20:56:00 Once possible 20:56:13 If it's urgent for some reason we could try to arrange for manual SQL, but I'd really rather not 20:56:45 nah, not urgent. I'll do any update the DMB needs to do to it as I have both DMB and TB hats. 20:56:55 OK 20:56:56 #topic AOB 20:57:02 anything else? we have three minutes 20:57:39 cjwatson, regarding the nvidia proposals, did the discussion above qualify as a vote or does a formal vote still need to be held? 20:58:05 AFAICT there was consensus and therefore no need for a vote 20:58:11 awesome, thanks. 20:58:20 *agree* 21:00:50 #endmeeting