18:00:31 #startmeeting FESCO (2011-11-21) 18:00:31 Meeting started Mon Nov 21 18:00:31 2011 UTC. The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:34 #meetingname fesco 18:00:34 The meeting name has been set to 'fesco' 18:00:37 #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 18:00:37 Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 18:00:41 #topic init process 18:00:41 hi 18:00:45 * nirik is here. 18:00:49 Hello everyone 18:00:52 hello 18:00:55 hi again 18:00:57 pjones is on holiday this week 18:00:57 wonder if we will have quorum. ;) 18:01:09 I'm also simultaneously in #fedora-townhall 18:01:12 * cwickert is here 18:01:20 But given what we have today, that doesn't seem like a huge problem 18:01:38 Seems we have quorum. 18:01:41 We seem to have 6, at least 18:01:41 well, it could be a problem for mmaslano 18:01:41 Ok 18:01:54 I don't mind, tickets looks easy 18:01:55 #topic #667 Request to fix CRITPATH update process 18:01:55 .fesco 667 18:01:56 mjg59: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667 18:01:57 because she has to answer questions form candidates 18:02:03 cwickert: So do I :p 18:02:11 mjg59: ah, sorry I missed you 18:02:16 * sgallagh is here 18:03:47 lmacken, Hi, are you around? Is there going to be a bodhi change reflecting the change to CRITPATH process we agreed upon? 18:05:00 yeah, not much progress on this front... we have several things pending. 18:05:31 I saw the new bodhi update today - still without the change. 18:05:44 Well, we did defer it 18:05:53 So I don't think it's unreasonable that it didn't happen :) 18:06:19 which part? 18:06:35 we have a ticket open to allow people to push to stable after 2 weeks with no -karma. 18:06:38 I guess we waited for input from qa 18:06:51 we have open the idea of making proventesters not any different from testers. 18:07:35 t8m: I'm not aware of the changes that you agreed upon. Is there a patch? 18:07:48 lmacken: just a ticket. ;) let me dig it up. 18:07:54 lmacken, no patch but there is a ticke 18:08:07 https://fedorahosted.org/bodhi/ticket/642 18:08:26 nirik: thanks. 18:08:36 that shouldn't be too difficult of a tweak. I'll make sure it makes it into the next bodhi release. 18:08:44 lmacken, thanks 18:08:54 * nirik would say defer this again, hope for some discussion on proventesters. ;) 18:09:28 adamw: Anything new on this from your side? 18:13:11 Well, ok. Let's defer and poke proventesters. 18:13:15 Any objections? 18:14:02 wfm 18:14:06 * nirik nods. 18:14:14 Anyone want to volunteer to do that? 18:16:00 I can send an email to proventesters group with questions about it 18:16:18 Ok 18:16:50 #action mmaslano to follow up with proventesters to find out what they think about the proposal 18:17:09 #topic #692 Adjust FESCo election policy 18:17:09 .fesco 692 18:17:10 mjg59: #692 (Adjust FESCo election policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/692 18:17:28 A little more discussion of this on-list, but not a lot 18:17:38 #proposal Leave the policy as is. 18:18:16 +1, effectively what we're doing anyway 18:18:26 just to catch up: have there been any suggestions for adjustments? 18:18:27 * nirik shrugs. I'd be ok opening it to more groups, but there's not much easy way to do that, so sure... leave it as is for now. 18:18:51 I mean, QA as a group was not a good idea, but have we investigated other groups? 18:19:24 such as? proventesters seems to possibly be going away. 18:19:33 cla_done+1 didn't seem to get much support. ;( 18:19:38 and they are basically unbounded group 18:19:48 basically what I'd like to know is: Do all of you just want to stick with the current policy for a lack of alternatives or because you are convinced that it is right? 18:19:48 +1 Not broken, don't fix it. 18:21:03 qa would be fine for me, but they are not using any group, so I don't know how to handle it 18:21:10 I'm not convinced that packager is the right metric 18:21:13 cwickert: personally, I'd be ok with more inclusive, but in the end, even packager is pretty easy to get. ;) 18:21:24 Since we can easily have highly-technical people involved in Fedora who don't maintain anything 18:21:30 cwickert, I do not think the current policy is seriously broken and we do not have any formal process for becoming a 'real qa tester' (apart from signing papers). 18:21:44 #proposal - leave as is, but allow case by case exceptions 18:22:05 mjg59, that's too arbitrary 18:22:09 mjg59: and who is to grant the exceptions? 18:22:09 mjg59: An argument could be made that no matter how technical they are, if they aren't maintaining anything, they don't have a vested interest in the outcome of FESCo rulings 18:22:15 cwickert: i would be open to better alternatives, but i don't feel it's currently broken in a way that requires a rush to finding new alternatives 18:22:37 cwickert: fesco 18:22:47 sgallagh: Of course they do 18:22:47 mjg59: that smells fishy 18:22:53 * nirik doesn't like the exceptions thing. 18:23:11 * sgallagh remains +1 Not broken, don't fix it. 18:23:18 packager is easy enough to get into 18:23:19 Is a Fedora user who's an upstream maintainer less qualified to understand what we do than someone who maintains one shell script? 18:23:40 * notting is +1 to t8m's proposal, weak -1 to mjg59's - not clear enough 18:24:00 So yeah, I think the current situation is mildly broken 18:24:04 If they're the upstream maintainer and a Fedora user, there's a pretty high chance they're at least a comaintainer of their package 18:24:06 But I don't have a solid means of expressing it right now 18:24:09 sgallagh: Why? 18:24:15 * cwickert wonders what t8m's proposal was 18:24:20 * t8m is +1 to my proposal as well and if I count right that's +5 18:24:25 ah, leave as is 18:24:43 ok, it looks like people agree there is room for improvement 18:24:47 "exceptions" can be granted by a sponsor determining that someone has sufficient knowledge to be a member of the packager group and add them 18:25:04 nb: People should be added to packager if they're involved in packaging 18:25:08 oops only +4 18:25:16 #proposal: Don't change the policy and close the ticket for now. cwickert will reopen it if he has a better idea 18:25:25 cwickert: +1 :) 18:25:28 cwickert, surely +1 18:25:34 I think that basically comes down to close it 18:25:40 Sure, I guess for now 18:25:46 so count me as the 5th +1 18:25:48 ha. sure, +1.. I think it could be better, but don't know how. 18:25:54 So close for now, revisit if someone has other concrete proposals? 18:25:59 wfm 18:26:00 +1 18:26:05 mjg59, yeah 18:26:10 +1 18:26:23 mjg59: surely that is the default for 90% of the things we close, if not more 18:26:26 but yes, +1 18:28:33 #agreed No change for now 18:28:37 #topic #699 Proposal to remove the package "tzdata" from Critical Path 18:28:38 .fesco 699 18:28:49 mjg59: #699 (Proposal to remove the package "tzdata" from Critical Path) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/699 18:29:06 I can kind of see this. It's intrinsically volatile data with a low regression risk. 18:29:08 this is just another case of the 'not enough proventesters, so my package doesn't get approved in a timely manner' 18:29:23 nirik: Well, specifically it's one that *must* be approved in a timely manner 18:29:31 By definition :) 18:29:34 right, there's a deadline 18:29:57 i'm ok with this idea in concept, but it would be a bit of a PITA in execution 18:30:02 But there's an argument to be made that something like this with no "moving parts" as it were, doesn't belong in CRITPATH 18:30:09 (what notting said) 18:30:10 I am +1 to the proposal to remove it because I agree with the reasoning. 18:30:28 I think we should remove it. if we now discuss all the suggestiions for changing the critpath process, we'll open another can of worms 18:30:45 the problem is that critpath is defined & implemented as a dependency solved package set 18:30:45 +1 for removing it, it's not really critpath I think 18:30:47 notting, is the CRITPATH by dependency somehow hardcoded in the bodhi and there is no place to put exceptions? 18:30:53 +1 to removal 18:31:01 t8m: it comes form comps 18:31:09 s/from/from 18:31:26 glibc depends on it I think? 18:31:28 * nirik looks. 18:31:34 t8m: critpath is a list in bodhi. it is being changed to pull from pkgdb. pkgdb is fed from depedency solved lists of packages that are determined by comps 18:31:47 I'm +1 in theory, but it's going to be blocked by implementation 18:32:09 notting, couldn't tzdata be hardcoded as an exception somewhere? 18:32:12 t8m: so, 1) bodhi needs changed to pull from pkgdb 2) we can flip the bit in pkgdb to not include tzdata 3) we then need to somehow fix the dependency resolution to not keep switching it back on to critpath 18:32:17 We can't have a whitelist of exceptions to the dependency rule? 18:32:20 we'd need a whiltelist for packages that should not considered critpath even if they are dependencies 18:32:28 well once someone writes the *listing, sure.. 18:33:32 but first, we need the step 1 (fix bodhi to pull from pkgdb) 18:33:39 abadger1999: lmacken: do you know if that got done? 18:36:04 notting, I can't see how that's a dependency - why there couldn't be a simple/hackish whitelisting done in the current bodhi list? 18:36:25 t8m: we could do a one-off fix in bodhi, but that's still a one-off fix 18:37:38 * abadger1999 only knows that the patch was written, not if it went in/went into production. 18:37:49 I understand that but better a one-off fix than waiting for something that might not happen :) 18:38:02 Ok 18:38:11 proposal: find out status to see how feasable a change will be, revisit next week with more data. 18:38:15 nirik: +1 18:38:20 +! 18:38:35 +1 18:38:41 +1 18:38:42 +1 18:38:49 +1 18:38:51 not too happy +1 18:38:53 i'll do it 18:39:05 #action notting to find out how feasible this change is 18:39:11 Ok 18:39:20 Anything on engineering tickets? 18:40:02 we have features 18:40:17 I see 703 and 704 marked for meeting 18:40:34 They only got filed just before the meeting 18:40:37 ok 18:40:38 We can cover them if people want to 18:41:17 Any objections? 18:41:29 none from me 18:41:34 * nirik doesn't mind either way. 18:41:37 I don't care either way. 18:42:09 #topic #703 Boost 1.48 Uplift http://fedoraproject.org/wiki/Features/F17Boost148 18:42:13 .fesco 703 18:42:15 mjg59: #703 (F17 Feature: Boost 1.48 Uplift http://fedoraproject.org/wiki/Features/F17Boost148) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/703 18:42:17 +1 18:42:30 +! 18:42:33 * sgallagh gets out the rubber stamp like every release 18:42:35 gah, i keep doing that 18:42:43 +1 18:43:10 sure, +1... a bit more heads up would have been nice before it hit rawhide, but oh well. 18:43:15 when the feature policy is changed? +1 18:43:19 Ok 18:43:24 #approved 18:43:26 +1 (for the record) 18:43:29 +1, sure. hey upstream, can you, like, you know, stop breaking ABI? 18:43:46 #topic #704 BTRFS default file system https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs 18:43:53 .fesco 704 18:43:54 mjg59: #704 (F17 Feature: BTRFS default file system https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/704 18:44:10 +1 with same provisos as last time 18:44:20 If there's no decent checking tool then we defer 18:44:27 do we have one now? 18:44:28 will there be a btrfsck now? 18:44:31 +1 second verse, same as the first 18:44:37 there still isn't one that I know of. 18:44:43 but sure, try again... +1 18:44:44 +1 as with f16 18:44:49 +1 if there will be btrfsck 18:44:57 um same question as last time 18:44:58 There's actual evidence of its existence this time 18:44:59 +1 if there will be btrfsck 18:45:09 do they have fsck? 18:45:32 there still isn't one that I know of. There could be one before feature freeze. 18:45:40 there is something but not sure if it is usable yet 18:45:44 I'd like to see list of Q&A than 18:45:53 and review it again like in previous release 18:46:33 I'm +0 without input from the developers 18:46:42 (RE: fsck) 18:47:02 sgallagh: they are saying, 'real soon now' as they have been for a while. 18:47:03 #proposal Approve conditional on the existence of a working fsck by release time 18:47:17 not only fsck, there was more things 18:47:28 I'll put it into discussion section tomorrow 18:47:51 mjg59: How hard of a change is it to Anaconda to change the default back to ext4 if we have to? 18:48:02 sgallagh: A tiny number of lines 18:48:07 ok 18:48:19 I think we said: 'working fsck and no regressions from features we test/use in ext4' last time? 18:48:34 nirik: sounds good to me 18:49:08 I can back that 18:49:15 Ok 18:49:30 +1 18:49:33 #proposal Approve conditional on working fsck and no relevant feature regressions 18:49:44 sounds good 18:49:47 Definition on "relevant"? 18:49:49 * cwickert needs to leave now 18:50:41 well, if we revisit it before feature freeze, we could decide that? 18:50:51 I'd expect so 18:51:04 * nirik is +1 to mjg59's proposal 18:51:17 +1 18:51:23 +1 18:51:38 +1 18:52:23 * notting is +1 18:53:37 +1 18:55:36 #agreed btrfs approved conditional on working fsck and no relevant feature regressions. Will revisit before feature freeze to make sure. 18:55:53 #topic Next week's chair 18:57:24 Who wants to volunteer? 18:57:36 Also, from the US side, is anyone planning on being missing on Monday? 18:57:59 i may or may not be around 18:58:09 * nirik should be here. 18:59:28 i should be around for at least the first hour 18:59:45 Ok 18:59:48 Same as notting 18:59:49 Well then 18:59:55 Get volunteering 19:00:46 OK, I'll volunteer 19:01:09 t8m: Great 19:01:16 #agreed t8m to chair next week 19:01:23 #topic Open Floor 19:01:26 Anyone? 19:01:28 There was a discussion a few months ago about reconsidering when to shut off updates-testing by default (e.g. beta/rc/etc). It was deferred with "Will talk about disabling updates-testing for f17 cycle when we get to a f16 retrospective." 19:01:34 http://meetbot.fedoraproject.org/teams/fesco/fesco.2011-08-22-16.59.log.html#l-92 19:02:07 Is now the right time to bring that up? 19:02:28 gholms: Probably as good a time as any 19:02:31 gholms, I think why not? Will you open a meeting ticket for that discussion? 19:02:39 I can do that. 19:02:44 gholms, thanks 19:06:51 anything else? 19:07:32 I'll give it a couple of minutes and then close out 19:09:11 Ok 19:09:13 #endmeeting