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