18:01:13 #startmeeting FESCO (2013-09-25) 18:01:13 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:28 Hello folks. I'm back. 18:01:30 #meetingname fesco 18:01:30 The meeting name has been set to 'fesco' 18:01:46 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:01:46 Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:01:59 #topic init process 18:02:04 morning everyone 18:02:11 hello all 18:02:13 * abadger1999 here 18:02:27 Hello all 18:02:31 hello. 18:03:00 hello 18:03:05 * pjones notes that he has a hard stop at 2:45 on wednesdays for the foreseeable future :/ 18:04:16 I have a hard stop at 3:00 today as well, FWIW 18:04:55 I think we can start now 18:04:59 hi 18:05:07 (sorry internet trouble blah blah blah) 18:05:31 #topic #1173 provenpackager request for vicodan 18:05:40 hi :) 18:05:44 .fesco 1173 18:05:45 t8m: #1173 (provenpackager request) – FESCo - https://fedorahosted.org/fesco/ticket/1173 18:05:49 I forgot to join channel... 18:05:57 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 no problem -- we're on the first topi :-) 18:06:25 On the other hand, we've already done the deed. Why not give him the opportunity to rise to the occasion? 18:06:47 I did not change my position since the last week - that is no revocation unless he behaves badly 18:07:21 So if nobody wants to propose we should revoke his PP status we could move on. 18:07:21 I think cwickert was going to add some bugs supporting his position, but I don't know that that happened. 18:07:21 t8m: I agree. 18:07:45 nirik: I don't think that changes what I've just said, though? 18:07:53 no, just mentioning it. 18:08:04 wolfgang (raveit65) spoke favorably so I don't think I've changed my mind 18:08:05 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 likewise wolfgang. 18:08:51 yeah, so proposal: close ticket and ask if anyone sees misuse of powers, let us know. 18:08:57 nirik: +1 18:09:00 dan408 is by now certainly very aware that people will be watching 18:09:03 +1 18:09:06 nirik, +1 18:09:09 +1 18:09:16 nirik: +1 18:09:35 nirik: +1 18:09:39 +1 18:09:42 well, there is one bug linked 18:09:48 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 abadger1999, yep, it was an oversight 18:10:17 abadger1999: that's on me. i thought the policy was 'a week for feedback, but immediately escalates on -1' 18:10:22 https://bugzilla.redhat.com/show_bug.cgi?id=891282#c10 18:10:26 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 18:11:06 My reading of the provenpackager policy isn't that we have to wait a week for the feedback. 18:11:08 I think Wolfgang is very clear in that bug I just linked 18:12:04 cwickert, but this still isn't overuse of powerpackager powers 18:12:10 provenpackager that is 18:12:25 cwickert: But then his https://fedorahosted.org/fesco/ticket/1173?action=comment-diff&cnum=22&version=3 supports other interpretations... 18:12:26 just sloppines 18:12:34 t8m: true, but it's not something that qualifies for proven packagere I think 18:12:54 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 that's debatable 18:13:38 t8m: yes, but when that sort of language is debatable we should opt towards the broader interpretation 18:13:51 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 pjones: i can edit it to clarify that now 18:15:28 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 #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 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 mitr: I can be +1 to that. 18:16:49 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 mitr, I think that is implicit and unnecessary 18:16:59 (in the policy) 18:17:08 notting: +1 18:17:09 notting, +1 18:17:19 notting: +1 18:17:22 notting: +1 18:17:27 notting: +1 18:17:36 mitr: -1 I don't think we need to call him out as an exception. 18:17:37 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 notting: +1 18:17:51 Anyone that misuses pp powers should have them revoked 18:17:51 cwickert: I certainly agree. 18:17:57 cool, eof 18:18:06 notting: +1 18:18:10 notting: +1 but one grammar change: In case of negative votes, after that period FESCo will 18:18:24 abadger1999: wfm. done. 18:18:46 notting, do you vote for yourself? 18:18:51 t8m: yes. 18:18:52 abadger1999: yeah, that does make a difference doesn't it ;) 18:18:54 (in this case) 18:19:30 yep :-) 18:19:45 #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 next topic 18:20:21 #topic #1175 SCLs -- FPC questions on backwards compat 18:20:27 .fesco 1175 18:20:28 t8m: #1175 (SCLs -- FPC questions on backwards compat) – FESCo - https://fedorahosted.org/fesco/ticket/1175 18:21:01 does everyone have the background on this one? 18:21:12 So I think the discussion is not finished yet in the ticket 18:21:19 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 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 or does anyone have anything to add? or proposal to vote on? 18:21:51 nirik: Well -- we've identified some use cases so that we can make the guidelines make sense for them. 18:22:09 abadger1999: but you're asking about either/or, not both, right? 18:22:54 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 t8m I would like to at least vote on the the proposal I suggested in the ticket 18:23:36 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 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 Ideallyy people would like to see an scl that has 100% backwards compatibility for that. 18:23:43 in talking to people at conferences and meetups about fedora cloud, anything which helps with that would be welcome. 18:24:02 mitr -1: upstreams don't do that. 18:24:10 mattdm: I, for one, am completely confused as to how your proposed statement answers whatever question has been asked. 18:24:18 mattdm: but that might be because I can't figure out the question. 18:24:22 mattdm: This is a "should", not a "required", or "if you don't this Fedora won't work with you" 18:24:36 All of SCLs is basically workarounds for upstreams... 18:24:36 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 mitr, I am afraid this is so purely declarative it won't have any effect 18:25:04 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 mitr: i agree, but we don't have leverage for that proposal to mean much 18:25:23 mitr, we can vote that we'd like all the wars in the world stop but will it have any effect? 18:25:27 notting: At least, it's something a package maintainer can point upstreams to if the upstreams are new/uncertain 18:25:37 mattdm: obviously we should just have a vote on jettisoning that as a policy in general and allow compat packages ;) 18:25:50 mattdm: A fact which is tempered by the decisions of the individual maintainers, of course. 18:25:55 mattdm's statement would help answer one of the questions. Although I'd prefer something more direct. 18:25:56 mitr: they often don't care 18:25:59 mitr: "You see how Google handles API/ABI compat? Don't do that." 18:26:12 For example, I've got a couple packages I'm intentionally holding back because I know they broke other stuff. 18:26:18 notting: by writing the whole of the interface in javascript? 18:26:26 sgallagh: as do I 18:26:34 abadger1999: BTW I don't like the "100%" in these discussions - it leads to ratholes like bug-for-bug compatibility 18:26:35 pjones: i was thinking of things like v8 that randomly change ABI in minor releases 18:26:49 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 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 could we at least agreed on some way for SCL? 18:28:14 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 (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 SCL's will still need maintaining too. ;) it's not made of unicorn dust. ;) 18:28:31 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 mitr: So I tried to talk about it with the thin vs thick scl portion. 18:28:49 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 nirik yes, but we have unicorn-wranglers interested in doing it. 18:29:32 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 So instead I think we should have thin scls. 18:29:54 mattdm: tbf, i think we have people interested in other people being unicorn-wranglers for them 18:29:58 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 abadger1999: I agree if we can get rid off thin/thick terminology :) 18:30:11 abadger1999: is 'thin' and 'thick' an upstream SCL concept? 18:30:15 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 notting: it's not. 18:30:38 notting: but I don't have better terms at the moment. 18:30:57 thin -> one package/thing. thick -> a bunch of things that are in the same SCL 18:31:12 nirik: where "thing" may be "all gems"? 18:31:13 abadger1999: That gets REALLY hard if we start talking about things like RDO 18:31:32 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 not in my mind... no. 18:31:35 Where we end up talking about dozens of "thin" SCLs for each RDO release 18:31:57 why are we even speaking about dozens of scls? 18:31:58 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 abadger1999: "Red Hat Distribution of OpenStack" 18:32:24 sgallagh: it does not stand for that 18:32:26 pjones: re: newer version of hte SCL -- not if there's 100% backwards compat. 18:32:39 mmaslano: because isolating each thing to their own SCL solves some issues... and makes others. ;) 18:32:41 pjones: you'd need a new SCL, not a newer version of the SCL. 18:32:59 notting: That's how I heard it. My apologies if that's incorrect. 18:33:15 abadger1999: that's the same thing in my mind ;) 18:33:20 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 pjones: they're different though 18:33:33 you'd need a new name, for one thing. 18:33:34 abadger1999: Maybe GNOME and KDE are a better example 18:33:35 sure, I see the distinction your making. 18:33:51 I don't think that changed my point at all. 18:34:00 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 You're just using the word "version" 90-degrees orthogonal to my expectation. 18:34:06 nirik right, SCL isn't a perfect solution. but it's one I'd like to explore as an option 18:34:34 ruby1.9.3 , ruby1.9.3-updated-rails, ruby1.9.3-updated-rails-and-mintest, and so on. 18:35:29 ... what question are we trying to answer by this discussion ... ? 18:36:04 fpc asked if fesco says it's okay to have scl for backward compatibility 18:36:05 mitr: first, is packaging for backwards compatibility acceptable in fedora? 18:36:26 mattdm: Proposal: "yes, because upstreams don't do it and we need to have it". 18:36:28 Next? 18:36:29 could we answer this question first? 18:36:32 mmaslano: if that's the question, the answer should be "yes". 18:36:44 s/upstreams/some upstreams/ 18:36:45 I guess I'm ok with that... although when should a SCL be used over a compat package? or maintainers choice? 18:37:05 pjones: I guess that was output from 2 hours discussion on fpc 18:37:05 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 nirik there are actually some guidelines for the cases when an scl should be used 18:37:28 (which is basically what mattdm's statement does). 18:37:32 mattdm: proposed guidelines you mean? ;) 18:37:36 abadger1999: to that subquestion, "foolish but not forbidden" IMHO 18:37:38 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 abadger1999: for values of 100% slightly less than 100, sure! 18:37:43 mattdm, nirik: Or at least, FPC is trying to evaluate those :-) 18:37:55 pjones: +1 18:37:58 pjones: +1 18:37:59 sure. +1 18:38:05 +1 18:38:06 +1 18:38:07 pjones: +1 18:38:19 pjones, +1 18:38:29 do we want to vote on my substantially-wordier proposal in the ticket? 18:38:42 mattdm, I'd +1 to that as well 18:38:43 Second question would be "do we have to require that scls be 100% backwards compatible?" 18:38:46 it says the same thing but with more pontificating 18:38:56 please do so, otherwise it will be another fpc meeting without speaking about guidelines... 18:38:59 pjones: +1 18:39:03 okay so: proposal: 18:39:05 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 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 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 pjones, do you vote for yourself? 18:39:57 t8m: I do 18:40: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) 18:40:36 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 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 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 mitr, if anybody volunteers for that why wouldn't we welcome him? 18:41:25 t8m: at certain levels, sure. but i think we'd vote down someone wanting to ship a 2.2 kernel 18:41:30 t8m: it's not necessarily isolated - does SRT need to be involved, for example? 18:41:40 (ok, reducto ad absurdium) 18:41:42 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 notting, sure 18:42:05 okay, works for me. it's just there in case anyone really feels the need for more verbiage 18:42:26 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 abadger1999: yes, that would be good 18:43:16 okay, so is there another vote here that would be helpful? 18:43:42 mattdm: Proposal: Let's have beer at the meetings? 18:43:45 the second item abadger1999 mentioned? 18:43:55 sgallagh: +1 18:44:11 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 "do we have to require that scls be 100% backwards compatible?" 18:44:26 Second question would be "do we have to require that scls be 100% backwards compatible?" 18:44:37 Proposal: absolutely not 18:44:42 mitr, +1 18:44:46 mmaslano: No, I get that. His question was open-ended, so I was just making a joke. 18:44:50 I agree, let's get this over wirh 18:45:00 (... SCLs _should_ document what exactly they provide that is different fro mFedora Commons, though) 18:45:03 mitr: +MANY 18:45:13 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 how we would even test/do that? 18:45:25 +1 each scl needs to document its goals and any guarantees. 18:45:46 I'm really not sure whether we should be requiring FESCo approval/ack/notification about adding a SCL 18:45:55 mattdm, +1 18:46:02 notting: is that a question about what 100% backwards compat means or a question about something else? 18:46:07 sure, but I think FPC will generate in guidelines some general expectations... 18:46:16 abadger1999: yes, i think it's the first 18:46:26 abadger1999: do you have any examples? 18:46:30 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 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 mattdm: right 18:47:27 notting: +1 18:47:32 no ABI breakage, but minor updates would be fine 18:47:35 notting, definitely - it should stick to the purpose as defined when the scl is established 18:47:41 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 notting: : ^ That was about how to read "100% backwards compat" 18:48:10 Proposal: An SCL should strive for API/ABI compatibility, and if this breaks should consider doing so as a new SCL 18:48:19 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 sgallagh: -1. RDO again? 18:48:55 Intentionally not definitive, as there may be cases where some mostly unused feature is dropped 18:49:17 mitr: Sorry, I should maybe clarify. 18:49:38 sgallagh, -1 18:49:39 I meant API/ABI that is depended on by other packages. 18:49:51 But you're right, the RDO case gets hairy. 18:50:00 sgallagh: s/API.../promised API/, is a difference 18:50:05 But I'm thinking that each major release of something like RDO would probably be a new set of SCLs 18:50:18 mitr: Right, promised-and-public 18:50:27 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 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 abadger1999 sure 18:51:38 s/it's/its/, oops 18:51:42 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 notting +1 18:52:25 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 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 example: a xulrunner SCL 18:52:34 mitr: I would agree if I know what will be the promise 18:53:11 mitr: 4.0 protocol and X version of C library ABI, for example 18:53:13 mitr: +1 18:53:26 mitr, +1 18:53:38 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 mitr: ok, +1 18:53:50 notting: ok 18:54:09 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 (and deal with that next logical step as a... more complicated step.) 18:54:52 mattdm: That might make the politics easier, but honestly I'm fairly certain that's untenable 18:55:01 mattdm: Yeah, bring that up with fpc when hte time is right... but hte danger is language stack vs platform stack. 18:55:27 mitr: explain? 18:55:30 mattdm: ie: you'd exclude rails and openstack in that first pass if you do that. 18:55:37 abadger1999: do we have more questions from fpc? 18:55:42 mattdm: which may not be a bad thing for the first pass, though :-) 18:55:45 abadger1999 okay fair enough -- i want rails included. 18:56:08 t8m: do we have enough votes on mitr's proposal? 18:56:15 mattdm: If we package any rails applications at all, we _will_ end up with some choosing to stay behind 18:56:24 i actually feel a bit of urgency about rails since 4 is a feature 18:56:33 abadger1999, I don't think so? 18:56:51 sorry, what was the proposal again? 18:56:58 * sgallagh has a hard stop in five minutes. 18:57:06 [11:51:12] 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 there have been a lot of +1s going by :) 18:57:12 or maybe we do if we count notting's 18:57:14 * mitr is +1 to himself 18:57:23 mitr +1 (if I didn't already) 18:57:31 * notting is +1 to mitr's proposal 18:57:45 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 I'm +1 18:57:50 yep 18:57:58 mitr: +1 18:58:05 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 Wha6t's contract in tihis case? and what's life of an SCL? 18:58:28 #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 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 notting: Given the volunteer nature of Fedora, making any kind of promises for the future is somewhat tricky 18:59:37 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 notting: ah. yeah, that was implicit in my thoughts. FPC can make that explicit. 19:00:18 all of the promises fedora makes are best-effort promises. 19:00:37 mmaslano: one release in advance, or...? 19:01:01 notting: one Fedora release would make sense. 19:01:24 so people have time to move on or take the scl 19:02:27 i don't think we need to figure out the exact details here 19:02:42 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 I think that's all I need from fesco for this week. 19:03:30 I'll open a new ticket if we need more for next week. 19:03:41 thanks abadger1999! 19:03:53 thanks 19:04:04 #topic Next week's chair 19:04:30 Anybody volunteers 19:04:50 I probably won't be able to attend next week 19:04:52 I can do that 19:05:12 #action mitr to chair next week 19:05:23 #topic Open Floor 19:06:25 Does anybody have anything for Open Floor? 19:06:27 if not 19:06:34 * nirik does not 19:06:40 I'll close the meeting in two minutes 19:09:00 #endmeeting