Summary/Minutes from Wednesday's FESCo meeting (2013-09-25)
tmraz at redhat.com
Thu Sep 26 08:10:43 UTC 2013
#fedora-meeting: FESCO (2013-09-25)
Meeting started by t8m at 18:01:13 UTC. The full logs are available at
* init process (t8m, 18:01:59)
* #1173 provenpackager request for vicodan (t8m, 18:05:31)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=891282#c10
* AGREED: close ticket and ask if anyone sees misuse of powers, let us
know (+8 if I count nirik's own implicit, -0, 0:0) (t8m, 18:15:29)
* AGREED: change text to: "A FESCo member will send an e-mail to the
sponsors list for the packager group to review the application.. You
must get at least 3 positive votes with no negative votes, over a
one week review period, to be automatically approved.. In case of
negative votes, after that period FESCo will vote at one of its
weekly meetings on your request and then notify you if your request
has been approved." (+9, -0, 0) (t8m, 18:19:45)
* #1175 SCLs -- FPC questions on backwards compat (t8m, 18:20:21)
* AGREED: it is okay for people maintaining an SCL to guarantee
backwards compatibility, or to make a separate SCL for backwards (or
forwards) compatibility. (+9, -0, 0) (t8m, 18:40:21)
* AGREED: A SCL when proposed must document it's purpose, including
what API/ABI promises to provide to packages outside of the SCL; it
is then expected to maintain that promise [and that compatibility
promise only] (+8, -0, 0) (t8m, 18:58:28)
* Next week's chair (t8m, 19:04:04)
* ACTION: mitr to chair next week (t8m, 19:05:12)
* Open Floor (t8m, 19:05:23)
Meeting ended at 19:09:00 UTC.
* mitr to chair next week
Action Items, by person
* mitr to chair next week
People Present (lines said)
* abadger1999 (56)
* t8m (54)
* mitr (41)
* mattdm (38)
* sgallagh (32)
* pjones (32)
* notting (30)
* mmaslano (23)
* nirik (22)
* cwickert (7)
* zodbot (6)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
18:01:13 <t8m> #startmeeting FESCO (2013-09-25)
18:01:13 <zodbot> Meeting started Wed Sep 25 18:01:13 2013 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:28 <sgallagh> Hello folks. I'm back.
18:01:30 <t8m> #meetingname fesco
18:01:30 <zodbot> The meeting name has been set to 'fesco'
18:01:46 <t8m> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:01:46 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:01:59 <t8m> #topic init process
18:02:04 <nirik> morning everyone
18:02:11 <t8m> hello all
18:02:13 * abadger1999 here
18:02:27 <mitr> Hello all
18:02:31 <pjones> hello.
18:03:00 <notting> hello
18:03:05 * pjones notes that he has a hard stop at 2:45 on wednesdays for the foreseeable future :/
18:04:16 <sgallagh> I have a hard stop at 3:00 today as well, FWIW
18:04:55 <t8m> I think we can start now
18:04:59 <mattdm> hi
18:05:07 <mattdm> (sorry internet trouble blah blah blah)
18:05:31 <t8m> #topic #1173 provenpackager request for vicodan
18:05:40 <mmaslano> hi :)
18:05:44 <t8m> .fesco 1173
18:05:45 <zodbot> t8m: #1173 (provenpackager request) â€“ FESCo - https://fedorahosted.org/fesco/ticket/1173
18:05:49 <mmaslano> I forgot to join channel...
18:05:57 <pjones> On the one hand (and sorry for missing last week but I was at two conferences at once), I really don't think the bugs cited were good justification for PP status
18:06:06 <abadger1999> no problem -- we're on the first topi :-)
18:06:25 <pjones> On the other hand, we've already done the deed. Why not give him the opportunity to rise to the occasion?
18:06:47 <t8m> I did not change my position since the last week - that is no revocation unless he behaves badly
18:07:21 <t8m> So if nobody wants to propose we should revoke his PP status we could move on.
18:07:21 <nirik> I think cwickert was going to add some bugs supporting his position, but I don't know that that happened.
18:07:21 <sgallagh> t8m: I agree.
18:07:45 <pjones> nirik: I don't think that changes what I've just said, though?
18:07:53 <nirik> no, just mentioning it.
18:08:04 <abadger1999> wolfgang (raveit65) spoke favorably so I don't think I've changed my mind
18:08:05 <pjones> I mean, we've certainly all had issues with him in the past, but that includes e.g. rex, who thinks he's gotten a lot better.
18:08:21 <pjones> likewise wolfgang.
18:08:51 <nirik> yeah, so proposal: close ticket and ask if anyone sees misuse of powers, let us know.
18:08:57 <pjones> nirik: +1
18:09:00 <mitr> dan408 is by now certainly very aware that people will be watching
18:09:03 <mitr> +1
18:09:06 <t8m> nirik, +1
18:09:09 <mattdm> +1
18:09:16 <abadger1999> nirik: +1
18:09:35 <sgallagh> nirik: +1
18:09:39 <mmaslano> +1
18:09:42 <cwickert> well, there is one bug linked
18:09:48 <abadger1999> Should we do anything about the "fesco decided the first time before 7 days had passed"? I think it was just an oersight on our part.
18:10:02 <t8m> abadger1999, yep, it was an oversight
18:10:17 <notting> abadger1999: that's on me. i thought the policy was 'a week for feedback, but immediately escalates on -1'
18:10:22 <cwickert> https://bugzilla.redhat.com/show_bug.cgi?id=891282#c10
18:10:26 <pjones> I think it was an oversight, but... we've still got consensus I think, so we really just need to be more careful in the future.
18:10:59 <abadger1999> <nod>
18:11:06 <mitr> My reading of the provenpackager policy isn't that we have to wait a week for the feedback.
18:11:08 <cwickert> I think Wolfgang is very clear in that bug I just linked
18:12:04 <t8m> cwickert, but this still isn't overuse of powerpackager powers
18:12:10 <t8m> provenpackager that is
18:12:25 <mitr> cwickert: But then his https://fedorahosted.org/fesco/ticket/1173?action=comment-diff&cnum=22&version=3 supports other interpretations...
18:12:26 <t8m> just sloppines
18:12:34 <cwickert> t8m: true, but it's not something that qualifies for proven packagere I think
18:12:54 <cwickert> mitr: "You must get at least 3 positive votes with no negative votes, over one week." <-- I read that as "sponsors must be given one week to respond"
18:13:19 <t8m> that's debatable
18:13:38 <pjones> t8m: yes, but when that sort of language is debatable we should opt towards the broader interpretation
18:13:51 <t8m> pjones, no problem with that
18:13:58 * nirik isn't clear on the problem in that ticket. There's 2 dependent reviews, do they contain that missing thing?
18:14:33 <notting> pjones: i can edit it to clarify that now
18:15:28 <pjones> cwickert: in any case it would be "sponsors /should/ be given one week to respond"; fesco still has the power to grant it even if all the sponsors say no, though it wouldn't be our best move ever.
18:15:29 <t8m> #agreed close ticket and ask if anyone sees misuse of powers, let us know (+8 if I count nirik's own implicit, -0, 0:0)
18:16:30 <mitr> I wouldn't mind an addendum of "FESCo recommends Dan to be extra careful when using the provenpackager powers" if that made anybody happy, though it isn't adding anything new strictly speaking
18:16:46 <pjones> mitr: I can be +1 to that.
18:16:49 <notting> proposal: change text to: "A FESCo member will send an e-mail to the sponsors list for the packager group to review the application.. You must get at least 3 positive votes with no negative votes, over a one week review period, to be automatically approved.. In case of negative votes after that period, FESCo will vote at one of its weekly meetings on your request and then notify you if your request has been approved."
18:16:49 <t8m> mitr, I think that is implicit and unnecessary
18:16:59 <notting> (in the policy)
18:17:08 <nirik> notting: +1
18:17:09 <t8m> notting, +1
18:17:19 <mmaslano> notting: +1
18:17:22 <sgallagh> notting: +1
18:17:27 <mattdm> notting: +1
18:17:36 <sgallagh> mitr: -1 I don't think we need to call him out as an exception.
18:17:37 <cwickert> pjones: true that, but I think a very fundamental rule of Fedora is to trust the right people, in this case the sponsors. I think whoever has not been working with the person in question needs to trust others who have
18:17:37 <pjones> notting: +1
18:17:51 <sgallagh> Anyone that misuses pp powers should have them revoked
18:17:51 <pjones> cwickert: I certainly agree.
18:17:57 <cwickert> cool, eof
18:18:06 <mitr> notting: +1
18:18:10 <abadger1999> notting: +1 but one grammar change: In case of negative votes, after that period FESCo will
18:18:24 <notting> abadger1999: wfm. done.
18:18:46 <t8m> notting, do you vote for yourself?
18:18:51 <notting> t8m: yes.
18:18:52 <pjones> abadger1999: yeah, that does make a difference doesn't it ;)
18:18:54 <notting> (in this case)
18:19:30 <abadger1999> yep :-)
18:19:45 <t8m> #agreed change text to: "A FESCo member will send an e-mail to the sponsors list for the packager group to review the application.. You must get at least 3 positive votes with no negative votes, over a one week review period, to be automatically approved.. In case of negative votes, after that period FESCo will vote at one of its weekly meetings on your request and then notify you if your request has been approved." (+9, -0, 0)
18:19:54 <t8m> next topic
18:20:21 <t8m> #topic #1175 SCLs -- FPC questions on backwards compat
18:20:27 <t8m> .fesco 1175
18:20:28 <zodbot> t8m: #1175 (SCLs -- FPC questions on backwards compat) â€“ FESCo - https://fedorahosted.org/fesco/ticket/1175
18:21:01 <mattdm> does everyone have the background on this one?
18:21:12 <t8m> So I think the discussion is not finished yet in the ticket
18:21:19 <nirik> so, I'm a bit confused on scope here... FPC wants fesco to say what specific use cases we want to allow so they can craft guidelines for that?
18:21:27 <abadger1999> A few days ago I thought approving something along the lines of notting + mattdm's comment would work. But bkabrda's comment makes me retract that thought :-(
18:21:28 <t8m> or does anyone have anything to add? or proposal to vote on?
18:21:51 <abadger1999> nirik: Well -- we've identified some use cases so that we can make the guidelines make sense for them.
18:22:09 <pjones> abadger1999: but you're asking about either/or, not both, right?
18:22:54 <abadger1999> nirik: and one of the use cases is give developers a stable (API-wise) platform even though Fedora changes underneath that platform.
18:23:17 <mattdm> t8m I would like to at least vote on the the proposal I suggested in the ticket
18:23:36 <mitr> As long as we are thinking about some kind of matt's proposal, I'd like to use FESCo's (small?) ability to say something people will tend to listen to, to say:
18:23:38 <mitr> Proposal: FESCo thinks that an appropriate level of backward compatibility in API interfaces is primarily an upstream's responsibility, and upstreams _should_ take that into account when designing and maintaining their APIs.
18:23:39 <abadger1999> Ideallyy people would like to see an scl that has 100% backwards compatibility for that.
18:23:43 <mattdm> in talking to people at conferences and meetups about fedora cloud, anything which helps with that would be welcome.
18:24:02 <mattdm> mitr -1: upstreams don't do that.
18:24:10 <pjones> mattdm: I, for one, am completely confused as to how your proposed statement answers whatever question has been asked.
18:24:18 <pjones> mattdm: but that might be because I can't figure out the question.
18:24:22 <mitr> mattdm: This is a "should", not a "required", or "if you don't this Fedora won't work with you"
18:24:36 <mitr> All of SCLs is basically workarounds for upstreams...
18:24:36 <abadger1999> but the problem is that if we craft guidelines to meet that (and all the negatives that that has) then we're making the other use cases much harder to implement.
18:24:54 <t8m> mitr, I am afraid this is so purely declarative it won't have any effect
18:25:04 <mattdm> pjones in the FPC meeting, there was strong sentiment that fedora's policy is to always and only package the latest versions of everything.
18:25:05 <notting> mitr: i agree, but we don't have leverage for that proposal to mean much
18:25:23 <t8m> mitr, we can vote that we'd like all the wars in the world stop but will it have any effect?
18:25:27 <mitr> notting: At least, it's something a package maintainer can point upstreams to if the upstreams are new/uncertain
18:25:37 <pjones> mattdm: obviously we should just have a vote on jettisoning that as a policy in general and allow compat packages ;)
18:25:50 <sgallagh> mattdm: A fact which is tempered by the decisions of the individual maintainers, of course.
18:25:55 <abadger1999> <nod> mattdm's statement would help answer one of the questions. Although I'd prefer something more direct.
18:25:56 <mmaslano> mitr: they often don't care
18:25:59 <notting> mitr: "You see how Google handles API/ABI compat? Don't do that."
18:26:12 <sgallagh> For example, I've got a couple packages I'm intentionally holding back because I know they broke other stuff.
18:26:26 <pjones> sgallagh: as do I
18:26:34 <mitr> abadger1999: BTW I don't like the "100%" in these discussions - it leads to ratholes like bug-for-bug compatibility
18:26:35 <notting> pjones: i was thinking of things like v8 that randomly change ABI in minor releases
18:26:49 <mattdm> pjones: that's fine too if people are willing to do the work for maintaining them. it becomes hard when there are many interrelated packages in a language stack. SCL isn't perfect, but it attempts to address that.
18:27:19 <abadger1999> mitr: well -- that would be another thing to discuss... I've been assuming that the scl people wanted bug-for-bug compat in some cases.
18:28:12 <mmaslano> could we at least agreed on some way for SCL?
18:28:14 <mitr> abadger1999: " but the problem is that if we craft guidelines to meet that (and all the negatives that that has) then we're making the other use cases much harder to implement" what's this about?
18:28:15 <abadger1999> (ie: let the scl maintainer decide not to fix bugs because their evaluation is that the bug is something that some people depend on)
18:28:20 <nirik> SCL's will still need maintaining too. ;) it's not made of unicorn dust. ;)
18:28:31 <notting> the problem is that there are a variety of interrelated issues here . for example, it may be good to have a 'python-for-the-system' and 'python-for-your-apps', and SCLs solve that. we may additionally want that 'python-for-your-apps' to be fixed at a version longer than we'd do it for 'python-for-the-system', and that could be seen as a question independent of SCL packaging
18:28:38 <abadger1999> mitr: So I tried to talk about it with the thin vs thick scl portion.
18:28:49 <mitr> abadger1999: I can imagine giving a maintainer that kind of freadom, but it should not be a _requirement_ to be a SCL
18:29:03 <mattdm> nirik yes, but we have unicorn-wranglers interested in doing it.
18:29:32 <abadger1999> mitr: If SCLs must guarantee 100% backwards compat then having thick scls where many different packages are in one scl seems unmaintainable. and combinatorily expensive.
18:29:41 <abadger1999> So instead I think we should have thin scls.
18:29:54 <notting> mattdm: tbf, i think we have people interested in other people being unicorn-wranglers for them
18:29:58 <pjones> abadger1999: it seems like the answer there is that an SCL is like a distro. You need newer versions? Switch to the newer version of the SCL.
18:30:07 <mmaslano> abadger1999: I agree if we can get rid off thin/thick terminology :)
18:30:11 <notting> abadger1999: is 'thin' and 'thick' an upstream SCL concept?
18:30:15 <abadger1999> where a rails3 SCL would depend on the Ruby193 SCL, for instance. and each of those scls could be deprecated on a different schedule.
18:30:29 <abadger1999> notting: it's not.
18:30:38 <abadger1999> notting: but I don't have better terms at the moment.
18:30:57 <nirik> thin -> one package/thing. thick -> a bunch of things that are in the same SCL
18:31:12 <mitr> nirik: where "thing" may be "all gems"?
18:31:13 <sgallagh> abadger1999: That gets REALLY hard if we start talking about things like RDO
18:31:32 <abadger1999> mitr: but if we have thin scls, then things that we want in an scl that have many many packages in a stack on top of it become.... expensive.
18:31:33 <nirik> not in my mind... no.
18:31:35 <sgallagh> Where we end up talking about dozens of "thin" SCLs for each RDO release
18:31:57 <mmaslano> why are we even speaking about dozens of scls?
18:31:58 <abadger1999> sgallagh: I don't know what RDO is but I think you're giving an example of the problem I just stated. Correct?
18:32:13 <sgallagh> abadger1999: "Red Hat Distribution of OpenStack"
18:32:24 <notting> sgallagh: it does not stand for that
18:32:26 <abadger1999> pjones: re: newer version of hte SCL -- not if there's 100% backwards compat.
18:32:39 <nirik> mmaslano: because isolating each thing to their own SCL solves some issues... and makes others. ;)
18:32:41 <abadger1999> pjones: you'd need a new SCL, not a newer version of the SCL.
18:32:59 <sgallagh> notting: That's how I heard it. My apologies if that's incorrect.
18:33:15 <pjones> abadger1999: that's the same thing in my mind ;)
18:33:20 <abadger1999> newer versions of the same SCL would only be able to add api and fix things that didn't affect the API (as te maintainer interprets it).
18:33:28 <abadger1999> pjones: they're different though
18:33:33 <abadger1999> you'd need a new name, for one thing.
18:33:34 <sgallagh> abadger1999: Maybe GNOME and KDE are a better example
18:33:35 <pjones> sure, I see the distinction your making.
18:33:51 <pjones> I don't think that changed my point at all.
18:34:00 <sgallagh> They are both considered a single entity, though composed of many individual packages that are expected to be upgraded more or less in lockstep
18:34:05 <pjones> You're just using the word "version" 90-degrees orthogonal to my expectation.
18:34:06 <mattdm> nirik right, SCL isn't a perfect solution. but it's one I'd like to explore as an option
18:34:34 <abadger1999> ruby1.9.3 , ruby1.9.3-updated-rails, ruby1.9.3-updated-rails-and-mintest, and so on.
18:35:29 <mitr> ... what question are we trying to answer by this discussion ... ?
18:36:04 <mmaslano> fpc asked if fesco says it's okay to have scl for backward compatibility
18:36:05 <mattdm> mitr: first, is packaging for backwards compatibility acceptable in fedora?
18:36:26 <mitr> mattdm: Proposal: "yes, because upstreams don't do it and we need to have it".
18:36:28 <mitr> Next?
18:36:29 <mmaslano> could we answer this question first?
18:36:32 <pjones> mmaslano: if that's the question, the answer should be "yes".
18:36:44 <mitr> s/upstreams/some upstreams/
18:36:45 <nirik> I guess I'm ok with that... although when should a SCL be used over a compat package? or maintainers choice?
18:37:05 <mmaslano> pjones: I guess that was output from 2 hours discussion on fpc
18:37:05 <abadger1999> I think one fpc members asked if it's okay for scls to guarantee 100% backwards compat. I would say yes as the answer to that.
18:37:17 <mattdm> nirik there are actually some guidelines for the cases when an scl should be used
18:37:28 <abadger1999> (which is basically what mattdm's statement does).
18:37:32 <nirik> mattdm: proposed guidelines you mean? ;)
18:37:36 <mitr> abadger1999: to that subquestion, "foolish but not forbidden" IMHO
18:37:38 <pjones> Proposal: it is okay for people maintaining an SCL to guarantee backwards compatibility, or to make a separate SCL for backwards (or forwards) compatibility.
18:37:43 <notting> abadger1999: for values of 100% slightly less than 100, sure!
18:37:43 <abadger1999> mattdm, nirik: Or at least, FPC is trying to evaluate those :-)
18:37:55 <notting> pjones: +1
18:37:58 <mmaslano> pjones: +1
18:37:59 <nirik> sure. +1
18:38:05 <abadger1999> +1
18:38:06 <mattdm> +1
18:38:07 <mitr> pjones: +1
18:38:19 <t8m> pjones, +1
18:38:29 <mattdm> do we want to vote on my substantially-wordier proposal in the ticket?
18:38:42 <t8m> mattdm, I'd +1 to that as well
18:38:43 <abadger1999> Second question would be "do we have to require that scls be 100% backwards compatible?"
18:38:46 <mattdm> it says the same thing but with more pontificating
18:38:56 <mmaslano> please do so, otherwise it will be another fpc meeting without speaking about guidelines...
18:38:59 <sgallagh> pjones: +1
18:39:03 <mattdm> okay so: proposal:
18:39:05 <mattdm> The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community. The values of "features" and "first" underpin this goal of advancement, and historically we have concentrated on packaging the newest possible versions of software with an explicit non-concern for backwards compatibility. However, this does not mean that we shun efforts to
18:39:08 <mattdm> provide that compatibility. To the contrary, giving our users a compatibility path provides additional freedom to move quickly without disruption. If Fedora subprojects or packagers are interested in providing and maintaining software stacks which provide backwards or forwards compatibility and can commit the resources required to do so, such effort is very welcome.
18:39:51 <mitr> mattdm: I agree with the substance; I don't really like that doing such effort _within Fedora_ is "welcome"; it's a painful fallback option.
18:39:54 <t8m> pjones, do you vote for yourself?
18:39:57 <pjones> t8m: I do
18:40:21 <t8m> #agreed it is okay for people maintaining an SCL to guarantee backwards compatibility, or to make a separate SCL for backwards (or forwards) compatibility. (+9, -0, 0)
18:40:36 <sgallagh> mitr: It's painful, but we really can't keep putting our hands over our eyes and pretending that the latest-and-greatest works for everyone
18:40:43 <abadger1999> mattdm: really, I don't care if someone wants to say that... but it's the same a pjones' much more succinct statement so if we were to say, this is what we want, I prefer the shorter version.
18:40:53 <mitr> sgallagh: oh, definitely; it's a wording matter and I don't have a counterproposal.
18:40:53 * pjones has to go
18:40:58 <t8m> mitr, if anybody volunteers for that why wouldn't we welcome him?
18:41:25 <notting> t8m: at certain levels, sure. but i think we'd vote down someone wanting to ship a 2.2 kernel
18:41:30 <pjones> t8m: it's not necessarily isolated - does SRT need to be involved, for example?
18:41:40 <notting> (ok, reducto ad absurdium)
18:41:42 <sgallagh> I'm good with the pjones version, myself. The wordier version doesn't really add anything
18:41:51 * pjones really goes.
18:41:59 <t8m> notting, sure
18:42:05 <mattdm> okay, works for me. it's just there in case anyone really feels the need for more verbiage
18:42:26 <abadger1999> mmaslano: heh, you are an optimist if you think we'll actually get to guidelines tomorrow :-/ (Maybe you and I should talk about how we could slice the guidelines up into smaller portions and do one chunk per FPC meeting)
18:42:48 <mmaslano> abadger1999: yes, that would be good
18:43:16 <mattdm> okay, so is there another vote here that would be helpful?
18:43:42 <sgallagh> mattdm: Proposal: Let's have beer at the meetings?
18:43:45 <nirik> the second item abadger1999 mentioned?
18:43:55 <notting> sgallagh: +1
18:44:11 <mmaslano> sgallagh: you are making fun of it, but I don't want to spend another meeting about if we want scl at all...
18:44:23 <mattdm> "do we have to require that scls be 100% backwards compatible?"
18:44:26 <abadger1999> Second question would be "do we have to require that scls be 100% backwards compatible?"
18:44:37 <mitr> Proposal: absolutely not
18:44:42 <t8m> mitr, +1
18:44:46 <sgallagh> mmaslano: No, I get that. His question was open-ended, so I was just making a joke.
18:44:50 <sgallagh> I agree, let's get this over wirh
18:45:00 <mitr> (... SCLs _should_ document what exactly they provide that is different fro mFedora Commons, though)
18:45:03 <sgallagh> mitr: +MANY
18:45:13 <notting> abadger1999: what do you mean by that? if you mean "the python3 scl should be "python33" or "python34" instead of python3, yes.
18:45:17 <nirik> how we would even test/do that?
18:45:25 <mattdm> +1 each scl needs to document its goals and any guarantees.
18:45:46 <mitr> I'm really not sure whether we should be requiring FESCo approval/ack/notification about adding a SCL
18:45:55 <t8m> mattdm, +1
18:46:02 <abadger1999> notting: is that a question about what 100% backwards compat means or a question about something else?
18:46:07 <nirik> sure, but I think FPC will generate in guidelines some general expectations...
18:46:16 <notting> abadger1999: yes, i think it's the first
18:46:26 <nirik> abadger1999: do you have any examples?
18:46:30 <mattdm> mitr: if FPC feels more comfortable with FESCo ack as a first pass, i think we can probably do that until the concept is proven to be less scary.
18:46:54 <notting> do they need to be 100% backwards compatible? no. but i also think, if someone is building something on top of your SCL, you're doing it because you expect it to be a platform for you. so it shouldn't randomly change.
18:47:21 <mitr> mattdm: right
18:47:27 <nirik> notting: +1
18:47:32 <mmaslano> no ABI breakage, but minor updates would be fine
18:47:35 <t8m> notting, definitely - it should stick to the purpose as defined when the scl is established
18:47:41 <abadger1999> I would say yes -- but do note that that is a simplistic example. If we shipped a python3.3 SCL and there was python3.3-pycurl package in the scl, we wouldn't be able to update that pycurl package in a backwards incompatible manner either.
18:48:07 <abadger1999> notting: : ^ That was about how to read "100% backwards compat"
18:48:10 <sgallagh> Proposal: An SCL should strive for API/ABI compatibility, and if this breaks should consider doing so as a new SCL
18:48:19 <mitr> mmaslano: "... as the ABI was defined within the documentation of that SCL, including possibly an empty set"
18:48:48 * abadger1999 notes that mitr's proposal and notting's vote are opposites.
18:48:49 <mitr> sgallagh: -1. RDO again?
18:48:55 <sgallagh> Intentionally not definitive, as there may be cases where some mostly unused feature is dropped
18:49:17 <sgallagh> mitr: Sorry, I should maybe clarify.
18:49:38 <t8m> sgallagh, -1
18:49:39 <sgallagh> I meant API/ABI that is depended on by other packages.
18:49:51 <sgallagh> But you're right, the RDO case gets hairy.
18:50:00 <mitr> sgallagh: s/API.../promised API/, is a difference
18:50:05 <sgallagh> But I'm thinking that each major release of something like RDO would probably be a new set of SCLs
18:50:18 <sgallagh> mitr: Right, promised-and-public
18:50:27 <abadger1999> mitr, mattdm: after the meeting if you could tell me how you envision an scl documenting it's guarantees that would help prepare me for tomorrow's FPC meeting.
18:51:12 <mitr> Proposal: A SCL when proposed must document it's purpose, including what API/ABI promises to provide to packages outside of the SCL; it is then expected to maintain that promise [and that compatibility promise only]
18:51:19 <mattdm> abadger1999 sure
18:51:38 <mitr> s/it's/its/, oops
18:51:42 <notting> mitr: +1. i'd add that we suggest they define some level of compatibility at some level that they intend to keep, otherwise they're kinda useless
18:51:52 <mattdm> notting +1
18:52:25 <abadger1999> notting: well -- not always. there's also the case of an scl being the method of enabling an application we want to ship in Fedora.
18:52:27 <mitr> notting: I'm not sure what "mysql40" would do. saying "we support the 4.0 protocol over TCP/IP" is one way to answer
18:52:32 <notting> example: a xulrunner SCL
18:52:34 <mmaslano> mitr: I would agree if I know what will be the promise
18:53:11 <notting> mitr: 4.0 protocol and X version of C library ABI, for example
18:53:13 <abadger1999> mitr: +1
18:53:26 <t8m> mitr, +1
18:53:38 <mitr> mmaslano: that's up to the maintainers of the SCL. e.g. a "ruby19" SCL would be promising a "Ruby language implementation, libruby* API, as defined by upstream for that release branch"
18:53:48 <mmaslano> mitr: ok, +1
18:53:50 <mitr> notting: ok
18:54:09 <mattdm> i think this part is more fpc than fesco, but i'd suggest that as a first pass we look at providing language stacks for users and developers building _on_ fedora and not things packaged _in_ fedora
18:54:11 * nirik is ok with that
18:54:49 <mattdm> (and deal with that next logical step as a... more complicated step.)
18:54:52 <mitr> mattdm: That might make the politics easier, but honestly I'm fairly certain that's untenable
18:55:01 <abadger1999> mattdm: Yeah, bring that up with fpc when hte time is right... but hte danger is language stack vs platform stack.
18:55:27 <mattdm> mitr: explain?
18:55:30 <abadger1999> mattdm: ie: you'd exclude rails and openstack in that first pass if you do that.
18:55:37 <mmaslano> abadger1999: do we have more questions from fpc?
18:55:42 <abadger1999> mattdm: which may not be a bad thing for the first pass, though :-)
18:55:45 <mattdm> abadger1999 okay fair enough -- i want rails included.
18:56:08 <abadger1999> t8m: do we have enough votes on mitr's proposal?
18:56:15 <mitr> mattdm: If we package any rails applications at all, we _will_ end up with some choosing to stay behind
18:56:24 <mattdm> i actually feel a bit of urgency about rails since 4 is a feature
18:56:33 <t8m> abadger1999, I don't think so?
18:56:51 <mattdm> sorry, what was the proposal again?
18:56:58 * sgallagh has a hard stop in five minutes.
18:57:06 <abadger1999> [11:51:12] <mitr> Proposal: A SCL when proposed must document it's purpose, including what API/ABI promises to provide to packages outside of the SCL; it is then expected to maintain that promise [and that compatibility promise only]
18:57:07 <mattdm> there have been a lot of +1s going by :)
18:57:12 <t8m> or maybe we do if we count notting's
18:57:14 * mitr is +1 to himself
18:57:23 <mattdm> mitr +1 (if I didn't already)
18:57:31 * notting is +1 to mitr's proposal
18:57:45 <abadger1999> I ocunt +5 with mitr: notting, mitr, t8m, mmaslano, abadger1999 (and now mattdm makes +6)
18:57:46 * mmaslano already said +1 to mitr's proposal
18:57:48 <nirik> I'm +1
18:57:50 <t8m> yep
18:57:58 <sgallagh> mitr: +1
18:58:05 <notting> may wnt to note that compatibility promises *should* only expand over the life of a SCL, not contract. or is that obvious?
18:58:25 <abadger1999> Wha6t's contract in tihis case? and what's life of an SCL?
18:58:28 <t8m> #agreed A SCL when proposed must document it's purpose, including what API/ABI promises to provide to packages outside of the SCL; it is then expected to maintain that promise [and that compatibility promise only] (+8, -0, 0)
18:59:19 <notting> abadger1999: just saying that going from "we support all our ABIs 100%" initially to "we support only these 5 ABIs 100%" 6 months later in a SCL would be... rude.
18:59:29 <mitr> notting: Given the volunteer nature of Fedora, making any kind of promises for the future is somewhat tricky
18:59:37 <mmaslano> abadger1999: I proposed - life of SCL - similar as other packages, only maintainer must warn about orphaning SCL in advance
18:59:38 * sgallagh departs
18:59:50 <abadger1999> notting: ah. yeah, that was implicit in my thoughts. FPC can make that explicit.
19:00:18 <mattdm> all of the promises fedora makes are best-effort promises.
19:00:37 <notting> mmaslano: one release in advance, or...?
19:01:01 <mmaslano> notting: one Fedora release would make sense.
19:01:24 <mmaslano> so people have time to move on or take the scl
19:02:27 <mattdm> i don't think we need to figure out the exact details here
19:02:42 <abadger1999> sgallagh: Side note -- v8 does not seem like it would fit under the current proposed criteria for SCLs but we could refine that (it's still very much under discussion). We should discuss that later too.
19:03:19 <abadger1999> I think that's all I need from fesco for this week.
19:03:30 <abadger1999> I'll open a new ticket if we need more for next week.
19:03:41 <mattdm> thanks abadger1999!
19:03:53 <t8m> thanks
19:04:04 <t8m> #topic Next week's chair
19:04:30 <t8m> Anybody volunteers
19:04:50 <t8m> I probably won't be able to attend next week
19:04:52 <mitr> I can do that
19:05:12 <t8m> #action mitr to chair next week
19:05:23 <t8m> #topic Open Floor
19:06:25 <t8m> Does anybody have anything for Open Floor?
19:06:27 <t8m> if not
19:06:34 * nirik does not
19:06:40 <t8m> I'll close the meeting in two minutes
19:09:00 <t8m> #endmeeting
No matter how far down the wrong road you've gone, turn back.
(You'll never know whether the road is wrong though.)
More information about the devel