18:01:17 <mmaslano> #startmeeting FESCO (2013-01-30) 18:01:17 <zodbot> Meeting started Wed Jan 30 18:01:17 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:22 <mmaslano> #meetingname fesco 18:01:22 <zodbot> The meeting name has been set to 'fesco' 18:01:29 <mmaslano> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:01:29 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:01:39 <mmaslano> #topic init process 18:01:39 <nirik> morning everyone. 18:01:55 <sgallagh> Good morning/afternoon/evening 18:01:57 <pjones> hello. 18:02:04 <law> morning 18:02:05 <mitr> Hello all 18:02:17 <t8m> hello 18:02:22 <mmaslano> evening everyone 18:02:39 <mmaslano> abadger1999: ? 18:03:09 * notting is here 18:03:14 <nirik> he's finishing up a FPC meeting I think 18:03:21 * abadger1999 here 18:03:25 <mmaslano> great 18:03:40 <mmaslano> #topic #1001 F19 Feature: JRuby 1.7 - https://fedoraproject.org/wiki/Features/JRuby_1.7 18:03:44 * abadger1999 finishing FPC meeting ... hoping to get to a vote on ruby draft there. 18:03:45 <mmaslano> .fesco 1001 18:03:47 <zodbot> mmaslano: #1001 (F19 Feature: JRuby 1.7 - https://fedoraproject.org/wiki/Features/JRuby_1.7) – FESCo - https://fedorahosted.org/fesco/ticket/1001 18:03:51 <mmaslano> abadger1999: yeah, please do so 18:04:07 * nirik is still +1 for these features provided the packaging guidelines are finalized. 18:04:28 <mitr> yeah, +1 if FPC acks it 18:04:32 <t8m> +1 18:04:38 <mmaslano> +1 18:04:40 <sgallagh> +1 assuming FPC ack 18:04:43 <pjones> likewise, +1 on that condition. 18:04:58 <notting> same here - +1 18:05:26 <sgallagh> If they nack it, shall we defer to next week? 18:05:28 * jwb is here 18:05:44 <nirik> we can always revisit 18:05:47 <sgallagh> ok 18:05:53 <mmaslano> #agreed JRuby 1.7 is F19 feature if FPC acks it (+7,-0) 18:05:58 <mmaslano> #topic #1002 F19 Feature: Ruby 2.0.0 - https://fedoraproject.org/wiki/Features/Ruby_2.0.0 18:06:04 <mmaslano> .fesco 1002 18:06:06 <zodbot> mmaslano: #1002 (F19 Feature: Ruby 2.0.0 - https://fedoraproject.org/wiki/Features/Ruby_2.0.0) – FESCo - https://fedorahosted.org/fesco/ticket/1002 18:06:08 <mmaslano> same as previous feature? 18:06:09 <nirik> same here. 18:06:13 <mitr> Same here 18:06:19 <t8m> +1 18:06:30 <abadger1999> +1 18:06:45 <mmaslano> #agreed Ruby 2.0 is F19 feature if FPC acks it (+5,-0) 18:06:46 <jwb> sure +! 18:06:48 <sgallagh> +1 18:06:48 <jwb> er, +1 18:07:03 <mmaslano> #undo 18:07:03 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x4c773d50> 18:07:11 <pjones> yeah, +1 18:07:19 * abadger1999 +1 on both the ruby features. 18:07:45 <mmaslano> #agreed Ruby 2.0 is F19 feature if FPC acks it (+7,-0) 18:07:55 <mmaslano> and new business... 18:08:05 <mmaslano> #topic #1004 Mass rebuild schedule 18:08:09 <mmaslano> .fesco 1004 18:08:11 <zodbot> mmaslano: #1004 (Mass rebuild schedule) – FESCo - https://fedorahosted.org/fesco/ticket/1004 18:08:32 <nirik> so, lets wait and do this and schedule at the end? 18:08:39 <jwb> yeah 18:08:40 <nirik> or do we want to do it now? 18:08:40 <pjones> yeah 18:08:51 <sgallagh> Let's wait until the end 18:08:59 <mitr> Are there any existing or proposed features that would impact the mass rebuild? 18:09:00 <t8m> Yep 18:09:01 * jreznik is around for scheduling... 18:09:17 <jreznik> mitr: glibc guys wants to coordinate with gcc mass rebuild 18:09:19 <notting> ruby implies a mass rebuild 18:09:36 <notting> (of ruby thigns) 18:09:39 <mmaslano> notting: in their own branch, but they need to think about mass rebuild to 18:09:41 <nirik> also, for the en mass stuff, could we just all say which ones we want to discuss and any not in that list pass? (but whatever way people want to do it that works is ok) 18:09:45 <law> glibc? 18:09:48 <nirik> notting: they wanted a side tag 18:10:03 <mmaslano> so let's move the mass rebuild at the end of meeting 18:10:05 <mmaslano> shall we? 18:10:13 <notting> nirik: mmaslano: right, but we would need to coordinate so we don't land mixes from both the mass rebuild and the side branch 18:10:14 <pjones> seems like it's easier to do it first 18:10:20 <mmaslano> notting: yes, tricky 18:10:27 <nirik> yeah. 18:10:37 <pjones> and then discuss non-en-mass stuff as well as stuff we want to remove from that group. 18:11:15 * nirik would like to discuss/vote on: FedoraUpgrade, SystemdPredictableNetworkInterfaceNames, FirstClassCloudImages. I'm fine with everything else today AFAICT. 18:12:02 <pjones> I'm fine with everything that was proposed for en mass except FirstClassCloudImages 18:12:18 <jwb> i'd like to discuss what nirik has, plus mariadb 18:12:20 <mmaslano> ok, move on to discussed features on list 18:12:21 <sgallagh> I'm also still not certain Shared System Certificates is actually achievable, but I'm in favor of acking it in the hopes it actually works. 18:12:27 <mmaslano> #topic #1006 F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB 18:12:34 <mmaslano> .fesco 1006 18:12:35 <zodbot> mmaslano: #1006 (F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB) – FESCo - https://fedorahosted.org/fesco/ticket/1006 18:12:38 <pjones> mmaslano: I thought we just said we didn't want to do that. 18:12:44 <pjones> at least I just said that and others seemed to agree. 18:12:51 <mmaslano> okay 18:13:03 <nirik> well, jwb wanted to discuss this one. 18:13:13 <t8m> pjones, jwb did 18:13:18 <abadger1999> Do we have a list of the features to potentially do en masse? /me saw jreznick commenting on the trac tickets to that effect. 18:13:25 <mitr> I have marked the ones I want to discuss in the tickets, so I have nothing to add now 18:13:29 <mmaslano> yes, I created a ticket 18:13:30 <nirik> ie, it should be: Accept unless at least 1 fesco member would like further discussion. 18:13:31 <mmaslano> it's in agenda 18:13:32 <pjones> nirik: well, yes, but I thought we were going to get the en mass stuff out of the way *before* discussing it, and he's suggesting it as one of the ones we can't remark on en mass. 18:13:32 <sgallagh> abadger1999: It's in the Schedule email 18:13:35 <t8m> abadger1999, it's in the meeting schedule mail 18:13:38 <mattdm> https://fedorahosted.org/fesco/ticket/1025 18:13:57 <jwb> pjones, right. i don't care when we talk about it, just that we at least briefly talk about it 18:14:10 <notting> i'm fine with everything in the 1025 ticket except would like to discuss the cloud images a bit 18:14:10 * nirik realizes we don't have process set for this, but we should do so to avoid confusion. 18:14:30 <pjones> nirik: right. That's why I'm suggesting process ;) 18:14:50 <t8m> pjones, I think it would be more clear to do it the other way 18:14:52 <pjones> so I think the process should be: 1) we identify what we can't vote on en mass, 2) we vote en mass for that which we can, then 3) we discuss the rest individually 18:15:03 <nirik> pjones: sure, fine with me. 18:15:08 <t8m> pjones, that is to switch 2) and 3) 18:15:15 <sgallagh> Isn't leaving something in the en masse block a tacit approval? 18:15:25 * nirik doesn't care which order. the bikeshed is built in 18:15:29 <mmaslano> pjones: great, so which are en mass ;-) 18:15:34 <pjones> sgallagh: well, yes. 1 and 2 are really the same thing, which is why I put them in that order. 18:15:36 <mitr> sgallagh: modulo technicalities of quorum 18:15:41 <pjones> mmaslano: the ones people just said they'd like to talk about. 18:15:57 * nirik is fine with approving everything in 1025 except FirstClassCloudImages. 18:16:08 <alorenzi> good evening :) 18:16:11 * pjones is also fine with everything in 1025 except FirstClassCloudImages 18:16:27 <pjones> (and I think the stuff not in 1025 obviously needs discussion) 18:16:29 <sgallagh> As I said above, I'm wary of the Shared Certificate plan, since it involves changing three crypto libraries in a significant way 18:16:42 <t8m> sgallagh, not much in the first step 18:16:45 <pjones> alright, so we should pull that out and discuss it separately as well. 18:16:46 <nirik> sgallagh: do you want further discussion on it? 18:16:54 <mitr> mmaslano: OK, please pull shared system certs out 18:16:54 <t8m> sgallagh, which is the target of the feature for F19 afaik 18:17:04 <mitr> let's not mix discussion and meta-discussion please 18:17:05 <nirik> so, perhaps we go back to the /topic then? 18:17:11 <nirik> if we are done with meta? 18:17:16 <sgallagh> yes, let's table that until we get there 18:18:14 <pjones> so it looks like things not listed in 1025, FirstClassCloudImages, and SharedCertificates need discussion, and we're okay with everything else in 1025? 18:18:19 <mmaslano> my proposal was: ack all features except those mentioned in discussion - FedoraUpgrade, SystemdPredictableNetworkInterfaceNames, FirstClassCloudImages, Shared System Certificates 18:18:27 <mmaslano> you mentioned all these in discussion 18:18:43 <mitr> We're getting in circles. 18:18:57 <mitr> mmaslano: please pick a topic (or reaffirm #1006) 18:19:01 <sgallagh> Hmm, I forget; didn't the discussion on the list for syslinux imply that most people didn't want it? 18:19:10 <sgallagh> Or did I miss a shift in the consensus? 18:19:15 <mmaslano> #undo 18:19:15 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0xd5ccad0> 18:19:15 * nirik sighs. 18:19:16 * abadger1999 notes fpc just ended -- guidelines for nodejs and ruby approved but with some action items for fesco before they go live. Hope we can get to those at the end of the meeting. 18:19:28 <nirik> pjones: yes 18:19:30 <mattdm> sgallagh: I certainly didn't see it that way. I got mostly a positive sense. 18:19:30 <nirik> mmaslano: yes 18:19:56 <t8m> sgallagh, I think most concerns were cleared up 18:20:00 <mmaslano> #topic #1025 En bloc features for January 30 18:20:05 <mmaslano> .fesco 1025 18:20:05 <pjones> sgallagh: there were some questions about how the anaconda guys who have to deal with it (i.e. me) felt. I feel fine about it. 18:20:06 <zodbot> mmaslano: #1025 (En bloc features for January 30) – FESCo - https://fedorahosted.org/fesco/ticket/1025 18:20:20 <sgallagh> t8m: right sorry. The agreement seems to be "as long as QE isn't responsible for testing it" 18:20:27 <notting> Proposal: accept all items from #1025 except FirstClassCloudImages and SharedSystemCertificates which shall be discussed separately 18:20:28 <nirik> proposal: approve all except FirstClassCloudImages, and SharedCertificates (which need more discssion to follow) 18:20:31 <nirik> notting: +1 18:20:38 <notting> nirik: jinx! 18:20:40 <sgallagh> notting: +1 18:20:42 <pjones> +1 18:20:44 <t8m> nirik, +1 18:20:45 <mitr> +1 18:20:47 <abadger1999> +1 18:20:54 <t8m> or notting, +1 :D 18:20:55 <mmaslano> +1 18:20:56 * notting is +1, obvs 18:21:26 <jwb> +1 18:21:48 <mmaslano> #agreed All features from #1025 will be accepted as F19 features execpt FirstClassCloudImages and SharedSystemCertificates which shall be discussed separately (+9,0) 18:22:09 <mmaslano> #topic #1008 F19 Feature: First-Class Cloud Images - https://fedoraproject.org/wiki/Features/FirstClassCloudImages 18:22:14 <mmaslano> .fesco #1008 18:22:14 <zodbot> mmaslano: Error: '#1008' is not a valid integer. 18:22:27 <mmaslano> .fesco 1008 18:22:29 <zodbot> mmaslano: #1008 (F19 Feature: First-Class Cloud Images - https://fedoraproject.org/wiki/Features/FirstClassCloudImages) – FESCo - https://fedorahosted.org/fesco/ticket/1008 18:22:46 <nirik> ok, I am basically fine with this as long as we get releng to ack that they can do it. ;) 18:22:58 * nirik thinks dgilmore is not around right now 18:23:19 <mattdm> it would also be nice if jgreguske were as well. 18:23:25 <mitr> Do we need to block the decision on legal, or leave this up to mattdm? 18:23:27 <notting> that's my issue too - there's not insignificant rel-eng work that would be needed for this 18:23:38 <notting> legal? /me missed that bit 18:23:44 <mattdm> mitr: what's the legal concern? 18:23:56 <abadger1999> I think legal was a different one. 18:23:57 <mitr> mattdm: Amazon images were a concern from what I've heard at FUDCon 18:24:04 <pjones> I asked dgilmore about this earlier, and while I was at lunch he said "<dgilmore> i have that on my list of things to do " 18:24:10 <mattdm> that's a different concern re amazon marketplace. 18:24:10 * nirik isn't sure how this is a legal issue 18:24:18 <mattdm> the legal concern. 18:24:23 <pjones> which really didn't clear anything up for me, because I don't know if commenting on it is on his todo or doing the thing is on his todo. 18:24:23 <sgallagh> Yeah, I'm trying to remember the detail there, but I think there are contracts that need to be signed. 18:24:31 <nirik> so, proposal: defer and get more rel-eng feedback 18:24:36 <mattdm> Not related to this feature. 18:24:55 <mitr> mattdm: ok, sorry about the confusion 18:24:58 <mattdm> dgilmore has made clear that his concern is about the possibility of oz/imagefactory running outside of a chroot 18:25:08 <jwb> mitr, i think the amazon thing was having them as a choice in EC2 itself, not just creating image 18:25:16 <notting> potential legal issue is if we spin updated images how we track what goes into them from a source distribution perspective 18:25:18 <t8m> nirik, +1 18:25:28 <mitr> jwb: "The EC2 images will be automatically uploaded and registered in EC2. The Final AMIs for Fedora 19 will be available in the Amazon marketplace. " is in the feature 18:25:36 <sgallagh> mattdm: Really sorry about the fuzzy memory, but someone was telling me on the bus at FUDCon that the reason Amazon isn't hosting newer images than Fedora 7 is that there was a legal blocking issue. I don't recall what it was. 18:25:47 * jgreguske was summoned by mattdm 18:25:47 <sgallagh> I'm sure legal@fp.org would know 18:25:48 <mattdm> oh, is the marketplace in there? that might be hopeful thinking. 18:26:04 <mattdm> the images will defintely be availabe in ec2. 18:26:16 <mattdm> the legal issue is with amazon's new "app store" for images 18:26:26 <mattdm> right now they can be found from our page or with searching 18:26:38 <mattdm> having them in the marketplace would be better visibility 18:26:40 <mitr> I'm fine with just highlighting the issue and letting mattdm decide whether it can be handled or whether to reduce the scope of the feature, fwiw 18:26:50 * nirik too 18:26:53 <mattdm> but requires signing something legal was not okay with 18:27:02 <abadger1999> mitr: +1 18:27:28 <mattdm> the core of the feature is to produce the images in a better, systematic way 18:27:29 <abadger1999> So... +1 to defer for releng ack. 18:27:40 <mitr> +1 to defer for rel-eng 18:27:56 <sgallagh> Proposal: Ack if and only if releng can commit to their part 18:28:14 <notting> the contingency plan if they don't is a little vague 18:28:17 <sgallagh> (Avoid the need to circle back around if rel-eng is in favor) 18:28:19 <mmaslano> sgallagh: +1 18:28:29 <notting> mattdm: are you suggesting we update koji and push images into it that are built outside of koji? 18:29:02 <mattdm> notting: no, skip koji entirely. i am really not happy with that as a fallback but I see no other option 18:29:29 <mitr> notting: if releng doesn't ack it, mattdm can either drop it or re-propose modified 18:29:38 <mattdm> "rel-eng" is nirik, notting, and dgilmore, right? 18:29:53 <jwb> mostly dgilmore and nirik 18:29:58 <nirik> well, a few other folks do things from time to time, but yeah 18:30:08 <notting> kind of. i'm in the group, but the amount of time i have for rel-eng coding is essentially nil 18:31:09 <nirik> dgilmore does the vast majority of it... so I would def like to have his input. 18:31:21 <notting> which reminds me... need to start the orphan process 18:31:22 <mattdm> I have talked with him about it at some length. 18:31:44 <nirik> mattdm: and he's ok in general? or ? 18:31:49 <mattdm> His primary (and strongly-put) objection is that the proposal includes the possibility of building the images in koji with oz running on the host 18:31:55 <mattdm> instead of in a chroot 18:32:14 <t8m> can we please defer and move on? 18:32:21 <nirik> mattdm: icky. 18:32:21 <notting> sure, +1 to defer 18:32:22 <sgallagh> mattdm: Quick definition of oz? Is it an image creation tool? 18:32:29 <mattdm> I, imcleod, and, jgreguske disagree that that's an insurmountable problem 18:32:38 <mattdm> sgallagh: yes. image creation tool which uses virt and anaconda 18:32:50 <mattdm> it is a cousin to livemedia-creator 18:32:52 <nirik> koji isn't really setup to use virt 18:32:55 <jgreguske> appliance-tools is what we use now to build images. It is a dead project 18:32:57 <mmaslano> +1 to defer 18:32:59 <sgallagh> Ick, I don't like that on the koji hosts... 18:33:02 <nirik> and many of our image tools seem to be heading to only using viryt 18:33:11 <jgreguske> the other options are oz and livemedia-creator which both use virt 18:33:13 <nirik> which seems bad 18:33:17 <mattdm> there are two bare-metal builders which can be used 18:33:25 <mattdm> in the future, virt-on-virt will make that less of a problem 18:33:34 <mattdm> (and it's not a terribly far off future) 18:33:51 <jgreguske> upstream koji will be moving to using virt as well 18:33:57 <sgallagh> mattdm: Is this something that we could do by repurposing COPRs? 18:34:05 <nirik> jgreguske: cool. Any idea when? 18:34:12 <jgreguske> first half of this year 18:34:20 <mattdm> I agree that it's not gorgeous, but the problem is that the current approach is horribly broken with no solution. 18:34:32 <jgreguske> there is not future for chroot based image building 18:34:38 <pjones> sgallagh: let's wait for coprs to be finished before we start making things depend on it? 18:34:38 <jgreguske> *no 18:34:43 <nirik> jgreguske: ok, then that might be a possible solution for us? 18:34:54 <jgreguske> nirik: I certainly would like it to be 18:35:04 <mattdm> nirik: it is, in effect, the proposal. :) 18:35:31 <nirik> ok. I'd prefer to get a bit more input and we discuss next week? 18:35:58 <mmaslano> great 18:36:26 <mattdm> oz is *meant* for building images other than the os it's run on. main concrete objection from dennis was that mkisofs flags might change. 18:37:22 <pjones> so if the mkisofs flags change and they don't work, it seems like that just means we need a bugfix? 18:37:36 <mmaslano> can we move on? dgilmore is not here anyway 18:37:42 <pjones> doesn't seem like a good reason to not switch to doing something we think is better. 18:37:48 <mattdm> pjones: yeah. 18:37:53 <mmaslano> you are trying to solve technical difficulties, which is not right place nor time 18:38:03 <abadger1999> mmaslano: +1 18:38:07 <t8m> mmaslano, +1 18:38:20 <abadger1999> It's spread out but I think we've hit +5 for defer 18:38:34 <mmaslano> hope so 18:38:43 <pjones> mmaslano: if we know of an objection from somebody relevant, it is our responsibility to at least give it a perfunctory discussion and rule it in our out as a showstopper. 18:38:51 <pjones> which I think we've now done, but still. 18:38:52 <jwb> +1 defer 18:39:08 <mmaslano> #agreed defer to next week, more discussion with other relengs needed (+6,-0) 18:39:47 <mmaslano> #topic #1019 F19 Feature: Shared System Certificates - https://fedoraproject.org/wiki/Features/SharedSystemCertificates 18:39:51 <mmaslano> .fesco 1019 18:39:52 <zodbot> mmaslano: #1019 (F19 Feature: Shared System Certificates - https://fedoraproject.org/wiki/Features/SharedSystemCertificates) – FESCo - https://fedorahosted.org/fesco/ticket/1019 18:40:10 <nirik> so, I like the idea here, I think it may be a long road, but so be it. ;) 18:40:30 <sgallagh> So t8m, you mentioned earlier that there was a "phase 1" subset that was the real target. Could you explain that please? 18:40:32 <t8m> sgallagh, so I am fairly optimistic at least for the first step of the idea which is this feature 18:40:41 * mitr is kind of involved, so will abstain from voting 18:40:43 <notting> it definitely seems the Right Thing To Do. i'm a bit concerned about how we would catch any breakage with the library changes in apps that do dumb things 18:41:20 <sgallagh> Yeah, I most certainly want this to happen. I have no objection to that. I'm just wary of the "how", without breaking our crypto libraries in tough-to-spot ways. 18:41:21 <mitr> notting: The only thing this feature does for NSS and OpenSSL is change the mechanism the trust is generated, without changing the location of the data. 18:41:29 <mitr> So there should be very little risk. 18:41:30 * nirik is +1 anyhow. I think it's important to keep communication up with the devel list on progress as it goes tho 18:41:32 <t8m> mitr, I am kind of involved as openssl maintainer but as I am not the feature owner I can vote 18:41:49 <mitr> (I'm not 100% sure how much change will happen for gnutls) 18:42:13 <jwb> brb 18:42:32 <t8m> sgallagh, notting, actually I think this change will not make any already broken app more broken 18:42:48 <t8m> sgallagh, notting, at least in this first step the old bundles still be there 18:43:02 <notting> fair enoough 18:43:11 <t8m> mitr, gnutls won't change in this first step at all 18:43:25 <mitr> t8m: i.e. again the same location of the bundle used by applications? great 18:43:31 <t8m> yes 18:43:38 <sgallagh> Ok, could we ask that the Feature page be revised to list only what they're trying to do in F19 18:43:47 * notting is +1 then 18:43:59 <t8m> sgallagh, I think the page is correct in this sense 18:44:00 <sgallagh> And then ask for future feature pages when it's time to change core pieces of the crypto libs? 18:44:58 <sgallagh> t8m: The detailed description section seems to at least imply a more comprehensive solution than we're discussing. 18:45:10 <sgallagh> In any case, I am +1 to what I now understand is actually happening in F19 18:46:03 <t8m> sgallagh, but I really think the detailed description describes exactly that 18:46:35 <abadger1999> sgallagh: I think a lot of the detailed section explains how the certificates that a given crypto library uses will be generated from our central bundle rather than (current) having its own bundle or (future) being adapted to use the central bundle direcdtly. 18:46:41 <abadger1999> t8m: is that correct? 18:46:49 <t8m> sgallagh, except of course the paragraph which contains "Over time, (but not in this Fedora release) there will be:" 18:47:09 <t8m> abadger1999, yes 18:47:34 * abadger1999 +1 to feature 18:47:42 <sgallagh> +1 (again) 18:47:50 <t8m> so +1 from me 18:47:56 <mmaslano> +1 18:48:19 <pjones> Yeah, I think I'm +1 to this. 18:49:01 <jwb> +1 18:49:33 * nirik is still +1 18:50:01 * notting is still +1 18:50:09 * mitr +0? 18:50:18 <mitr> "+1 but not voting" or something 18:51:03 <mmaslano> #agreed Shared System Certificates are F19 feature (+8,-0, 1 abstain) 18:51:56 <mmaslano> now features, which were discussed a lot on the list 18:52:11 <mmaslano> #topic #1006 F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB 18:52:15 <mmaslano> .fesco 1006 18:52:17 <zodbot> mmaslano: #1006 (F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB) – FESCo - https://fedorahosted.org/fesco/ticket/1006 18:52:50 * nirik is +1 for this. If folks want to keep maintaining mysql also thats ok. I don't like the conflicts, but don't see a better answer. 18:52:55 <pjones> I think at the very least this needs to be reworded, and they must be able to live alongside. 18:53:03 <jwb> pjones, agreed 18:53:07 <jwb> that was my main concern 18:53:22 <notting> did we actiually have people that *want* to maintain mysql (as opposed to want mysql to be maintained, which is not the same thing) 18:53:24 <sgallagh> Can we ask them to rename this feature somehow and work nicely with the Oracle folks on keeping both DBs available? 18:53:33 <mmaslano> as I speak with hhorak, no problem 18:53:42 <nirik> notting: I thought someone did say they would, but I could be misremembering. 18:53:46 <mattdm> notting: yes, oracle people said that they would maintain 18:53:47 <mmaslano> the question is if there will be any mysql maintainers 18:53:52 <mitr> Well, all the clients can be linked with and tested against only one of them. 18:53:53 * abadger1999 +1 to this. 18:54:03 <sgallagh> notting: I think the Oracle guy was actually volunteering to do it. 18:54:21 <jwb> i'm not sure they were clearly volunteering to do it even if mysql isn't the default 18:54:25 <pjones> mitr: and if the code specifies "mysql", and they don't want mysql, then it would seem they should change the code, yes? 18:54:27 <mitr> I can't see any problem with having two separate stand-alone servers if anybody wanted to maintain mysql 18:54:29 <jwb> but it's something that could be asked 18:54:30 <mmaslano> possible, but I guess apss must be linked with only one database 18:54:48 <mattdm> http://markmail.org/message/q5fk6lxlniq2p6gz?q=python#query:python+page:1+mid:oybas2zmjrpo2hap+state:results 18:54:55 <sgallagh> mmaslano: Why? Many apps out there use an ODBC or similar interface so they work with multiple DBs 18:55:00 <mattdm> "We are ready to help integrate and package the latest and best-tested version of MySQL in Fedora, including becoming the package maintainer (same as we do with Ubuntu)." 18:55:01 <mmaslano> ok 18:55:01 <abadger1999> If there's explicit Conflicts:, they probably should be revisited once in a while to see if it makes sense to make them parallel installable now 18:55:20 <nirik> abadger1999: agreed. 18:55:47 <mitr> pjones: Is there any, even hypothetical, benefit from switching the _client_ library? 18:56:16 <sgallagh> Yeah, I'd really like us to campaign for MariaDB upstream to change names (or allow a mode to do so) so that they can avoid conflicting. Also, do we have trademark issues if MariaDB claims libmysqlclient.so.25 ? 18:56:18 <jreznik> well, there's also embedded mysql etc. - we really need to standardize on one (to not force users to install both) + allow both to coexists... 18:56:18 <t8m> so what will be done with applications that "Requires: mysql-server"? Will they be changed to MariaDB or what? 18:56:19 <pjones> mitr: well, there's no *guarantee* they'll remain completely compatible, is there? 18:56:36 <sgallagh> t8m: Perhaps we can do "Requires; 18:56:41 <mitr> pjones: I have looked at the protocol; it seems to have sufficient backward compatibility and versioning mechanisms 18:56:49 <notting> sgallagh: filenames are not trademarks, *i think* 18:56:55 <pjones> mitr: sure, but that doesn't help 18:56:56 <sgallagh> "Requires: mysql(5.3)" which can be satisfied by either? 18:57:21 <mitr> I'm not terribly keen on expanding the testing matrix 18:57:26 <pjones> if they rev the protocol and you have to have a newer one for the other backend, then no amount of versioning will work. yes, it'll fail correctly. but that's not the same as working. 18:57:33 <mitr> The new mysql maintainers are hypothetical at this point 18:57:51 <mitr> pjones: no, both sides will just fall back to the older version 18:57:57 <sgallagh> mitr: Well, we declare one or the other as the tested version and give a best effort only for the other. 18:57:59 <pjones> mitr: okay 18:58:14 <pjones> mitr: well, then I don't care that much about the client library after all 18:58:20 <mitr> pjones: (to be precise s/will/can in principle/) 18:58:25 <pjones> (right) 18:58:47 <sgallagh> notting: Anything can be a trademark. And that's a pretty clear usage of the MySQL trademark 18:59:10 <pjones> mitr: that's making some assumptions though - like they won't both have new versions of the protocol that conflict with each other. 18:59:11 <sgallagh> I don't know what the rules are for using it, but those rules could also be changed by Oracle at any moment to make life harder for MariaDB 18:59:23 <pjones> mitr: which I suspect isn't a great bet to place 18:59:32 <mitr> pjones: a part of the protocol is a textual version string that can be used to distinguish them 18:59:35 <pjones> though we can cross that bridge when we come to it 18:59:35 <sgallagh> * I don't know what the *current* rules are, I should say 18:59:38 <jwb> sgallagh, i don't think we're going to solve that here today. perhaps take it upstream. 18:59:50 <mitr> sgallagh: For F19, I'd focus the packaging on maintaining a smooth transition from mysql to mariadb; we can figure out the rules for coexistence if and when we need to. 18:59:58 <t8m> +1 ack this as long as the MySQL is allowed as alternative (no problem with conflicting it on parallel install) at least for the non-embedded case 19:00:24 <notting> t8m: yeah, i can be +1 to that. Conflicts: are fine 19:00:28 <sgallagh> mitr: I think "when" is already here, given Oracle's involvement in the discussion. 19:00:29 <pjones> sgallagh: trademark? I doubt it unless we start using "libmysql.so.31337" in user-facing text. 19:00:33 <mitr> t8m: "mysql the server", or also the cliens with the same .so? 19:00:41 <notting> although i'd just really prefer Obsoletes: and only ship one 19:00:41 <sgallagh> But yeah, I'm +1 to t8m's proposal 19:00:41 <mitr> sgallagh: discussion != package review 19:00:46 <notting> actually 19:00:59 <notting> HERE is where we should use nonexistent COPRs to solve a problem. mysql in a copr! 19:01:13 * sgallagh chuckles 19:01:21 <mmaslano> lol 19:01:43 <nirik> somewhat... 19:02:15 <abadger1999> notting: +1 to liking Obsoletes better... but if someone steps up to maintain mysql packages, it will quickly not matter. (obsoletes should be versioned so that you replace an older package, not used for an update war) 19:02:42 <sgallagh> I would like a #info that we really want these two communities to make an effort at coexisting without conflicting, but it's not a requirement for F19 19:02:43 <mmaslano> +1 19:02:43 <mitr> "We intend to mark the mariadb packages as providing/obsoleting mysql" is already in the feature 19:02:51 <mmaslano> sgallagh: ok 19:03:15 <abadger1999> mitr: hmm... on list there was discussion about obsoleting portion I think... /me looks for it 19:03:47 <sgallagh> mitr: I don't think that's an acceptable approach. I'm not in favor of Provides: or Obsoletes: mysql for this if mysql still exists in the repo. 19:03:54 <notting> mitr: i'm honestly OK with that. the feature is about those active in fedora and responsible for the databases making a switch 19:04:04 <mitr> notting: me too 19:04:10 <abadger1999> http://lists.fedoraproject.org/pipermail/devel/2013-January/176635.html 19:04:15 <mitr> let's start again... 19:04:46 <abadger1999> sgallagh: Provides would be okay... the Obsoletes gets sticky. 19:05:00 <mmaslano> any proposal? 19:05:06 <pjones> obsoletes with "<=" the branch point is fine 19:05:06 <sgallagh> Ok, yes. Obsoletes is where I draw the line. 19:05:13 <mitr> Proposal: Feature accepted as proposed (including obsoletion as a transition mechanism). If new MySQL maintainers appear, feature owners are asked to make it possible to install the MySQL stand-alone srever (only) 19:05:27 <pjones> mitr: yeah, +1 19:05:52 <sgallagh> pjones: That will still force a change on any update, won't it? 19:06:03 <notting> mitr: wfm. +1 19:06:09 <sgallagh> mitr: -1 (I disagree on the obsoletes) 19:06:11 <drago01> sgallagh: obsolete would force a change at update 19:06:24 <pjones> sgallagh: ... any update from a prior version. 19:06:32 * nirik isn't sure he likes obsolete either if there's maintainers for mysql 19:06:35 <t8m> mitr, obsoletion as transition mechanism is meant to have versioned obsoletes only I suppose? 19:06:43 <pjones> because right now we've seen interest in mysql maintenance, but it hasn't /happened/ yet. 19:06:46 <mitr> sgallagh: the two are currently compatible both on protocol and data format level, so it's simply a transition from one upstream with specific Fedora maintainers to a different upstream with the same Fedora maintainers. 19:06:56 <mitr> Wha'ts your concern about forcing the change? 19:06:57 <sgallagh> pjones: I don't understand the yum dep resolution well enough. 19:06:57 * abadger1999 is okay with versioned obsolete. 19:07:10 <pjones> sgallagh: well, you'll have to take our word for it, then. 19:07:19 * t8m is okay with versioned obsolete as well 19:07:21 * pjones is also okay with a versioned obsolete 19:07:22 <abadger1999> If someone else picks up the mysql package, they'll bump release and the new package will no longer be obsoleted 19:07:29 <nirik> yeah, ok. 19:07:30 <pjones> abadger1999: exactly. 19:07:33 <abadger1999> b/c its nevr is higher 19:07:36 <jwb> +1 19:07:51 <pjones> and if they do that before F19, it'll never be an issue for them. 19:07:56 <abadger1999> right 19:08:16 <pjones> so hypothetical mysql maintainers who should be paying attention to this discussion, make a note ;) 19:08:17 <abadger1999> +1 19:08:18 <sgallagh> OK, so if MySQL 6 appears in the DB, that will be preferred over MariaDB 5.7? (hypothetically)? 19:08:33 <pjones> sgallagh: for people with the mysql package already installed, yeah 19:08:37 <mitr> Right, that's what I was wondering about 19:08:51 <nirik> ok, +1 19:08:52 <mitr> Perhaps we need the new packages to be named "oracle-mysql" or something? 19:09:10 <mitr> Or plan a different way to transition the dependencies 19:09:18 <pjones> seems like that makes it worse, really 19:09:38 <pjones> because then they'll just include the same obsolete, also with a newer version, and we'll have the same mathematical scenario but with one more package name. 19:09:54 * nirik wonders where we are in voting? 19:09:59 <mmaslano> I'm not sure maintainers will be happy with this outcome. I guess they wanted to see mariadb as "main" database 19:10:08 <notting> i'm sure we can make the problem worse with epochs somehow 19:10:09 <mmaslano> nirik: and what is the proposal ;-) 19:10:16 <t8m> notting, +1 LOL 19:10:19 <nirik> I think we were voting on mitrs: 19:10:23 <sgallagh> pjones: Ok, with that understanding, I'm okay with the versioned Obsoletes approach (though it seems to me that this is going to reduce down to the same case as no Obsoletes:, since Oracle will probably version-bump or epoch-bump to get around this) 19:10:33 <nirik> mitr> Proposal: Feature accepted as proposed (including obsoletion as a transition mechanism). If new MySQL maintainers appear, feature owners are asked to make it possible to install the MySQL stand-alone srever (only) 19:10:37 <mitr> OK, so let's approve the feature as is (because it makes sense with what we have), and if mysql happens again, let $somebody figure out a different transition plan (and I'd suggest that $somebody should be the people who want mysql again) 19:10:41 <pjones> sgallagh: making the assumption they get their act together, yes ;) 19:10:45 <Viking-Ice> if I'm not mistaken you cannot force a change on update/upgrade it might break 3rd party application support 19:10:51 <notting> sgallagh: if you're epoch-bumping or version-bumping just to make your non-default thing the default, we have FESCo mechanisms to deal with that 19:10:55 <abadger1999> notting: Epoch: %(rpm -q bind --qf '%{epoch}') 19:10:58 <pjones> Viking-Ice: it won't - they provide the same library sonames 19:11:04 <pjones> Viking-Ice: with the same ABI 19:11:09 <notting> proposal: clearly state that fedora prefers mariadb? 19:11:12 <notting> (for now) 19:11:17 <pjones> notting: +1 as well 19:11:18 <nirik> notting: +1 19:11:21 <mitr> notting: +1 19:11:23 <mmaslano> +1 19:11:24 <t8m> notting, +1 19:11:52 <Viking-Ice> pjones, I mean upstream 3rd party support like jira/confluence which do not support users running mariadb but do support users running mysql ( and other databases ) 19:11:57 <sgallagh> notting: +1 19:12:02 <abadger1999> +1 19:12:26 <mmaslano> #agreed Replace MySQL with MariaDB is F19 feature (+7,-0) 19:12:37 <mmaslano> #topic #1007 F19 Feature: Checkpoint/Restore - https://fedoraproject.org/wiki/Features/Checkpoint_Restore 19:12:45 <mmaslano> .fesco 1007 19:12:47 <zodbot> mmaslano: #1007 (F19 Feature: Checkpoint/Restore - https://fedoraproject.org/wiki/Features/Checkpoint_Restore) – FESCo - https://fedorahosted.org/fesco/ticket/1007 19:12:53 * nirik is +1 for this, had no particular questions. 19:13:07 <jwb> kernel team is fine with it. i turned stuff on today 19:13:08 <mitr> kernel maintainers are OK, so +1 19:13:13 <sgallagh> mmaslano: I thought we were voting on clearly stating that Fedora prefers MariaDB. I'm still not sure we came to a conclusion on Obsoletes... 19:13:20 <pjones> Viking-Ice: right now we don't have anybody maintaining mysql, so that's not really a problem we can address. 19:13:22 <mmaslano> #undo 19:13:22 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xbc371d0> 19:13:46 <mmaslano> #topic #1006 F19 Feature: Replace MySQL with MariaDB - https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB 19:14:05 <pjones> So let's do this again: 19:14:08 <pjones> <nirik> mitr> Proposal: Feature accepted as proposed (including obsoletion as a transition mechanism). If new MySQL maintainers appear, feature owners are asked to make it possible to install the MySQL stand-alone srever (only) 19:14:10 * pjones +1 19:14:24 <jwb> with server spelled right +1 19:14:27 <nirik> +1 19:14:29 <abadger1999> +1 19:14:30 <mmaslano> +1 19:14:33 <notting> +1 19:14:33 <mitr> +1 19:14:37 <Viking-Ice> pjones, well if we ship mysql you cant obsolete it with mariadb because you might break paid support doing so 19:14:43 <sgallagh> So my main concern is that, correctly or illegitimately, the Oracle folks could release a version bump and we're back to staying on the MySQL track 19:14:57 <mitr> Viking-Ice: Fedora is not paid to support it... 19:14:59 <pjones> it appears we have voted for the proposal. 19:15:14 <pjones> Viking-Ice: that sounds like a problem for somebody getting paid 19:15:23 <jwb> 7. consensus. 19:15:29 <mmaslano> #agreed Feature accepted as proposed (including obsoletion as a transition mechanism). If new MySQL maintainers appear, feature owners are asked to make it possible to install the MySQL stand-alone server (only) (+7,-0) 19:15:32 <sgallagh> pjones: I'm still -1 if Obsoletes is in play 19:15:39 <pjones> sgallagh: yes, and then package maintainers can choose to change their deps. 19:15:41 <Viking-Ice> mitr, no but you might have paid for a product that runs on fedora and that support your paying for covers only mysql not mariadb 19:15:47 <nirik> did we want to vote on the preferred thing? or leave it alone? 19:15:55 <sgallagh> I've said my piece and been outvoted. We can move on. 19:16:08 <mmaslano> #topic #1007 F19 Feature: Checkpoint/Restore - https://fedoraproject.org/wiki/Features/Checkpoint_Restore 19:16:12 <mmaslano> .fesco 1007 19:16:14 <zodbot> mmaslano: #1007 (F19 Feature: Checkpoint/Restore - https://fedoraproject.org/wiki/Features/Checkpoint_Restore) – FESCo - https://fedorahosted.org/fesco/ticket/1007 19:16:22 <jwb> kernel team is fine with it. i turned stuff on today. we'll back it out if it causes problems 19:16:47 <abadger1999> +1 since kernel team is onboard 19:16:50 <mmaslano> +1 19:16:54 <t8m> +1 19:16:54 <pjones> sgallagh: the provides will still be there, so maria will provide that dep resolution. if somebody cares which one they get, kickstart works for systems, and more specific deps work for packages that care. 19:16:55 <sgallagh> +1 19:17:03 * pjones +1 19:17:08 <jwb> +1 btw 19:17:22 <jwb> adrianr even knows of testcases! extra excited 19:17:23 <notting> +1 19:17:31 <nirik> +1 19:17:37 <mitr> +1 19:18:15 <mmaslano> #agreed Checkpoint/Restore is F19 feature (+9,-0) 19:19:19 <mmaslano> #topic #1009 F19 Feature: Fedora Upgrade - https://fedoraproject.org/wiki/Features/FedoraUpgrade 19:19:23 <mmaslano> .fesco 1009 19:19:25 <zodbot> mmaslano: #1009 (F19 Feature: Fedora Upgrade - https://fedoraproject.org/wiki/Features/FedoraUpgrade) – FESCo - https://fedorahosted.org/fesco/ticket/1009 19:19:50 <nirik> so, I think it's fine that we have a package for this, and that someone is working on making yum upgrades less painfull. 19:20:21 <nirik> that said, I don't think we should point our general users at it. I think it should be mentioned as a 'advanced user' type thing. 19:20:25 <sgallagh> I'm -1 to officially supporting online upgrades. It's a disaster and PR nightmare waiting to happen 19:20:40 <jwb> pretty squarely against it being the suggested/supported/official method for upgrades. i don't care if the package exists or not 19:20:41 <mitr> -1 to making runtime upgrades a supported path; it's just not technically possible in many upgrade scenarios 19:20:43 <t8m> sgallagh, we don't officially support anything 19:20:44 <t8m> :D 19:20:47 <nirik> so, -1 to the feature 19:21:04 <jwb> -1 19:21:04 <pjones> I'm very much -1 to this. 19:21:06 * notting agrees with nirik . -1 on those grounds 19:21:16 <sgallagh> t8m: Can we just agree that I would say "commercially supported" if I meant that? :) 19:21:25 <mmaslano> I think it could be documented as difficult option 19:21:33 <t8m> mmaslano, +1 19:21:43 <jwb> mmaslano, i don't see the need. just add the package name to the existing yum upgrade docs 19:21:46 <nirik> mmaslano: sure, I'm fine with that... but we should NOT advertise it as a feature to all our users. 19:21:54 <jreznik> jwb: +1 19:21:56 <mitr> mmaslano: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum is already community-maintained 19:22:17 <abadger1999> mmaslano: +1 19:22:33 <t8m> ok -1 to the feature +1 to the package, documentation, etc. 19:22:37 <pjones> also, to be honest, it's not clear to me from reading the feature what he's talking about actually /doing/ other than having a command named fedora-upgrade. 19:22:38 <sgallagh> Yes, let's point them there, tell them they can do the work if they want and mention it in a community wiki page, but let's not recommend it in any way (including by accepting it as a Feature) 19:22:39 <mmaslano> ok, I'll ask docs guys about it 19:22:42 <pjones> so -1 to everything. 19:23:04 <abadger1999> -1 to advertising it as a feature 19:23:19 <pjones> Also I'm not particularly okay with having a package named that and having it drop a program named "fedora-upgrade" in the path unless QA is planning on doing testing of it. 19:23:31 <nirik> it's already in/shipped 19:23:38 <sgallagh> That's a good point. There's a branding consideration there 19:23:39 <pjones> nirik: doesn't mean I'm okay with it. 19:23:53 <nirik> sure, just mentioning that it's been in a while. 19:24:21 <sgallagh> Let's ask them to rename to online-upgrade or similar, so it's not assumed to be blessed the way "fedora-upgrade" sounds. 19:24:26 <pjones> yeah. I can't always get what I want. 19:24:32 * nirik isn't sure there's a better name really... 'fedora-live-upgrade' 'fedora-upgrade-live-dontuse' ? 19:24:49 <jwb> nirik, just drop the fedora part 19:24:51 <nirik> 'beware-of-lepard' 19:24:53 <pjones> nirik: if we're not blessing it, it shuoldn't be "fedora" anything. 19:25:08 <sgallagh> pjones: +1. That's why I suggested "online-upgrade" 19:25:13 <mitr> pjones: That would be a rathe new rule 19:25:18 <mitr> I still see the concern... 19:25:25 <mitr> Having "fedora upgrade" easier to find than "fedup" is not great 19:25:25 <jwb> if-you-break-it-you-can-keep-both-pieces 19:25:31 <pjones> mitr: yeah 19:26:06 <drago01> semi unrelated but do we currently install fedup by default? 19:26:07 * nirik is fine with whatever there... perhaps ask for them to change it to 'online-upgrade' ? 19:26:36 <nirik> drago01: I don't think so, but I could be wrong. 19:26:40 <abadger1999> nirik: +1 19:26:48 <pjones> drago01: no, but maybe we should consider it. 19:26:49 <t8m> or at least fedora-yum-upgrade 19:26:56 <drago01> pjones: ok 19:26:59 <nirik> sgallagh: could you take that to the maintainers? :) 19:27:01 <mmaslano> t8m: that would be best 19:27:25 * nirik doesn't care much what it's called as long as it reduces confusion 19:27:38 <sgallagh> nirik: Will do. Hit me up with a #action to do that, as well as one to approach the Board about formalizing a request process for adding packages with "fedora" in their name 19:28:10 <notting> yes, +1 to rename 19:28:21 * pjones obviously +1 to rename 19:28:24 <nirik> #action sgallagh to ask fedora-upgrade maintainers to consider renaming to avoid confusion 19:28:24 <mmaslano> #action sgallagh will speak with Board about formalizing a request process for adding packages with fedora in their name 19:28:29 * jreznik can talk with mirek about it but expects resistance :) 19:28:38 * nirik stops and lets mmaslano do it. :) 19:28:46 <sgallagh> That's why I want to talk with the Board first 19:29:10 * nirik thinks we finished voting here? 19:29:28 <t8m> yeah please 19:29:29 * abadger1999 notes for the record that he's not enthralled with a general rule 19:29:30 <drago01> are forks/respins required to rename such packages? 19:29:40 <mmaslano> I see +4 19:29:41 <drago01> if yes we should consider not to use fedora-foo at all 19:29:53 <jwb> +1 19:29:57 <jwb> 5. move on 19:29:58 <t8m> mmaslano, I mean #agreed to NACK the feature 19:29:58 <sgallagh> mmaslano: +1 for rename 19:29:59 <pjones> drago01: we really can't control what a fork does in that regard, I don't think 19:30:15 <drago01> pjones: I mean from a legal / trademark pov 19:30:15 <abadger1999> So if it's to be a fesco request to the board, we should vote on it... if it's just personal request, then no need :-) 19:30:34 <pjones> abadger1999: the general rule would be "somebody needs to review them and make sure it's not confusing enough that others should discuss it" 19:30:42 <mmaslano> #agreed Fedora Upgrade must rename after Board decide about naming convention for fedora-* packages (+5,-0) 19:30:45 <mitr> I'm not enthusiastic about instituting the rule either - let's try dealing with this as an one-off before adding a process 19:31:04 <mmaslano> #undo 19:31:04 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0xc314050> 19:31:14 <nirik> mmaslano: I think we simply rejected the feature. ;) 19:31:16 <t8m> mitr, agree 19:31:31 <pjones> Proposal: ask FPC to /recommend/ against using "fedora" in package names without discussion on f-d-l first 19:31:44 <mmaslano> #agreed Fedora Upgrade feature is rejected (+0,-7) 19:31:47 <t8m> pjones, FPC or board? 19:31:55 <pjones> t8m: well, FPC makes packaging requirements. 19:31:58 <Viking-Ice> just out of curiosity did fedup up magically inherit the official upgrading label from preupgrade? 19:32:05 <abadger1999> FPC would be packaging guidelines so I can see that. 19:32:08 <sgallagh> Yes, but the Board makes trademark rulings 19:32:08 <pjones> so it seems like their purview 19:32:43 <nirik> Viking-Ice: well, depending on what you mean by 'official' 19:32:45 <pjones> Viking-Ice: well, with the same group of responsible people for it as all of our previous supported upgrade methods, it does seem natural. 19:33:05 <jwb> also, importantly, a very similar method of updating 19:33:10 <jwb> not something totally different 19:33:11 <pjones> sgallagh: this isn't really about trademark. more about branding. 19:33:16 <t8m> I think we're making it bigger problem than it really is, so -1 19:33:16 <mitr> pjones: fpc deals with "packaging" of "upstreams", and the current naming guidelines prefer using the same name as "upstream" 19:33:28 <sgallagh> Ok, fair enough, but branding is still a Board decision :) 19:33:31 <jwb> can we move on to another feature? 19:33:35 <mmaslano> sgallagh: you have action, please solve it as you think 19:33:37 <t8m> jwb, +1 19:33:42 <mmaslano> #topic #1022 F19 Feature: systemd/udev Predictable Network Interface Names - https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames 19:33:45 <sgallagh> mmaslano: Will do 19:33:47 <mmaslano> .fesco 1022 19:33:50 <zodbot> mmaslano: #1022 (F19 Feature: systemd/udev Predictable Network Interface Names - https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames) – FESCo - https://fedorahosted.org/fesco/ticket/1022 19:34:57 <mitr> I really liked the fedora-devel idea to tweak the naming policy so that em1 stays em1 19:35:07 * nirik will be right back. 19:35:15 <Viking-Ice> pjones, well qa was left out that official part last time it was decided ( with preupgrade ) hence the question ( we are better of not officially supporting neither yum or pre/fedup ) 19:35:55 <t8m> Viking-Ice, except no upgrade method would be a really bad press item 19:36:08 <pjones> Viking-Ice: you've just said we're better off without upgrades. While from a maintenance perspective I completely agree, but I don't think our users are best served that way. 19:36:17 <t8m> but we already moved to next topic 19:36:22 <t8m> mitr, +1 19:38:01 <pjones> mitr: yeah, that's not a bad idea 19:38:48 <sgallagh> I'm +1 either way, but I'd prefer the em1 tweak as well 19:39:18 <notting> the one issue with the em1 tweak is that it moves embedded interfaces out of the same initial namespace as other interfaces (which are en*) 19:39:27 <t8m> note that they also ask our decision on the biosdevname usage on upgrades 19:40:38 <mitr> notting: All of the "en*" naming is new, so does it hurt? 19:41:25 <nirik> I'm +1 for the feature. If there are reasonable tweaks thats fine, if not, oh well. 19:41:46 <pjones> I'm also +1, but prefer the em1 tweak to be included. 19:42:03 <mmaslano> +1, tweak included 19:42:21 <jwb> yes +1 19:42:39 <abadger1999> +1 19:42:40 <t8m> +1 with or without the tweak, but I am rather undecided on the biosdevname on upgrades 19:43:19 <mitr> Let's try a full proposal: 1) feature is approved 2) upgrades shouldn't change naming, 3) eno=>em tweak is required 19:43:21 <fenrus02> changing the interface name on an upgrade is pain and misery for all involved. 19:43:44 <sgallagh> mitr: +1\ 19:43:46 <notting> i'm not convinced the naming tweak is *required* 19:43:52 <notting> i'm +1 to 1) and 2) 19:43:54 <t8m> mitr, OK, +1 to 1), 2) 19:44:12 <nirik> +1 1) and 2) 19:44:15 <pjones> it's not clear to me that upgrade is included in this proposal. Is it? 19:44:23 <mmaslano> +1 1) and 2) 19:44:28 <mitr> pjones: 2) 19:44:29 <pjones> gah, 10 lines behind and I come to mitr's new proposal. 19:44:40 <pjones> I'm +1 to all 3 honestly, but I'd be +1 to just #1 and #2 as well. 19:44:43 <mitr> notting: I don't think missing the tweak would be a disaster; my concern is that if FESCo doesn't specifically require it, the feature owners will not want to change from the upstream system 19:45:28 <mitr> So either we require it or it probably doesn't happen 19:46:23 <sgallagh> It looks like we all agree on 1) and 2) 19:46:30 <mmaslano> #agreed systemd/udev Predictable Network Interface Names are accepted as F19 feature (+7,-0) 19:46:31 <sgallagh> Can we just vote on 3)? I'm +1 19:46:36 <abadger1999> +1 w/ same notes as pjones 19:46:38 <t8m> perhaps we could try something like: "FESCo prefers the em1 tweak unless there are serious reasons (not just implementation simplicity) to not have it." 19:46:46 <pjones> sgallagh: +1 19:46:59 <mmaslano> #agreed systemd/udev Predictable Network Interface Names - upgrades shouldn't change naming (+5,-0) 19:47:18 * mitr is +1 on 3), for the record 19:47:22 <mmaslano> t8m: +1 19:47:29 <pjones> sgallagh: for clarity, I'm in agreement both with voting separately and +1 for the actual vote. 19:47:32 <notting> note: i *think* we could do 3) with local policy 19:47:35 <sgallagh> t8m: I thought that was generally implied. 19:47:42 <notting> although that's kind of weird 19:47:43 <mitr> notting: ... within the systemd package? 19:47:48 <t8m> sgallagh, ok then +1 19:48:38 <notting> mitr: NAME=="eno[0-9]+", NAME="em%n". but i haven't checked that 19:49:05 <fenrus02> notting, handy if that works 19:49:08 <sgallagh> t8m: I'd prefer to say "do this" and if they come back eventually and say "we can't" deal with it then. 19:49:16 <mitr> notting: Sorry; I mean that adding "local policy" to systemd package and asking feature owners who own systemd package to change the Fedora default is indistinguishable to me. 19:49:18 <mmaslano> I see it as 3) eno=>em tweak is required passed by 5 19:49:19 <t8m> sgallagh, OK 19:49:37 <notting> mmaslano: -1 to making it required 19:50:38 <Viking-Ice> on qa related changes to your voting will interface name changes on upgrade break the upgrade criteria thus delay the release if it comes to it? 19:50:55 <mmaslano> more votes? I still see +5,-1 to requires the tweak 19:50:57 * nirik is also -1 to required 19:51:01 <nirik> but thats fine. 19:51:06 <mitr> Viking-Ice: We voted that upgrades shouldn't change names 19:51:19 <nirik> Viking-Ice: upgrades should stay the same... only new installs get the new ones. 19:51:19 <jwb> -1 to required, but it passes anyway 19:51:31 <Viking-Ice> mitr, yes then we need to specifically test for that 19:51:40 <notting> Viking-Ice: so, yes, if upgrade changes the device names, then we need to fix it 19:51:54 <fenrus02> on a non-upgrade, i dont see why it matters that much what the name is. on an upgrade, it must remain exactly the same that it was. 19:51:56 <notting> (or, at least, changes the device names due to this feature) 19:52:33 * nirik largely doesn't care what the names are. The only time it matters is if you have specific firewall rules, and thats trivial to adjust 19:53:09 <fenrus02> nirik, for a new install, i completely agree. for an existing one that was upgraded, i do not 19:53:11 <Viking-Ice> nirik, those name changes might break some virtualzation bits as well 19:53:45 <mmaslano> could you vote once more on twek? 19:54:08 <mitr> +1 19:54:16 <t8m> +1 19:54:23 <nirik> I would not think so, but ok. 19:54:30 <sgallagh> +1 19:54:49 <notting> -1 19:54:54 <mmaslano> or do you see same as me that twek passed as a must? 19:55:01 <nirik> -1 19:55:09 <notting> (not that the tweak would be *bad*, just don't see it as a must) 19:55:24 <fenrus02> i dont see it as a required item. more of a nth if its trivial 19:55:26 <mmaslano> +1 19:55:30 <sgallagh> notting: perhaps that should be a +0 then 19:55:53 <notting> sgallagh: *shrug* 19:55:56 <notting> ok then,, 0 19:56:00 <abadger1999> +0 19:56:22 * pjones is +1 to the tweak 19:56:41 <pjones> which brings us back to the +5 from the previous vote. 19:57:08 <mmaslano> #agreed eno=>em tweak is required (+5, -1) 19:57:17 <mmaslano> #topic #1024 F19 Feature: MEMSTOMP - https://fedoraproject.org/wiki/Features/MEMSTOMP 19:57:21 <mmaslano> .fesco 1024 19:57:23 <zodbot> mmaslano: #1024 (F19 Feature: MEMSTOMP - https://fedoraproject.org/wiki/Features/MEMSTOMP) – FESCo - https://fedorahosted.org/fesco/ticket/1024 19:57:43 * nirik is fine with this feature. +1. I did wonder if this is going to result in more abrt filed bugs, but thats a side note. 19:57:45 <mitr> +1 19:57:50 <mmaslano> +1 19:57:58 <t8m> +1 19:58:07 <sgallagh> +1 19:58:10 <law> it might, but only if someone turned on memstomp 19:58:16 <notting> +1 19:58:24 <notting> law: should we enable it by default in the debugmode package? 19:58:28 <abadger1999> +1 19:58:29 <mitr> more abrt-filed bugs reporting real problems are a good thing, aren't they? 19:58:43 <mmaslano> #agreed MEMSTOMP is F19 feature (+7,-0) 19:58:52 <mmaslano> #topic #1004 Mass rebuild schedule 19:58:55 <fenrus02> mitr, non-dups, sure 19:58:55 <mmaslano> .fesco 1004 19:58:57 <zodbot> mmaslano: #1004 (Mass rebuild schedule) – FESCo - https://fedorahosted.org/fesco/ticket/1004 19:58:59 <nirik> law: yeah. Might be worth asking abrt folks to note that in reports it files with it enabled or something? 19:59:05 * pjones is definitely +1 here 19:59:07 <law> think it depends on if i can make backtraces thread safe 19:59:18 <nirik> I'd like to propose we push out a week... 19:59:23 <mitr> nirik: I'd expect it to be visible in backtraces 19:59:34 <nirik> start on the 8th instead of the 1st. 19:59:40 <nirik> mitr: probibly true. 19:59:42 <pjones> yeah, abrt hitting the backtrace with a regexp should be enough to detect it 19:59:45 <jmoskovc> nirik: law or make abrt to ignore those crashes 19:59:52 <jwb> nirik, why? 19:59:53 <pjones> (or even a simple substring match) 19:59:57 <mitr> jmoskovc: please don't 20:00:35 <nirik> reasoning: time for ruby/maven/other stuff to finish landing and hopefully reuse the mass rebuild instead of side tags. Also, we just got some arm hardware, and would be nice to have that running so we could do the mass rebuild in arm secondary at the same time. 20:00:36 <arthurbuliva> Pardon me, but is this EMEA Ambassadors meeting? 20:00:51 <pingou> arthurbuliva: see /topic 20:01:06 <jwb> nirik, ok. +1 20:01:13 <abadger1999> nirik: +1 20:01:17 <nirik> do we have any other pending stuff needing mass rebuild we haven't approved yet? 20:01:21 <mmaslano> nirik: +1 20:01:24 <nirik> (ie, next week) 20:01:50 * jreznik is ok with 8th 20:01:57 <notting> nirik: wfm. +1 20:02:00 <sgallagh> nirik: Do we know if KDE 4.10 is going to require a QT mass rebuild? 20:02:05 * nirik isn't sure. 20:02:05 <mitr> nirik: somebody mentioned glibc? 20:02:12 <nirik> glibc is landed. 20:02:17 <t8m> nirik, +1 20:02:21 <jreznik> sgallagh: qt mass rebuild? 20:02:33 <nirik> not sure about erlang 20:02:36 <pjones> nirik: so it can vote and marry? 20:02:54 <law> mitr: just in the context of mass rebuild dependencies 20:02:59 <sgallagh> jreznik: rebuild of packages consuming QT. I thought I remembered it soname bumped in Rawhide, but I could be mistaken. 20:03:11 <mmaslano> #agreed mass rebuild on 8th (+5,-0) 20:03:12 <nirik> arthurbuliva: no, this is fesco, we are running over. sorry. 20:03:22 <nirik> pjones: ? 20:03:25 <jreznik> sgallagh: ah, I missed that - I can ask guys 20:03:25 <pjones> mmaslano: I'm +1 to that as well 20:03:32 <mmaslano> #undo 20:03:32 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0xcedd150> 20:03:33 <pjones> nirik: just making fun of the use of "foo is landed" 20:03:38 <mmaslano> #agreed mass rebuild on 8th (+6,-0) 20:03:52 <nirik> cool. 20:03:59 <sgallagh> jreznik: My memory on that is hazy, I could be remembering F18 for all I know :) 20:04:04 <nirik> do we get to decide the rest of the schedule now too? 20:04:23 <pjones> nirik: I think we've got another pile of features for next week, don't we? 20:04:26 <mmaslano> don't have a ticket, not even dates 20:04:34 <sgallagh> nirik: I think we should probably ask someone to propose a schedule before we decide on it 20:04:37 <nirik> yeah there are more. 20:04:40 <t8m> sgallagh, +1 20:04:46 <kalev> one thing that would be great to have before the mass rebuild is the boost ugprade -- is there a schedule for that? 20:04:51 <jreznik> at least we know the mass rebuild date -> leads to branching date 20:04:56 <nirik> ah yeah, boost. 20:05:02 <sgallagh> Can we put that on the agenda for next week? Have someone(s) prep a preliminary schedule and adjust it if anything we discuss next week throws it off? 20:05:15 <pjones> sgallagh: I think we should probably just have an actual conversation on what a schedule should look like with jreznik, but... if he wants to propose something after next week's feature discussion, I guess he can. 20:05:38 <jreznik> pjones: at least I can try to work in the mass rebuild/branch 20:05:42 <nirik> well, we can eyeball the features pending... 20:05:46 <kalev> a large part of boost is header only templates, so without a mass rebuild packages would still continue using the old boost templates 20:05:46 <t8m> jreznik, would you do some schedule proposal given the current amount of fatures? 20:05:48 <jreznik> and we can tweak it based on features coming 20:05:50 <mmaslano> #topic Next week's chair 20:05:53 <sgallagh> Well, I'd rather have something tentative for next week than wait another week 20:05:54 <t8m> features that is... 20:05:56 <mmaslano> really two hours are enough 20:06:08 * nirik can do next week. 20:06:12 <mmaslano> great 20:06:20 <mmaslano> #action nirik will chair next meeting 20:06:20 <jreznik> sgallagh: I can work on it tomorrow and add to the schedule ticket 20:06:28 <mmaslano> #topic Open Floor 20:06:29 <jreznik> pls action me :) 20:06:34 <nirik> jreznik: I have some ideas too... we can discuss in devel? 20:06:35 * pjones has an item for open floor 20:06:38 <mmaslano> #action jreznik will propose schedule 20:06:51 <mmaslano> pjones: please 20:06:55 <jreznik> nirik: yep 20:07:09 * abadger1999 has 1.5 things from the fpc meeting after pjones 20:07:15 <pjones> so we discovered a slight problem with our secure boot support earlier today, and I wanted to bring it up here and see how people feel like dealing with it 20:07:28 <pjones> and that is, the certificate that's used to sign shim has a validity that expires in october 20:07:30 <sgallagh> pjones: Is this related to the Samsung brickings? 20:07:32 <pjones> and that's before F18 EOL 20:07:47 <pjones> sgallagh: no, that's not related to SB at all. Just a shitty firmware and a kernel bug. 20:08:03 <jwb> which is fixed 20:08:04 <mitr> pjones: ... and the private key is not under our control, is it? 20:08:09 <pjones> so we can easily get a new shim signed in that timeframe, and it'll have a longer validity 20:08:12 <pjones> mitr: correct 20:08:32 <pjones> but the problem is that as it stands we'll have a window where the boot media we've got mirrored won't work on some machines. 20:08:42 <nirik> icky 20:08:48 <mjg59> pjones: There are machines that check the date? 20:08:50 <sgallagh> How often is this going to happen? 20:08:53 <pjones> I don't have a great answer here, so I figured I'd solicit opinions. 20:09:01 <pjones> mjg59: none that I've seen, but I don't know that none will. 20:09:02 <sgallagh> Do we know when the new signing cert expires? 20:09:12 <pjones> mjg59: I suspect we'd learn about them in october if there are. 20:09:15 <sgallagh> i.e. are they planning to reissue it every 6 months or something? 20:09:16 <mjg59> pjones: And the certificate that was used to sign shim? 20:09:16 <pjones> sgallagh: we don't., 20:09:27 <sgallagh> Ok, how long was the previous one live? 20:09:29 <pjones> mjg59: hrm? 20:09:30 <jreznik> pjones: well, I don't expect many people will still use f18 media in october 20:09:36 <pjones> sgallagh: previous window was 13 months 20:09:38 <mjg59> pjones: As in, Microsoft provided a signature that expires? 20:09:45 <pjones> mjg59: the cert expires. 20:10:05 <mjg59> pjones: I don't understand. Whose cert? 20:10:10 <pjones> the signature itself doesn't have expiration dates; the cert that's signed it has validity that expires. 20:10:13 <pjones> microsoft's cert. 20:10:16 <sgallagh> How are Microsoft dealing with this? They can't be reissuing boot media every 12 months... can they? 20:10:23 <mjg59> Why are Microsoft using a cert that expires? 20:10:30 <mjg59> sgallagh: They sign with a different key for their media 20:10:35 <pjones> well, "Microsoft Windows UEFI Driver Publisher", as it were. 20:10:36 <sgallagh> Of course they do 20:11:03 <pjones> mjg59: well, all certs expire eventually. the question is "why is it soon" 20:11:05 <fenrus02> they could set the expire date +10yrs from now too. still has an expiration. just as meaningless however. 20:11:15 <mitr> pjones: So if I install F18, disconnect the box from the internet, and turn it on 2 years later, it might not boot because the signature is expired? 20:11:19 <mjg59> pjones: Given that every SB machine would just stop working in October in that case, I don't think our boot media is the primary concern 20:11:27 <sgallagh> pjones: The cynical answer is "because it makes it hard for competitors to sign anything" 20:11:32 <pjones> mitr: though we've yet to see any machine that checks the date, yes. 20:11:40 <pjones> sgallagh: not helpful. 20:11:48 <mjg59> pjones: Given that their GPU won't work any more 20:11:53 <pjones> mjg59: indeed. 20:12:09 <mjg59> pjones: So I'd suggest working with Microsoft to find out whether this is a real problem first? 20:12:18 <t8m> mjg59, +1 20:12:19 <pjones> mjg59: so this is probably something I should bring up with USWG then, actually. 20:12:23 <mitr> pjones: That sounds like a little more important problem to solve than installation media for a then-not-current release to me 20:12:23 <mjg59> Yeah 20:12:28 * pjones makes a note for something else to do today ;) 20:12:31 <sgallagh> pjones: Well, I wonder if this couldn't be grounds for an anti-competition suit by our corporate overlords. This is going to affect them too. 20:12:42 <t8m> if the bioses really check for that expiration date, it is surely a great misfeature of Secure Boot 20:12:45 <mjg59> sgallagh: No, it couldn't 20:12:47 <pjones> sgallagh: again not helpful - that's not something I think we'd have a solution for by october ;) 20:13:31 <mitr> sgallagh: well certificate expiration is a "best practice" 20:14:09 <sgallagh> mitr: Except if they're holding themselves to a different standard where their certificates last five years and the ones they give us only 13 months. 20:14:09 <pjones> Alright, so I'll go to USWG and try to get clarification that expiration cannot be honored. 20:14:20 <pjones> (it's already /useless/ to honor it, since any attacker can reasonably set the time themselves.) 20:14:45 <pjones> alright, we can move on. 20:15:13 <mmaslano> #info SB: pjones will to SWG and try to get clarification that expiration cannot be honored. 20:15:21 <pjones> USWG. 20:15:24 <mmaslano> abadger1999: please, FPC news? 20:15:28 <pjones> also a verb would be nice. 20:15:38 <mmaslano> #info SB: pjones will got to USWG and try to get clarification that expiration cannot be honored. 20:15:49 <abadger1999> FPC item 1: nodejs guideliens were approved contingent on a fesco multilib exepmtion 20:16:27 <abadger1999> nodejs wants to install and find modules in one path under /usr/lib rather than %{_libdir} which may be /usr/lib64. 20:16:52 <mitr> abadger1999: could you file a ticket with a link to the discussion/rationale? 20:17:00 <abadger1999> From what I understand, it should be a similar case to java which received a multilib exemption a few weeks ago. 20:17:23 <t8m> abadger1999, yes, given the java exception I am +1 to this as well 20:18:01 <mmaslano> +1 20:18:08 <abadger1999> mitr: I could but if you want an in depth analysis, you'd need tc hollingsworth and sgallagh to fill in the details. 20:18:23 * abadger1999 is inclined to just vote +1 now 20:18:37 * notting is +1 20:18:42 <abadger1999> and trust them when they think this is the best solution. 20:18:43 <mitr> give me a minute... 20:19:17 <nirik> +1 as well. 20:20:17 <sgallagh> The short version is that upstream is not multilib-aware (or actually is multilib-averse). 20:20:21 <mitr> all right, +1; the symlinking architecture doesn't really lend itself to multilib 20:20:31 <abadger1999> +1 20:21:18 <mmaslano> #agreed nodejs guideliens were approved contingent on a fesco multilib exemption, odejs wants to install and find modules in one path under /usr/lib rather than %{_libdir} which may be /usr/lib64 (+6,-0) 20:22:15 <mmaslano> abadger1999: and the second issue? 20:22:15 <abadger1999> FPC item 2: We passed the ruby guidelines with some modifications -- (I'll circle back with bkabrda to check on those) 20:22:25 <abadger1999> Athe fesco portion was: FPC noted mitr's feelings on rubypick overriding command line args vs only using environment variables but decided that due to how rubypick is used, it was something fesco should decide. 20:23:51 <abadger1999> We approved the ruby and jruby feature earlier so I don't know if we want to call that sufficient or discuss this specific aspect. 20:24:27 <sgallagh> mitr: Could you summarize the rubypick issue briefly? 20:24:40 <mmaslano> abadger1999: I guess it's your (fpc) problem now? 20:24:51 <t8m> if anybody wants to propose any concrete proposal related to the rubypick, please go ahead :] 20:24:56 <abadger1999> mmaslano: ? 20:25:24 <mitr> A. The *Ruby packaging guideliens itend to have a /usr/bin/ruby that works regardless of which interpreters are installed. This is "rubypick" 20:25:26 <mmaslano> abadger1999: well, you should work with them on correct packaging/guidelines. Is it rubypick part of it? 20:25:40 <t8m> mmaslano, I think if we don't agree on anything, the rubypick will be as is currently proposed 20:25:46 <abadger1999> The concrete proposal would be: modify rubypick to only use environment variables to switch between ruby guidelines; no command line args to switch allowed. 20:25:51 <t8m> by maintainers 20:25:52 <fenrus02> mitr, rubypick is the same as 'alternatives' ? 20:26:08 <mitr> B. There is a desire to let the users override the interpreter used when running a script, and (/path/to/ruby/implementation /full/path/to/script) is considered cumbersome 20:26:11 <fenrus02> ah, no. env based. 20:26:25 <mitr> C. Current rubypick allows doing this as "env_var=interpreter script_name" or "script_name _jruby_". 20:26:39 <mitr> My concern is that taking over command-line arguments like this is unexpected and generally a bad idea 20:26:58 <mitr> Proponents argue that there is prior art in rubygems, where similar syntax is used to specify a gem version IIRC 20:27:11 <mitr> That's about it I think 20:27:21 <t8m> abadger1999, I am +0 or even -1 to that 20:27:50 <sgallagh> Is rubypick something that one or both upstreams (ruby2 and jruby) are backing, or is it custom for Fedora? 20:27:53 <notting> abadger1999: the proposal is to deviate from upstream behavior? or is rubypick a fedora invention? 20:27:59 <abadger1999> sgallagh: custom to fedora. 20:28:06 <sgallagh> abadger1999: In that case: -1 20:28:10 <mitr> Fedora invention, https://github.com/bkabrda/rubypick https://github.com/bkabrda/rubypick/blob/master/ruby 20:28:11 <abadger1999> notting: same. it's a fedora invention. 20:28:59 <sgallagh> cumbersome but functional > easy but hard to predict 20:29:03 <abadger1999> sgallagh: wait, am I reading right, that you'd vote to change rubypick if it was an upstream behaviour? 20:29:13 <mitr> sgallagh: is that "-1 to modifying rubypick", or "-1 to taking over command-line arguments"? 20:29:21 <sgallagh> abadger1999: I'm voting against inclusion of rubypick 20:29:27 <abadger1999> ah... Hmm... 20:29:32 * mmaslano thinks we vote about abadger1999's proposal 20:29:42 <notting> abadger1999: so is this the equivalent of having /usr/bin/python alternatively call pypy or jython? 20:29:45 <abadger1999> So rubypick was somewhat essential to the jruby feature that we approved earlier... 20:29:45 <sgallagh> That they should behave like other languages and specify the interpreter properly in the script 20:30:13 <sgallagh> abadger1999: So have them use the 'alternatives' architecture to specify /usr/bin/ruby 20:30:19 <mmaslano> notting: it's not like python. rvm and jruby are compatible according to upstreams 20:30:26 <t8m> sgallagh, -1 to your proposal 20:30:32 <mitr> mmaslano: modulo binary extensions 20:30:40 <mmaslano> mitr: they are working too 20:30:51 <abadger1999> notting: yeah -- in python terms, we'd replace /usr/bin/python with a short wrapper that by default invoked /usr/bin/python2.7 but with an env var or CLI arg could call /usr/bin/pypy or /usr/bin/jython or /usr/bin/ironpython instead. 20:30:54 <mitr> mmaslano: wow. thanks for the correction 20:31:19 <mmaslano> mitr: according to maintainers rubygems, which we have are working. Upstreams were working on these issues 20:32:08 <abadger1999> mmaslano: It is like python -- but not python2 vs python3... we do have several implementations of the python-2 language. 20:32:16 <abadger1999> python, pypy, jython 20:32:35 * nirik isn't sure if there are concrete proposals pending... disallow env? 20:32:43 <abadger1999> nirik: the opposite. 20:32:46 <mmaslano> it's not, as I heard every python interpreter has a bunch of packages working only with the one interpreter 20:32:55 <abadger1999> disallow the command line switching... only use the env var switching. 20:32:56 <mmaslano> anyway, back to rubypick 20:33:02 <nirik> ah, ok. 20:33:05 <abadger1999> mmaslano: it is. 20:33:15 <nirik> as long as it's documented, I don't care if it's both. 20:33:15 <notting> so... 20:33:15 <abadger1999> mmaslano: But we're on a tangent :-) 20:33:24 <notting> why would i want ruby, and why would i want jruby? 20:33:27 <sgallagh> proposal: let them behave like any other language and either properly specify the interpreter in the hashbang or use alternatives 20:33:37 <notting> i.e., what's the point of randomly switching your interpreter? 20:33:56 <mmaslano> notting: well, some projects want to use it, for example clouds 20:34:10 <pjones> mmaslano: he asked why they want to do it, not what they want to do. 20:34:17 <mitr> (like in the mysql situation :) ) having a distribution-wide default against which applications are expected to be tested and working would generally be preferable 20:34:42 <t8m> sgallagh, -1 20:34:44 <pjones> mitr: but that would be the case even with the environment based switching 20:35:14 <mitr> pjones: sure; considering sgallagh wants to disable even that, I think we can't avoid the discussion 20:35:22 <pjones> true. 20:36:04 <mitr> mmaslano, abadger1999: what is the reason for the desire to use both? performace vs. "the traditional implementation"? Something else? 20:36:27 <mmaslano> I guess ruby programmers tend to switch from one to another 20:36:29 * abadger1999 can look in the ml archives for that answer unless mmaslano can give a summary. 20:36:53 <sgallagh> mmaslano: but *why*? What does jruby give them that rvm does not? And vice-versa 20:37:15 <mmaslano> I guess performance 20:37:16 <sgallagh> Or is it just a matter of "we want to test that what we write works on both, because both exist"? 20:37:22 <notting> looks like 'thread-safety and running on the JVM for better java interaction' 20:37:46 <mmaslano> sgallagh: I don't think so 20:38:06 <t8m> I suppose the rvm is more compatible and jruby more performing and better interacting w/ java 20:38:15 <mmaslano> JRuby is an alternative Ruby implementation with fast growing user base due to its great performance in parallel tasks. 20:38:19 <mmaslano> ^ feature page 20:38:24 <sgallagh> Either way, I don't really understand why they should get special env var treatment instead of behaving like our other interpreters. 20:38:38 * t8m really thinks this should be a Ruby SIG decision and FESCo should not interfere 20:38:40 <sgallagh> Especially since env vars make it harder to keep track of which one is active 20:38:41 <pjones> okay, so that does sound like something that a normal ruby developer may be considering, and thus expecting the ability out of our implementation. 20:39:08 <pjones> sgallagh: because we'd rather be inclusive of normal ruby developer expectations than exclusive of them 20:39:09 <mmaslano> there is also paragraph about "why not alternatives" 20:39:14 <sgallagh> The fact that this is a Fedora-centric feature and *not* part of upstream Ruby/Jruby concerns me 20:39:15 <t8m> pjones, +1 20:39:25 <mmaslano> pjones: +1 20:39:34 <sgallagh> pjones: Yes, except we established already that this is NOT normal ruby developer behavior. 20:39:38 <sgallagh> It's unique to Fedora 20:39:44 <pjones> well, the implementation isn't 20:40:06 <pjones> doesn't really simplify things, does it. 20:40:16 <mmaslano> sgallagh: because other linux distributions are not trying much to package it? 20:40:54 <mmaslano> normal ruby developer is developing on mac, they are trying to make developer experience on fedora better 20:40:59 <notting> so, essentially, reads as "use jruby if you want good threads and java support; use c-ruby if you want C extensions" 20:41:01 <abadger1999> http://lists.fedoraproject.org/pipermail/devel/2013-January/176796.html 20:41:49 <notting> and at least in the case of some IDEs, what they do is ask you upfront whether you want MRI (c ruby) or jruby 20:41:57 * abadger1999 thinks from that that the "wants to test on both" is closer to the truth. 20:42:05 <abadger1999> also "wants to deploy on one or the other" 20:42:32 <abadger1999> -- ie, My site has knowledge of jruby and deploys all its apps on jruby -- your site has knowledge of ruby-mri and wants to deploy on that. 20:42:54 * mitr will attempt to take a shortcut 20:42:56 * mitr Proposal: 1) taking over command-line arguments in rubypick is unwanted; 2) FESCo asks FPC and the feature owners to revisit whether the rationale for having two equally-supported switchable implementations is strong enough, and if they think so, to summarize their reasoning. 20:43:15 <mitr> abadger1999: Does both mri and jruby install to /usr/bin/ruby on other systems? 20:43:18 <mmaslano> mitr: +1 20:43:59 <abadger1999> mitr: FPC stepped out of that. just talk to the feature owners -- FPC will change the examples in the guidelines if command line args are removed from rubypick 20:44:31 <abadger1999> mitr: I don't know. will have to download some .debs to find that answer 20:44:39 <t8m> proposal: Leave things in jruby/ruby Features as they are now 20:45:08 <abadger1999> oh... wait, you're asking whether being switchable is okay... 20:45:13 <abadger1999> FPC said yes -- 20:45:34 <abadger1999> it makes the packaging burden smaller in some ways (one package to serve multiple interpreters) 20:46:01 <abadger1999> and if they're mostly compatible, there's not a strong reason not to share the modules. 20:46:35 <sgallagh> abadger1999: not just switchable but "equally-supported" 20:46:36 <abadger1999> the switching of interpreters for apps is similar in concept to alternatives and envirnoment-modules which we currently allow. 20:46:52 <sgallagh> But yeah, that I don't have a problem with. 20:46:57 <abadger1999> sgallagh: Define supported :-) 20:47:15 <sgallagh> Frankly, I'm tired of this discussion, so I'm going to just sit back and abstain from further comments. 20:47:31 <abadger1999> One of the changes FPC decided needed to be there is that unittests ned to be run on all the interpreters that are sharing code, not just on one of them. 20:47:44 * nirik has been in that boat for a while. I'm really finding it hard to get worked up over this. 20:47:52 <abadger1999> I think that's about as into the definition of "supported" as FPC usually gets. 20:48:16 <abadger1999> default application sets and such is something that usually is a fesco decision rather than fpc. 20:48:35 <abadger1999> (for instance, what services can be started after install) 20:48:56 <mitr> sgallagh, abadger1999: so it's the three of us, and everyone is tired about arguing alternatives/rubypick/default? 20:49:08 <mitr> let's leave that to the feature owners perhaps, and just take the command line part? 20:49:35 * abadger1999 would love to avoid discussing #2 again :-) 20:49:41 <nirik> I don't see the great danger of the command line switching either... what problem does that cause? 20:49:48 <t8m> nirik, +1 20:49:49 <sgallagh> Yes, let us never speak of this again. 20:50:10 <mitr> lol 20:50:26 <notting> i have definitely hit the point of decision fatigue here. i'm +1 to trust the domain experts . it will be their own bed of rubies to clean up if it goes wrong anyway 20:50:43 <abadger1999> command line switching seems to be an essential part of the jruby feature we approved. 20:50:45 <mmaslano> notting: +1 20:50:59 <abadger1999> so I wouldn't want to tlak about that again either :-) 20:51:06 <mmaslano> so say +1 20:51:17 <pjones> notting: oh, yes. quite. +1 20:51:28 * nirik nods. agreed. 20:51:38 <t8m> notting, +1 20:51:46 <nirik> how about people with concrete proposals bring them to us later when they have them written up? 20:51:57 <abadger1999> the only question that leaves is mitr's #1 -- command line arguments when taking over /usr/bin/ruby 20:52:17 <abadger1999> nirik: Sounds good. mitr, want to take that as an action item for next week? 20:52:21 <t8m> abadger1999, I think this is implicitly approved - left to domain experts 20:52:46 <t8m> and we will have enough features next week :) 20:53:07 <mmaslano> #agreed rubypick will be implemented as proposed by domain experts in JRuby feature (+5,-0) 20:53:42 <mmaslano> close the meeting in 1 minute 20:54:06 <mitr> abadger1999: will do 20:54:15 <mmaslano> #endmeeting