#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
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
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 -
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
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
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,
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
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
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
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 -
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,
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
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
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
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
18:28:38 <abadger1999> mitr: So I tried to talk about it with the thin vs thick scl
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
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
18:30:11 <notting> abadger1999: is 'thin' and 'thick' an upstream
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
18:32:59 <sgallagh> notting: That's how I heard it. My apologies if that's
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
18:36:05 <mattdm> mitr: first, is packaging for backwards compatibility acceptable
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
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
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)
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
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
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
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
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,
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
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
18:48:07 <abadger1999> notting: : ^ That was about how to read "100% backwards
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
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
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,
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
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
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.)