17:59:59 #startmeeting FESCO (2012-03-05) 17:59:59 Meeting started Mon Mar 5 17:59:59 2012 UTC. The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:04 #meetingname fesco 18:00:04 The meeting name has been set to 'fesco' 18:00:12 #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 18:00:12 Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 18:00:12 #topic init process 18:00:16 hey, who's around? 18:00:16 * nirik is here. 18:00:31 hi 18:00:33 Hello 18:00:37 * sgallagh assumes incorporeal form on the wire to be here 18:00:54 Hi 18:01:01 hello. 18:01:06 hi 18:01:13 greets 18:01:47 hiya 18:01:52 * epienbro is here for the mingw subject 18:02:19 big crowd today 18:02:37 i missed the other meeting so making up with a different one :/ 18:02:39 * ktietz is here for the mingw subject, too 18:02:40 ok, let's get started 18:02:49 #topic #812 Mass rename request for all mingw32-* packages because of new packaging guidelines 18:02:55 .fesco 812 18:02:58 notting: #812 (Mass rename request for all mingw32-* packages because of new packaging guidelines) – FESCo - https://fedorahosted.org/fesco/ticket/812 18:03:29 so, my concern here is that it's really easy to screw up the Obsoletes/Provides... how can we check that they are good before just landing all these. 18:04:03 nirik: In the ticket, they claim it's not changing the Provides for 32-bit packages 18:04:04 obsoletes/provides aren't needed for this rename 18:04:12 * t8m has no problem with this mass change for Rawhide 18:04:15 let me come up with an example diff 18:04:19 It seems that FPC has been involved with the plan, is that so? 18:04:41 yeah, so if we don't need them, it might be ok. as long as we block the old ones at the same time. 18:04:43 http://svn.openftd.org/viewvc/Fedora%20Cross%20Compiler%20Framework/mingw-cppunit/mingw-cppunit.spec?r1=322&r2=543 18:04:45 It's questionable whether we want such change on F17 branch 18:06:12 seems like a lot of change post alpha/feature freeze. 18:06:56 we'd still have to block all the prior-named packages 18:07:05 * nirik nods. 18:07:15 well, we planned to perform this change earlier, but as we were waiting for rh legal to approve the use of the mingw-w64 toolchain in fedora we couldn't do this earlier 18:07:29 The "actual software" aspect seems easy enough (diff, automation, rpmdiff etc.), only the infrastructure might be a problem 18:07:43 epienbro: Is there a technical or political reason that it can't wait until F18 at this point? 18:07:44 we have also had a policy of no new packages without review, but this may be a corner case where it's ok. 18:08:08 sgallagh: Is there a technical or political reason why it couldn't go into F17 at this point? 0 code change. 18:08:10 i'm certainly fine for rawhide, and can be convinced that it's useful for f17 as it's all behind the scenes, it shouldn't be changing anything for users/developers 18:08:11 maybe you can rename all the mingw packages and create an alias with the old name? 18:08:32 VICODAN2: this is about renaming them. ;) 18:08:44 mitr: Technically, it's a massive set of changed packages post feature freeze 18:09:12 epienbro: dumb question - what do you intend to do in the buildsystem if one of our secondary arches is made primary? port the cross-compiler to that arch too? 18:09:19 mitr: Frankly, I'm on the fence, so I'm offering an opportunity to convince me 18:09:31 sgallagh, as we needed to wait for rh legal to give approval (for more than a year) it would be a shame if we would miss the f17 deadline..especially as everything has already been developed and tested in a separate repository 18:10:18 epienbro, this does not really look like a convincing technical argument 18:10:19 notting, in that case only a bootstrap has to be performed of gcc 18:10:36 nirik: I understand, the idea was to somehow keep backwards compatibility, I mean theoretically this "shouldnt" break anything but what could it break? 18:10:36 epienbro, although I can understand your point 18:10:51 well, technical argument for this rename is that 64-bit support can be added by it AFAIU 18:10:59 sgallagh: I guess I'm not worried about the code change at all (there is none, and we routinely assume that rebuilding one moth later is safe), I'm not really worried about the packaging (many eyeballs are already focusing on this), so all that is left from my POV is whether the infrastructure / package retirement process can accomodate it. 18:11:12 ktietz: Yes, but that sounds like a Feature coming in post-Feature Freeze to me. 18:11:17 So I need a little justification 18:11:28 mitr, yeah, that looks like reasonable argument 18:11:53 true 18:11:59 mitr: should be possible. Just create the 101 new packages, block the 101 old packages, let them import. For f17 the updates process may not be able to easily handle an update with 101 packages... so it would need to be split up or manually tagged into f17 18:12:07 I'm not trying to be obstructionist, just cautious :) 18:12:07 sgallagh, that's correct, we actually already prepared a feature page for mingw-w64 support: https://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler 18:12:24 nirik: eh, 101 packages most people don't have installed? 18:12:32 right. 18:12:40 well, from my point it would be good to start on F17 already with the mass-rename, as it leads for RHEL 7 from beginning to the proper naming schema. On the other hand, I can wait for this until F18, but it might be better for having it soon 18:12:47 nirik: would we even import? why not just copy the repos over? 18:12:59 but we didn't propose it at the feature submission deadline because of the pending legal issues I mentioned earlier and we weren't certain if the legal approval would arrive in time 18:13:24 notting: well, they still have to update and the spec would need renaming, and it seems odd to have the old history there on a new package, IMHO 18:14:17 notting: the old repo can be merged into the git history anyway 18:14:20 i'm sure the retirement process can handle it. blocking things is easy :) 18:14:40 ok, I guess I am +1 to both 17/rawhide. Provided releng doesn't yell. 18:14:52 (also for personal reasons I want this in as soon as possible.) 18:14:52 * nirik looks at dgilmore 18:15:20 I'm +1 Rawhide, +0 Fedora 17 18:15:43 I'm +1 to both 18:15:45 OK +1 for both F17 and Rawhide 18:15:55 I'm +1 to both 18:15:58 +1 to both if dgilmore is ok with rename 18:16:55 +1 to both from me 18:17:02 dgilmore: opinions? 18:17:07 nirik: I'd rather keep the old history FWIW; it's not like it's suddenly not true history or something. 18:17:21 +1 18:17:33 what is the question? 18:17:36 * nirik shrugs. I don't know that I care, just seems odd in a 'new' package. 18:17:47 lol 18:18:06 dgilmore: we are talking about blocking mingw32-* and making mingw-* and doing that in f17 and rawhide. 18:18:25 nirik: i would say rawhide only 18:18:33 why? 18:19:37 it's post feature freeze churn, but it seems like it would be reasonably safe 18:19:43 what we're really asking is: is there any technical problems releng would have with doign it for f17? 18:19:49 because its a big change way past feature freeze 18:19:57 pjones: who knows 18:19:59 it is merely a change in the name of the source package 18:20:19 does it involve changes in comps? 18:20:22 no. 18:20:23 andaconda? 18:20:25 no. 18:20:47 nirik's synopsis above really appears to be complete. 18:21:23 grep mingw32 comps-f17.xml.in |wc -l 18:21:24 34 18:21:38 i would think that really should all be changed 18:21:42 right, it doesn't change those 18:22:01 seriously we should at this point be slowing the curn way down. its really too late for f17 18:22:04 dgilmore, the comps file only contains binary packages right? the naming of binary packages doesn't change..only the source packages change 18:22:45 dgilmore: What you're being asked isn't whether you think it's a good idea. It's whether it will cause rel-eng (and *only* rel-eng) technical difficulties. 18:23:05 mjg59: thats unknown 18:23:17 Well if there's no known problems then let's do it 18:23:18 mjg59: i found out about it a monute or two ago 18:23:20 mjg59: well, "risk of technical difficulties" is interesting as well 18:23:32 mjg59: so i would say rather than tempt fate no 18:23:46 dgilmore: Yes, but that's not what you're being asked 18:24:01 mjg59: it may cause technical difficulties 18:24:15 But you're not aware of any specific cases in which it would? 18:24:17 dgilmore: any particular area, or just "too much change"? 18:24:17 it's a process we do now on an individual basis. not seeing why it would break when scripted 18:24:21 OK why not doing it in two steps? First doing rawhide as soon as possible. Then if there are no serious difficulties proceed with F17. 18:24:45 t8m: with a very short timeframe for determining if there were serious difficulties? like a day or two max? 18:24:46 mitr: its completely unknown what will. wont or may break. 18:25:02 t8m: looks reasonable 18:25:07 pjones, yep, 18:25:22 t8m: I could get behind that 18:25:25 dgilmore: so do it and find out? 18:25:26 notting: we do not ever rename git repos 18:25:40 drago01: not at this point of the release cycle 18:25:54 notting: we create new repos for renames 18:25:55 well, if they went and did re-review of the packages, then it would be allowed? 18:26:04 Renaming git repos is optional and if rel-eng objects to it it does not have to be done 18:26:09 we eol the old package aand block it in koji 18:26:15 and add the new packages 18:26:30 we don't want to rename. 18:26:32 So far what I'm continuing to hear is "There are no technical issues that would result from this" 18:26:39 While a package rename was requested, I think the most important part of the request was an exception from the re-review request. 18:26:41 mjg59: sounds like it. 18:26:50 nirik: the packages being re-reviewsed is the steps needed for a rename, we treat them as new packages 18:26:55 I'm +1 to going ahead with it, though I could be persuaded by t8m's plan. 18:27:00 mitr, I think the exception from rereview was clearly granted 18:27:05 It seems there's no controversy about the lack of re-review 18:27:11 I have no problem with it being briefly staged in rawhide 18:27:14 dgilmore: right. in this case they are asking us to skip the review part. 18:27:31 We probably should have voted on the re-review skip. +1 to it in my case 18:27:51 nirik: that should be a big fat no 18:28:15 well, the reason for re-review is to make sure obsoletes/provides is right. In this case there are none needed. 18:28:22 I don't think anybody on fesco is currently arguing that we should re-review. 18:28:40 dgilmore: You mean that the re-review bug is necessary as a part of the process, or that the human review is necessary? 18:28:56 mitr: both 18:28:57 * nirik nods. I'm ok with giving them a pass on re-review. The f17 thing is more up in the air. 18:29:24 dgilmore: Again, you're being asked a technical question, not a policy one. 18:30:04 proposal: no re-review, land in rawhide. Revisit next week about f17 status? 18:30:11 dgilmore: Policy-wise, fesco is fine with these packages not being re-reviewed. If there are technical reasons that this causes a problem for rel-eng then we'd love to hear about them. 18:30:17 So, if no renaming is done in infrastructure, and this is treated like an ordinary re-review with a bug filed, tickets etc., except that nobody will actually do a full re-review, is there any problem? 18:30:45 nirik: I'd rather approve this right now, and only require 1 non-broken compose in the mean time 18:31:08 non broken compose? 18:31:12 dgilmore: Would doing f18 and f17 separately double load on a person, or is new package import automated enough? 18:31:20 nirik: I'm okay with the people doing the work just moving ahead on f17 if nothing breaks in rawhide. 18:31:25 nirik: Well, what kind of a failure are we expecting really? 18:32:03 epienbro: are there any changes to the packages aside from the subpackage adding/spec file name? ie, are you also adding other changes? 18:32:10 mitr: the load on a person doing it for f17 and f18 would be the same as adding any other package 18:32:21 dgilmore: This is 101 packages 18:32:36 dgilmore: "do you care whether there are 101 or 202 tickets, or do you not care?" 18:32:52 mitr: There should only be 101 tickets 18:32:59 mitr: tbh, it would go through bugzilla and wouldn't hit releng until the old packages needed blocked 18:33:00 mitr: adding the repos on the server is scripted 18:33:03 sgallagh: Not if f17 is done several days later 18:33:11 dgilmore: thanks 18:33:25 really, it would be one ticket. "plz block these 101 packages" 18:33:26 * nirik notes there should be 1 ticket really. 18:33:30 mitr: the script is run, each package is checked for a complete review 18:33:46 and then acked or naked by the person doing the processing 18:33:46 nirik: JINX. 18:33:58 nirik, for now, the only things we plan to do are to bootstrap the win64 compiler and to perform the package renames (which we expect to complete this week)..after that we can port the individual packages to the new mingw packaging guidelines (thus adding win64 support), but this isn't time limited 18:34:04 nirik: there cant be one ticket 18:34:27 nirik: the scripts to process new git branches expect one package per bug report 18:34:43 epienbro: the packaging guildeines update would be F18 only? 18:34:51 but there should be 1 ticket to block the old ones 18:34:56 dgilmore: yes, if we require a bugzilla bug for each rename. 18:35:29 mitr, well they can be enabled from f17 on as all the pieces are already in place (all rpm macros are backwards compatible) 18:36:02 dgilmore, cannot this be handled with a different script automatically, not requiring bugzilla for each package? 18:36:03 epienbro: I'm fine with doing the rename for f17; larger changes in f17 are... something to discuss separately? 18:36:13 t8m: Why bother? Let epienbro write a bugzilla script. 18:36:23 mitr, OK that's another possibility 18:36:35 is this boiling down to "is someone from releng volunteering to do the work of handling the request? 18:36:36 I'm okay with that 18:37:04 t8m: no. we dont have anything like that because thats not how things are done 18:37:08 notting: I think we've covered most known ways why this couldn't work, and it seems to me that it could work after all. 18:37:39 so where are we here? 18:38:13 So, proposal: 1) manual re-review is not required for this rename; 2) if the rename happens in f18 and doesn't break a compose or anything else, 2 days later the rename can be done in f17 18:38:16 epienbro, OK I suppose you'll have to create all the bugzillas with some script. I suppose that you can grant the review flag automatically by another script run with mentioning the FESCo grant 18:38:47 mitr: nothing prevents #2 from being done in any case. 18:38:49 t8m, sure, I can give that a shot 18:39:10 Oh, and 3) rel-eng is not asked to create special processes for thi 18:39:20 this 18:39:51 epienbro: Would that work for you? 18:40:05 the one problem is the bodhi update for f17... but I suppose you could break them into 10-20 package chunks 18:40:23 nirik: i have created an update with over 100 packages before 18:40:32 mitr, I'm okay with that 18:40:34 but thats about its limit 18:40:39 dgilmore: and it worked? cool. 18:40:42 The longer this discussion goes on, the more I'm inclined to vote -1 for F17 18:40:59 But I'm sure I'm going to be outvoted. 18:41:05 i'm still +1 to doing this for both 18:41:09 sgallagh: why? even dgilmore seems to be saying it should work. 18:41:24 (though he clearly dislikes the idea) 18:41:35 pjones: it shoudl work, will it break things who knows 18:41:46 dgilmore: Well, ideally rel-eng would know 18:41:51 I'm undecided, slightly negative, on adding win64 support in f17, but that's something else. 18:42:18 * nirik is fine with the above proposal. (note that item 1 really isn't the case anymore if we are filing bugs and having someone approve the reviews)... but sure. 18:42:23 mjg59: without looking at it in detail and doing some testing we dont know, we can only speculate 18:42:24 pjones: We've gotten to "it should work" by walking through a half-dozen things that could each fall apart. 18:42:24 mitr: agreed. 18:42:30 This doesn't engender confidence in me. 18:42:37 dgilmore: Informed speculation is useful 18:42:49 mjg59: and i cant look at it in detail when ive only known about it for the length of this discussion 18:42:57 dgilmore: you don't have your tarot cards handy? or is that crystal ball? 18:42:59 sgallagh: sounds the only way to arrive at any conclusion to me... 18:43:06 nirik, note that the review approval would be just formal flag in BZ not a real review 18:43:14 we are discussing simple rename for 40 minutes, so it's not so easy as it looked like 18:43:21 dgilmore: So a deferral by a week would be useful? 18:43:25 t8m: sure, but it could also be a quick look over of the diff. Anyway. 18:43:27 nirik: its a magic fairy these days ;) 18:43:28 Does it make sense within the schedule? 18:43:30 nirik, just so that releng scripts would work 18:43:36 yeah, I think we're way past our 15 minutes on this. Can we just vote on mitr's proposal and move on? 18:43:45 +1 to jfdi 18:43:48 +1 to mitr's proposal, move on. 18:43:52 +1 as well 18:43:55 nirik, but normally a re-review should be a full rereview with running rpmlint etc 18:43:58 +1 18:43:58 mmaslano: well the only difference to a "normal" rename is 1) no reviews 2) lots of packages 18:44:07 TC1 for beta is due today 18:44:10 obviously mitr is +1 for it, right? that's 5. 18:44:11 or tomorrow 18:44:12 +1 to both mitr's proposal and moving on 18:44:18 6 18:44:28 I remain -1 to F17, but +1 for 1) and 2) of mitr's proposal 18:44:32 1) shouldn't be a problem due to fesco's ack 2) well if ti works for single packages there is no reason it can't work for 2, 10 or 1000 18:44:49 Yes, I'm +1; I don't think deferral is reasonable, given that we are 15 days before beta change deadline 18:45:00 #agreed rename w/o re-review will be done in rawhide and merged for f17 if there are no problems 18:45:04 dgilmore: if it doesn't make TC1, that's fine. 18:45:18 next topic... 18:45:22 #topic #815 abrt bugzilla deduplicator 18:45:26 .fesco 815 18:45:28 notting: #815 (abrt bugzilla deduplicator) – FESCo - https://fedorahosted.org/fesco/ticket/815 18:45:36 thank you for the approval! 18:45:44 this probably should have been a requirement for deploying abrt in the first place. 18:45:55 this was more or less approved in the ticket. mentioning here for completeness. 18:46:08 any comments before we move on? strenuous objections? 18:46:11 pjones: yeah 18:46:25 pjones: If we waited for a project to complete every feature, we'd never ship anything 18:46:26 they need to file a infra ticket to get the account setup with perms, etc 18:46:36 but hope it closes a ton of bugs. ;) 18:46:39 Yeah I'm +1 for this 18:46:48 * sgallagh was +1 in the ticket and remains so here 18:46:57 +1 in the ticket 18:47:02 * t8m as well 18:47:05 +1 in the ticket, for the record 18:47:13 sgallagh: dude, quit it with the useless aphorisms. I'm not making any assertion anything like "we should wait for every project to complete every feature". 18:47:20 sgallagh: that's not about being complete but avoid useless noise and thus save maintainers times (and keep there mailboxes sane ;) ) 18:47:30 #agreed abrt bugzilla deduplicator is approved. go forth and do it 18:47:35 moving on 18:47:38 #topic FES tickets 18:47:40 any news? 18:47:50 nope. 18:48:03 I can try and find someone to run things... but haven't yet. 18:48:03 ok 18:48:26 #topic Open Floor 18:48:29 i've got one item 18:48:45 notting: there was also a late ticket if we want to look at it 18:48:46 #topic #609 Live CD's and Install Media's arch inconsistent 18:48:53 .fesco 609 18:48:53 ah yes. 18:48:54 notting: #609 (F16Feature: Boost 1.47 - http://fedoraproject.org/wiki/Features/F16Boost147) – FESCo - https://fedorahosted.org/fesco/ticket/609 18:49:05 whoops 18:49:06 thats a rel-eng ticket? 18:49:08 #undo 18:49:08 Removing item from minutes: 18:49:10 .fesco 602 18:49:14 notting: #602 (meeting topic: Live CD's and Install Media's arch inconsistent) – FESCo - https://fedorahosted.org/fesco/ticket/602 18:49:38 fesco approved changing the live media. this got dropped for a while, moved to releng last week 18:49:41 yeah, we wanted to do this a while back and it got dropped on the floor. ;( 18:50:04 the releng ticket was closed->wontfix 18:50:19 with a suggestion to re-evaluate for f18 18:50:51 * nirik is fine with doing this for f18, but perhaps we should have a ticket or other note to actually do it? 18:51:15 agreed. releng ticket? fesco ticket? Feature? 18:51:24 can't we just call it x86 18:51:30 makes more sense 18:51:33 We could paint it blue, too 18:51:34 but well 18:51:42 But it's going to be called i386 18:51:46 mjg59: or chromakey green? 18:52:02 then whoever's looking at it can just pick what they want it to look like 18:52:11 (We're talking about our rusty old bikeshed, right?) 18:52:32 pjones: Don't they use magenta for chromakey nowadays? 18:52:34 notting: not sure. rel-eng might make most sense, but how can we keep it from being forgotten there too. 18:52:46 We could reopen the ticket? 18:52:56 sgallagh: paint available at b&h would suggest not. 18:53:05 * nirik wonders if by the time we remember to do this we just retire 32bit. ;) 18:53:13 nirik: +1 18:53:18 Proposal: Retire 32-bit for Fedora 18 18:53:26 * mitr notes that there are 5 fesco tickets that seem to have fell through the cracks; can we... not spend 10 minutes joking instead? 18:53:27 ha 18:53:39 (Thank you for giving me a segue to make that suggestion. I've been sitting on it for months) 18:53:45 proposal: re-open releng ticket, target f18? 18:53:49 +1 18:53:53 sure, +1 18:53:54 nirik: +1 18:53:59 I wasn't actually joking about the retirement 18:54:03 But yes, +1 to nirik 18:54:18 sgallagh: do you have numbers how many i686 were downloaded? 18:54:24 We probably can't retire 32-bit userspace 18:54:34 So while we could retire 32-bit install media, it doesn't seem like a huge win 18:54:37 nirik, +1 18:54:44 -1 , for OLPC if nothing else 18:55:12 notting: -1 on re-opening the ticket? ;-) 18:55:15 proposal: reopen the rel-eng ticket to target f18. check back later. 18:55:20 whoops 18:55:32 too many proposals in flight :) 18:55:35 +1 18:55:37 OLPC can get its own secondary arch :) 18:55:39 Seems like 5 for that, then 18:55:47 #agreed reopen rel-eng ticket, target f-18 18:55:54 rel-eng wants i686 instead of i386; I assume this is entirely up to rel-eng? If so, +1 to filing for f18 18:56:12 Seriously, though, is it such a bad idea to kill off a decade-old architecture at this point? 18:56:23 sgallagh: Yes 18:56:34 sgallagh: There's still plenty of 32-bit only binary code in use 18:56:34 3 decades old, and it seems to actually be used quite a bit. 18:56:38 * nirik thinks it's another discussion, feel free to bring it up next week with rationale? 18:56:47 nirik: agreed. 18:56:50 I'll do so 18:56:53 #topic Open Floor 18:57:09 I meant decade-old since it was reasonably replaced by x86_64 18:57:10 there's a late-breaking fesco ticket on security policy & polkit configuration. want to discuss now, or move to next week? 18:57:12 There was somthing brought up on -devel re: security 18:57:18 Ah yeah that 18:57:36 notting: I'd like to see the folks who made that decision weigh in on the ticket, then discuss next week after we have their input... 18:57:41 do we know who that would be? 18:57:53 hello, thanks for adding the item to the agenda -- but as always, please scrutinize what I'm saying, as I'm running a few degrees of fever (not joking) 18:58:11 it can wait until next week, of course -- just a minor insecurity 18:58:23 * vallor is Scott Doty -- hello 18:58:43 ok 18:58:56 #agreed defer #816 to next week 18:58:58 I'm actually not sure this is really FESCo bussiness at all - I do not think there is real conflict for FESCo to resolve here 18:59:13 My POV: 1) Linux is still supposed to be a multi-user system; blindly removing authentication is unacceptable 2) having things easier (perhaps much easier) for "wheel" (and presumably "wheel" being used on single-user machines) is fine 3) improvements in UI, workflows etc. within the boundaries of 1) are always welcome, but not really a FESCo matter. 18:59:34 mitr, +1 18:59:46 t8m: it's a request for review of asking for passwords for routine sysadmin tasks 18:59:55 the bug on -devel is just an example 19:00:09 vallor: What are you asking FESCo to do exactly? 19:00:09 sometimes, asking for a password makes the situation less secure 19:00:31 t8m: ask the security SIG to review packages for this problem 19:00:34 well, I think there's a conflict between what some people want and what maintainers have decided. perhaps we can mediate and come up with a solution, or perhaps some rationale would make us want to ask them to change. 19:00:39 t8m: or whoever would do the review 19:00:40 vallor: "root password could be captured, so let's just do it without authenticating as root" is a really bad tradeoff 19:01:00 * nirik notes there's not any kind of active security sig. 19:01:05 can we take this to the list, please? 19:01:16 there is a security@ list, but that's more of an incident response 19:01:27 nirik: There's a new security group at Red Hat run by Josh Bressers that is becoming more active 19:01:32 I'd suggest starting there 19:01:45 That's application security rather than CVE response 19:01:51 sgallagh: sure... but thats not really fedora specific. I'd be happy for that group to weigh in tho 19:01:56 proposal: close ticket, pending a specific proposal/question; let's discuss on fedora-devel for now 19:02:04 mitr: +1 19:02:17 nirik: Right, I meant to direct that at vallor 19:02:17 the proposal was to review, not the ticket 19:02:19 but okay 19:02:20 proposal: leave ticket, gather more info and visit next week when we have had time to review it. 19:02:38 +1 to nirik . when i said 'take this to the list', i meant the current in-channel discussion :) 19:03:04 nirik: what kind of info? 19:03:10 mitr: meet me over in #fedora-qa pls? :) 19:03:32 anything else for open floor? 19:03:37 mitr: rationale on how desktop folks set auth needed and which auth? 19:03:44 #800, #05, #808, #811 19:03:55 notting: ^^^ 19:04:03 #05? 19:04:04 the second one is #805 19:04:06 ah 19:04:51 In particular #805 applies to F17 and seems to need a decision, the others can be deferred easier I think 19:04:59 .fesco 805 19:05:01 nirik: #805 (Freeze break request for firewalld) – FESCo - https://fedorahosted.org/fesco/ticket/805 19:05:23 #topic #805 Freeze break request for firewalld 19:05:53 mitr: honestly 808 and 811 can likely be closed 19:05:56 but to this ticket... 19:06:25 I discussed #805 with qa and rel-eng. It didnt have Test Day yet 19:06:43 The ticket says March 15 19:07:20 great 19:08:02 so, the options are: 19:08:09 - postpone any decision until after test day 19:08:21 - allow inclusion if successful test day 19:08:26 - not allow inclusion at all 19:08:26 ? 19:08:31 The original ticket is +1-5 if I count correctly 19:08:50 Do we have any idea how many users test alpha vs. beta? 19:09:01 and the change being discussed is changing comps only? 19:09:17 mitr: many more test beta, 19:09:21 nirik: "only" changing the method the firewall is controlled 19:09:56 but we agreed on changing default to firewalld 19:09:59 or was that already enabled by default on alpha? 19:10:00 * nirik is -1 for f17 still... but f18 comps is open and ready for changes. ;) 19:10:05 the change in comps "only" switch it on 19:11:00 mitr: the issues is that the change was not made in comps prior to alpha 19:11:07 mitr: so by default its not enabled 19:11:52 my suggestion would be - if we think we can allow it based on a successful test day, we should be able to say so now. if we don't think we will allow it regardless of test day status, we can also say that now and close out the ticket. 19:12:02 notting: +1 19:12:33 so... proposal: allow switch of default firewall based on successful test day feedback 19:12:36 if we say it's ok with test day, we should note what "successful" test day means. ;) 19:12:52 Hm. On one hand, I'm not too worried about a comps change, and if alpha is not tested very widely, a pre-beta-freeze test day should be enough; on the other hand, if a pre-beta-freeze test day is a good enough substitue for alpha, why do we require features testable by alpha? 19:13:46 i think going down the rathole of the existing feature process is unlikely to add to this discussion 19:14:18 shall we vote? a) allow if test day goes well, b) ask to retarget for f18 ? 19:14:40 a/ +1, but how we define well 19:14:47 b) 19:14:49 b: +1 19:14:54 b) here as well. 19:15:12 a) for me. 19:15:22 mjg59: pjones: t8m: ? 19:15:25 nirik, a) +1 19:15:46 3 vs 3 19:17:14 sorry, got pulled away. lemme read some. 19:17:58 I'm +1 for "a" 19:18:10 mjg59's currently talking in a conference call, so I bet he's not paying attention. 19:19:02 hooray, limbo. 19:19:30