16:01:13 <abadger1999> #startmeeting fpc
16:01:13 <zodbot> Meeting started Thu Sep 19 16:01:13 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:23 <abadger1999> #chair tibbs|w geppetto limburgher RemiFedora
16:01:23 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher tibbs|w
16:02:08 <abadger1999> ping spot, SmootherFrOgZ, Rathann FPC meeting
16:02:13 <abadger1999> #chair Rathann
16:02:13 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher tibbs|w
16:02:17 <abadger1999> Hey Rathann
16:02:17 <Rathann> hi abadger1999
16:02:37 <Rathann> I just got home
16:02:43 <abadger1999> Cool  we just started ;-)
16:02:59 <abadger1999> mmaslano was able to join us so let's start with SCLs.
16:03:08 <abadger1999> even if we might not get to anything else.
16:03:32 <abadger1999> #topic SCLs in Fedora https://fedorahosted.org/fpc/ticket/339
16:04:02 <abadger1999> langdon, RemiFedora, and I worked on notes and questions over the weekend and sent them to the mailing list.
16:04:15 <abadger1999> mmaslano replied to the email with questions on a few of those.
16:04:19 <abadger1999> #chair racor
16:04:20 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher racor tibbs|w
16:04:47 <abadger1999> I'm putting the questions and answers onto a wiki page right now so that it's easy to see what's been answered and what hasn't.
16:05:02 <abadger1999> but I would like discussion to continue on the mailing list and on IRC.
16:05:32 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A
16:05:53 <abadger1999> What would we like to accomplish today since we have mmaslano available?
16:07:51 <abadger1999> mmaslano: is there something in particular that you'd like to discuss first?
16:08:04 <abadger1999> If not, I can jsut start going through our questions...
16:08:11 <mmaslano> please, start
16:09:09 * abadger1999 skips over the first /usr/bin/env for now -- that's tangential to scls.
16:09:47 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#SCL.27s_Big_Picture_Goals_within_Fedora <=  This is probably something that we need to write down this week.
16:09:53 <abadger1999> Discuss next week.
16:10:24 <abadger1999> SCLs are just a technology -- what they allow us to do is policy and it affects choices we'll need to make in the guidelines.
16:10:29 <geppetto> indeed … both goals are basically "make compat. packages easier" … except compat packages have never been refused in Fedora because "they are hard".
16:10:37 <abadger1999> yeah.
16:11:36 <abadger1999> So we should write down what we want to achieve and then next week we can discuss whether FPC sees any of them as unreasonable goals or how they might influence the rest of the guidelines.
16:12:05 <abadger1999> mmaslano, langdon_, etc: If you have any further goals to add, feel free.
16:12:20 <abadger1999> (Do it via the mailing list and I'll add the to the page)
16:12:34 <tibbs|w> I think the path of least resistance is to make it clear that these things are to be strictly minimized.
16:12:45 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#What_is_the_logical_limit_of_the_.22size.22_of_that_collection.3F
16:12:55 <abadger1999> <nod> brings us to the next topic
16:13:35 <abadger1999> #topic https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#Criteria:_When_is_a_Collection_the_Right_Choice.3F
16:13:37 <racor> abadger1999: Do we have real world examples for complex packages using SCLs, e.g. full blown perl-5.14.x stack?
16:13:51 <geppetto> tibbs: There's a difference between "we have a small number of cases where these would be useful" and "we have no cases where these would be useful" … the current arguments lean scls in Fedora heavily toward the later, IMNSHO.
16:13:52 <abadger1999> racor: yes, let me get a link
16:14:07 <Rathann> isn't the real goal of SCLs to allow installation of new software stacks on RHEL?
16:14:13 <abadger1999> https://fedorahosted.org/SoftwareCollections/
16:14:26 <abadger1999> Rathann: So -- that goes back to big picture goals.
16:14:40 <abadger1999> Rathann: on rhel, one of the big things is forwards compat -- new software stacks
16:14:59 <Rathann> they don't make much sense in Fedora IMHO
16:15:05 <abadger1999> Rathann: On fedora, one of the goals that mmaslano and langdon_ have been mentioning to me is backwards compat.
16:15:07 <racor> abadger1999: Thanks, will try to have a look into it until next week, but ... there is a >50% chance I'll not be able to attend.
16:15:12 <abadger1999> Rathann: cross-version conmpatibility.
16:15:20 <abadger1999> racor: k..
16:16:09 <racor> Rathann: ACK.
16:16:33 <mmaslano> I guess we are using the same guidelines also for EPEL
16:16:38 <abadger1999> racor: so you could build/develop your software on Fedora 19 targetting the ruby1.9 SCL and then deploy on fedora 22 using the same ruby1.9 SCL and things would Just Work(TM).
16:16:45 <mmaslano> people were already asking about scls in EPEL
16:16:45 <abadger1999> err Rathann ^, not racor
16:16:59 <tibbs|w> For EPEL, I guess talk to the EPEL folks?
16:17:07 <abadger1999> <nod>  and that -- although epel can have differences from fedora.
16:17:10 <RemiFedora> I think another goal is to simply provide various version for developpers, which need to test thier app which various (ex a webapp with php 5.3, 5.4 and 5.5)
16:17:17 <Rathann> hm
16:17:18 <mmaslano> tibbs|w: I wasn't sure. do they have their own guidelines?
16:17:20 <tibbs|w> They take guidelines from us where practical but can make their own decisions about this.
16:17:37 * abadger1999 notes that nirik weighed in for epel saying that he wanted to see what happened in fedora/FPC before enabling anything in epel.
16:17:39 <tibbs|w> Right now I'm pretty sure they won't permit them until Fedora permits them, if ever.
16:18:02 <Rathann> I'd love to see some practical examples
16:18:10 <tibbs|w> I'm sure we all would.
16:18:14 <RemiFedora> we really need SCL in EPEL, not to provide new SCL, but more to provide additional package for existing SCL in RHEL
16:18:34 <abadger1999> RemiFedora: Hmmm... I'm not sure if Fedora would go that route.
16:18:40 <abadger1999> But epel could deviate.
16:19:21 <RemiFedora> yes, I was talking about EPEL.
16:19:21 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#Collections_and_backwards_compat
16:19:30 <Rathann> sorry, I have to go away for a few mins
16:19:31 <racor> mmaslano: *Your* subordinates and RH-employes are asking for it - As I assume, they are challenging Fedora to have the Fedora community being  abused as Guinea pigs.
16:19:37 <abadger1999> So there's question of thick vs thin scls there.
16:20:30 <mmaslano> racor: for example I don't know that guy on packaging list
16:20:50 <abadger1999> RemiFedora: So from conversations so far, I think thick SCLs are going to be a very poor fit for the nature of fedora.
16:21:14 <abadger1999> RemiFedora: Instead I would go with thin scls and liberal use of inter-scl dependencies for building out a complete stack.
16:21:33 <mmaslano> abadger1999: I still believe they can be helpfull for "slow" projects
16:21:35 <geppetto> I think the idea of thin scls is a pretty bad one, it makes their difference from normal packages much less apparent and explodes testing.
16:21:59 <abadger1999> geppetto: well -- if we did thick scls, I would be 100% against the backwards compat goal.
16:22:28 <geppetto> I'm pretty close to 100% against it anyway … without a lot more justification.
16:22:38 * abadger1999 may be exagerating a tiny bit about his percentage of against but... it's pretty high
16:23:08 <geppetto> I mean the big thing about backwards compat. is that _by definition_ we've already had working packages for that version.
16:23:09 <abadger1999> geppetto: question though -- is being different from other packages really an advantage?
16:23:11 <racor> maslano: Which Review request? There should not be any need for any SCL-package stuff in fedora.
16:23:22 <mmaslano> racor: email on packaging list
16:23:34 <geppetto> So changing those working packages by adding a lot of scl stuff seems pretty bogus.
16:24:02 <racor> mmaslano: mail archive pointer ?
16:24:32 <abadger1999> geppetto: There's actually another section that ties into that: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#Spec_Files
16:24:33 <geppetto> abadger1999: They are fundamentally different (Eg. limited requires outside the scl/etc.), so if they look like they aren't it's just going to confuse people.
16:25:11 <mmaslano> racor: um it's about EPEL https://lists.fedoraproject.org/pipermail/packaging/2013-September/009532.html
16:25:17 <abadger1999> A big question langdon_ and I asked there was why not have separate packages from the "normal package" similar to how mingw has separate packages for their rebuilds.
16:25:33 <geppetto> abadger1999: Yeh, but it's still a big change from a working package … instead of just adding "compat-" to the name etc.
16:25:38 <mmaslano> abadger1999: what do you mean by separate?
16:25:48 <mmaslano> abadger1999: I didn't get it from your mail
16:25:52 <Rathann> ok, back
16:26:13 <abadger1999> mmaslano: So for mingw, they have many of the same packages as we have in mainstream fedora but they're compiled to run on windows instead of Linux.
16:26:35 <racor> mmaslano: Thx for the pointer.
16:26:53 <abadger1999> mmaslano: Instead of having conditionals in the main spec file to build a mingw package, they have a separate srpm-level package that has the changes needed for building the windows targetted binaries.
16:27:44 <abadger1999> they do try to stay as close as they can to the "normal package" but they can just use visual diff tools to do updates instad of wrapping everything in conditionals.
16:27:45 <mmaslano> abadger1999: it must be harder for maintenance, cherrypicking patches etc.
16:28:13 <racor> mmaslano: On the subject: How many sets of SCLs do you want? One stack per possible permutation of # of existing packages? Do you sense the nonsense?
16:28:21 <abadger1999> mmaslano: I don't think it would be harder than a separate branch in the SCM.
16:28:39 <RemiFedora> I think this must stay a packager choice, generic spec (for all branche/scl) vs branch/scl specific spec
16:29:09 <abadger1999> racor: there's a section asking that question too: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#What_is_the_logical_limit_of_the_.22size.22_of_that_collection.3F  The last two bullets
16:29:12 <mmaslano> racor: depends on packagers. Personally, I'd like to prepare few set of working cominations. Ruby 1.9.3 with old Rail, Ruby 2 with new Rails and keep only these two. Same with other languages
16:29:26 <racor> RemiFedora: I think scls should be banned from Fedora,
16:29:47 <tibbs|w> racor: No real disagreement, but we aren't the committee to do that.
16:30:02 * RemiFedora nods
16:30:11 <racor> mmaslano: x (gcc4.6 | gcc4.8) x ( )
16:30:42 <mmaslano> racor: i don't know anything about gcc, I guess major most used version
16:30:58 <tibbs|w> I honestly don't think this committee is going to be functional on this issue.
16:31:10 * abadger1999 notes that mmaslano suggested we have limits to keep the number of scls down.  we just don't have the criteria to do that written down (something we could come up with today.)
16:31:17 <tibbs|w> I'll try to do my job but the distaste for this kind of thing really makes it difficult.
16:31:22 <racor> tibbs|w: I disagree. We are not supposed to switch off our brains, and to ratify all other crap other people want to force on us.
16:31:41 <tibbs|w> No, we're supposed to work out how to do what others have decided.
16:32:11 <mmaslano> abadger1999: I heard proposal SCL SIG, Change approved by FESCo, something else?
16:32:32 <tibbs|w> If someone presents to me what I believe to be the best way to accomplish a goal I personally don't agree with, I'll vote for it.
16:32:35 <abadger1999> mmaslano:I'm much happier with having criteria.
16:33:16 <abadger1999> mmaslano: I could be persuaded that something like the FPC be set up to deal with approving SCLs but proper criteria is much prefered.
16:33:33 <mmaslano> abadger1999: I'm not sure how you want to set such criterias? 2 collections per language/database?
16:33:34 <tibbs|w> Proper criteria with an exception process, sure.
16:33:44 <Rathann> racor, tibbs|w: my dislike for the current proposal starts with /opt and then it gets worse
16:33:52 <tibbs|w> Well, sure.
16:34:22 <tibbs|w> I thought enough of us initially said /opt was a non-starter, but then it's just one configuration setting so it's the least of our troubles here.
16:34:23 <mmaslano> abadger1999: ok, so what if we based exception process on requests from projects running on Fedora?
16:34:23 <abadger1999> mmaslano: From experience with bundled libraries, you want a stable, non-elected body to judge SCLs.  and the more criteria they have to decide to approve or disapprove the better.
16:34:24 <RemiFedora> I think a new SCL should be considered as a feature, so approved as other features.
16:34:26 <racor> tibbs: I guess this is a cultural difference. I am not going to be a brain dead opportunist who is going to say "Amen" to everything
16:34:37 <tibbs|w> And neither am I.
16:34:56 <tibbs|w> But if you refuse to do the job this committee exists to do, then exactly why do you keep coming to meetings?
16:35:27 <racor> tibbs|w: why are you demanding to be behave as such?
16:35:36 <tibbs|w> I have demanded nothing.
16:35:52 <abadger1999> racor: the FPC and FESCo have always split their responsibilities as: fesco decides what is packaged, fpc decides how it is packaged.  So fesco has said, we want to allow scls.  fpc is deciding how those are to exist.
16:36:01 <tibbs|w> Anyway, apologies to the other folks in this channel, but I still don't think this committee is sufficiently functional to make much progress here.
16:36:53 <geppetto> abadger1999: How did FESCO approve scls if they still don't know what they'll be used for?
16:36:54 * abadger1999 notes that we are treading a line with criteria but thinks fpc is much better equiped to attempt to come up with a set of criteria and hand it off to fesco to approve than for fesco to come up with them from scratch.
16:37:10 <geppetto> abadger1999: Or are FESCO planning on allowing a lot more backwards compat. packages in the near future?
16:37:11 <abadger1999> geppetto: Hmm... good questoin.  let me find the ticket and see if I overstated the case.
16:37:12 <RemiFedora> abadger1999, I agree, so I think we have to check that Guidelines are correct, and that SCL will not break the system.
16:37:33 <racor> abadger1999: And I have the freedom to pronounce my opions and to fight against FESCO mistakes. As you know, I feel the last couple of FESCO, commited a lot of faulty decisions.
16:38:08 <racor> TmpOnTmpFS for instance, I am close to file a CVE against it
16:38:40 <abadger1999> mmaslano: Do you recall if SCLs were a fesco ticket or if they were voted on in meeting under another topic?
16:38:57 <mmaslano> abadger1999: I'm loooking
16:39:56 <mmaslano> abadger1999: probably not, I guess it was just given to FPC on some OpenFloor
16:42:15 <geppetto> That does sound much more likely … take it to FPC and see what they say, as they are the packaging people and this is all about packaging.
16:42:24 <abadger1999> k
16:42:28 <abadger1999> So .. plan of action:
16:42:47 <abadger1999> Let's braindstorm https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#SCL.27s_Big_Picture_Goals_within_Fedora
16:43:04 <abadger1999> then send it to fesco.
16:43:13 <abadger1999> fesco can decide what we're looking at.
16:43:23 <abadger1999> and then we revisit the guideliens to implement that?
16:43:28 <abadger1999> does that sound reasonable?:
16:44:34 <abadger1999> Or does no one have ideas for the goals that differ from what's already there?
16:44:51 <mmaslano> abadger1999: I would change it to normal language, at least my sentences
16:46:12 <geppetto> Again, I think the backwards compat. usecase is a huge amount of work for something we already have working solutions for (and aren't use, for other reasons).
16:46:57 <geppetto> When people first spoke to me about trying to get scls in Fedora again, it was with the intention of forwards compat. on top of a more stable base (see rings/onion model/whatever).
16:47:16 <abadger1999> mmaslano: Better? https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#SCL.27s_Big_Picture_Goals_within_Fedora
16:47:41 <mmaslano> abadger1999: fine, thanks
16:48:03 <mmaslano> geppetto: currently I do not have usecase for forward compat
16:48:17 <abadger1999> mmaslano: rhel?
16:48:28 <abadger1999> aren't all the scls in rhel about forward compat?
16:48:54 * abadger1999 adds geppetto's statement to the page
16:49:19 <mmaslano> but we are speaking about Fedora right now
16:50:13 <abadger1999> mmaslano: well, and to some extent epel.
16:50:22 <tibbs|w> So is the goal is just backwards compat (keeping an old ruby release around so rails still works) and SCL merely being proposed as the means to achieve that?
16:50:24 <Rathann> mmaslano: so why do you want SCLs in Fedora, please provide some real world use cases
16:50:38 <abadger1999> tibbs|w: not entirely...
16:50:41 <limburgher> In Fedora we have compat- packages and a tendency to keep moving forward.  So I second Rathann's question.
16:50:50 <abadger1999> tibbs|w: There's two aspects for backwards compat.
16:51:00 <tibbs|w> I think a failure for anyone to actually define the goal before starting is a big problem here/.
16:51:15 <mmaslano> Rathann: I guess I wrote it in the proposal. Stable set of packages for various projects. The most needed now is stable Ruby stack
16:51:15 <abadger1999> There's backwards compet for things in the distro and backwards compat for people developing on top of the distro.
16:51:24 <tibbs|w> Especially since the goal isn't the part of the process with which we should have any involvement.
16:51:26 <abadger1999> the rails case is kinda in the middle at the moment.
16:51:36 <abadger1999> since it's a framework... it oculd be seen in either light.
16:52:14 <tibbs|w> If done correctly, I don't see how those goals really diverge.
16:52:37 <tibbs|w> I see how they diverge if you have to see everything through SCL-tinted glasses.
16:52:54 <mmaslano> do you speak about something-compat packages?
16:53:00 <tibbs|w> I'm lagging, BTW.
16:53:30 <abadger1999> so -- let's say that puppet needed an older version of ruby to run.  that would fall squarely into a piece of software we want to package for fedora for end users to run but we need a parallel stack of old ruby to enable.
16:54:05 <mmaslano> ok, puppet is good example.
16:54:16 <Rathann> abadger1999: we'd package compat-rubyNNN for that case
16:54:19 <tibbs|w> So you package ruby18 or whatever, and then have a bunch of ruby18-foo packages and in the end you have puppet.
16:54:33 <racor> abadger1999: my view: "puppet" needs to be updated, compat-converted or it has to be removed
16:54:44 <Rathann> racor: also true
16:55:07 <abadger1999> otoh, let's say that there were two versions of ruby-on-rails and we wanted both of those to be usable, not for anything we run in the distro, but so that people who use ruby-on-rails can build their applications on fedora targetting one of those versions and deploy it on a later version of fedora.
16:55:12 <Rathann> but forward-porting takes time and we always treated compat-stuff as temporary
16:55:16 <abadger1999> that's the develop on top of the distor use case.
16:55:41 <tibbs|w> So you package ruby18 or whatever, then have a bunch of ruby18-foo packages and at the end you have ruby18-rails.
16:56:03 <abadger1999> Rathann: Some things are parallelizable natively (for instance, python with the exception of one use case).
16:56:04 <tibbs|w> Or you could have some thick SCL crazy thing and bundle a pile of stuff and write all new guidelines and....
16:56:16 <Rathann> that's one use case
16:56:18 <racor> tibbs|w: now do this for 100 other packages :)
16:56:24 <abadger1999> Rathann: other things are not (if i understand correctly, ruby is not because all of the filesystem paths are unversioned).
16:56:33 <tibbs|w> Well, sure, if someone thinks they can get those all through the review process.
16:56:56 <geppetto> Not only that … but those ruby18 or compat-ruby18 packages will mostly be identical to the ruby package at the time ruby18 was current … ie. tested already.
16:56:56 <tibbs|w> Or maybe at some point someone says "you know, this is actually a terrible idea".
16:57:06 <racor> the only purpose I see for SCLs is "3rd party" vendors to supply "fully bundled" package suites, similar to what google does.
16:57:12 <geppetto> If you make an SCL for ruby18, you've changed most of the package locations and a huge amount of the specfile … bye, bye testing.
16:57:27 <abadger1999> mmaslano: Do you know about ruby?  Can you speak to why/whether a ruby18 native package would not be possible?
16:57:38 <mmaslano> abadger1999: no, I do not
16:57:40 <tibbs|w> But I just don't understand why we're even talking about this when it appears that the real work is on the language packagers to figure out how do set up their stacks to allow parallel installs.
16:57:48 <Rathann> racor: and most big commercial software vendors like Symantec, IBM, BMC
16:57:50 <mmaslano> tibbs|w: we did
16:58:24 <abadger1999> I think the answer is -- they did and SCLs is what they came up with.
16:58:34 <racor> Rathann: None of them actually has needed SCLs.
16:58:51 <Rathann> yes, because they just install into /opt/foo
16:58:53 <mmaslano> the another reason why we were using packaged in SCL is that you can move whole Ruby collection to new FEdora, and everything will be still working the same way.
16:59:08 <racor> abadger1999: "they"? IBM etc? .. so this all is about money?
16:59:10 <Rathann> racor: and their "rpm" packages are horribly broken
16:59:23 <tibbs|w> I mean, I'm not a big fan of how the python2/3 stuff works, but it does work and is being used to do what SCLs are supposed to do.
16:59:31 <racor> Rathann: well, ... yes.
16:59:39 <limburgher> There's also php and php53 in EL-5.
16:59:54 <geppetto> mmaslano: Yes, that's kind of what backwards compat. is … stuff keeps on working.
17:00:03 <limburgher> I'm looking for the problem that SCL solves that is otherwise insoluable.
17:00:14 <Rathann> mmaslano: so how are SCLs better than what we currently have?
17:00:17 <limburgher> For Fedora, I mean.
17:00:29 <Rathann> assuming the backwards compatibility is the only goal
17:00:34 <geppetto> mmaslano: The point isn't that SCLs don't give backwards compat. … it's that we can already do backwards compat. but Fedora has historically rejected backwards compat. anyway.
17:00:43 <mmaslano> we didn't invent the whole thing just for fun, but because it safe us time with packaging
17:00:43 <RemiFedora> limburgher, yes... and php53 is just a nightmare for dependencies...
17:00:52 <limburgher> RemiFedora: Indeed.
17:00:53 <mmaslano> geppetto: why
17:01:10 <Rathann> mmaslano: but you've never answered the question why you did it
17:01:33 <geppetto> mmaslano: My understanding is that SCLs were "invented" to solve the forward compat. problem on RHEL … not to solve any backwards compat. problems.
17:01:39 <mmaslano> Rathann: imho installing more things in standard paths leads to errors
17:01:57 <Rathann> don't tell me your boss just came up to you one day and said "invent a way to have parallel-installable software stacks in Fedora"
17:02:00 <mmaslano> scl isolate different version from rest of the system
17:02:01 <geppetto> mmaslano: And I would be open to using them to solve forwards compat. problems in Fedora, if that was a thing.
17:02:11 <limburgher> geppetto:  Exactly, I think they make sense for EL-5, EL-6, EL-7.  But not for Fedora.
17:02:32 <mmaslano> geppetto: no, paralell installation of languages
17:02:36 <Rathann> mmaslano: but to have multiple versions of the same thing is contrary to Fedora goals
17:02:40 <limburgher> geppetto:  We typically solve Fedora forward-compat issues with fedpkg new-sources. :)
17:02:50 <mmaslano> Rathann: those goals might be redefined soon
17:03:02 <geppetto> limburgher: right, just ship it as default has been the historical "fix" :)
17:03:12 <Rathann> mmaslano: could you answer my question finally?
17:03:28 <mmaslano> Rathann: no, you are just not satisfied with answers
17:03:36 <Rathann> I asked for specific use cases
17:03:39 <Rathann> you provided one
17:03:53 <Rathann> that doesn't justify the amount of work put into this
17:03:59 <Rathann> so there must be more
17:03:59 <mmaslano> yes, because that's most wanted
17:04:47 * abadger1999 adds multiple versions of the same thing as a goal with forwards and backwards compat as separate flavours underneah.
17:05:14 <RemiFedora> Rathann, having SCL allowed in fedora don't means we'll have packager to create "huge" SCL, p.e. I really don't plan to propose a php 5.4 SCL (with the ~500 packaged library which could be included in it)
17:05:16 <mmaslano> Rathann: maybe you should ask on mailing list, where are people interested in it
17:05:26 <mmaslano> and have also different usecases
17:07:46 <racor> mmaslano: Like I said before, the only valid use case to me in Fedora is 3rd party add-on packages. The origin why these are difficult to implement is lots of fundamental bugs in Fedora/RH's rpm infrastructure, which are not easy to overcome.
17:08:32 <mmaslano> I don't think speaking about addons before changes in Fedora make sense
17:08:43 <mmaslano> we don't know how Fedora will change
17:09:20 * abadger1999 notes we're going into the second hour now.
17:09:55 <abadger1999> Perhaps there are specifics we could ask fesco to approve that would let us move forwards?
17:11:11 <mmaslano> abadger1999: I'm for giving it back to fesco if you are asking me
17:11:19 <Rathann> abadger1999: I'd like to know why we would want this stuff in Fedora - it's contrary to both "Features" and "First" as stated (backwards compatibility use cases)
17:11:42 <Rathann> the couple of use cases presented don't justify the amount of work necessary
17:12:05 <limburgher> Rathann: <nods>
17:12:14 <Rathann> it's very complex, fragile and easy to make a bad design decision which will bite us later
17:12:29 <abadger1999> mmaslano: the whole thing?  -1
17:12:34 <limburgher> And it makes total sense for EL, but not really Fedora.
17:12:52 <abadger1999> Rathann: That sounds like a good idea. /me figures out how to phrase that.
17:15:47 <abadger1999> FESCo questions:  what are the use cases that we are aiming for with SCLs?  One of the presented goals was backwards compat.  This seems to be contrary to the Fedora Foundations of "Features" and "First".  Is this a purposeful deviation?  [Add a longer description of the backwards-compat-for-developers goal to go with the tl;dr; question.]
17:17:11 <Rathann> also, the mixture of standard and SCL-provided dependencies opens a new kind of dependency hell which will be easy to trip over, as RemiFedora noticed
17:17:21 <abadger1999> Is that good for the people who want to have backwards compat made or not made an explicit goal?
17:17:26 <Rathann> we ban /opt in packages for a good reason
17:17:44 <Rathann> so we must have a REALLY good reason to break that tradition
17:18:29 <abadger1999> Hmm... so that is a set of technical question that I don't think was answered.  How do autodeps work with SCLs? Are non-scl packages allowed to dep on SCL packages?
17:18:56 <abadger1999> mmaslano: Do you know the answers to those?
17:19:50 <limburgher> abadger1999:  I'd guess explicitly no.
17:20:10 <mmaslano> abadger1999: I guess these should be answered by slavek. autodeps work same way, they might
17:20:40 <RemiFedora> for autodeps, I think "filtering" is the solution.
17:20:47 <mmaslano> abadger1999: dependency on SCL is based only on policy
17:20:53 <RemiFedora> the guildelines just need more examples, I think
17:21:20 <mmaslano> RemiFedora: could you add them if you have any? I run into different issues with packaging probably
17:21:22 <abadger1999> mmaslano: So it sounds like we need to have slavek here to talk about any of the technical questions (or he could reply on the mailing list).
17:21:46 <mmaslano> abadger1999: it might be better to reply on list and the output give back on wiki
17:21:58 <abadger1999> mmaslano: <nod>  What's the proposed policy?  Or what's the pros and cons of each so that we can decide.
17:21:59 <RemiFedora> mmaslano, I was thinking about the libapr-1.so issue we have discussed previously
17:22:34 * abadger1999 notes that because of timezone differences, this is like playing postal chess but it is what it is.
17:22:38 <mmaslano> abadger1999: deps on SCL? um I guess most packagers put their packages also in SLC dependent on the first one
17:22:56 <abadger1999> mmaslano: <nod>  But some of them wouldn't necessarily have too.
17:23:17 <mmaslano> abadger1999: they did it, because they can move the whole stack, the same way as rest of SCL
17:23:32 <abadger1999> If you had an application that needed an old version of ruby, for instance, the app could ship in /usr/bin/ but part of the app would be a wrapper that enabled the SCL it needed.
17:23:59 <Rathann> that's another question
17:24:09 <mmaslano> yes, in Fedora we might run into your usecase
17:24:09 <Rathann> do we allow regular stuff to depend on SCLs?
17:24:32 <Rathann> I'd say no
17:24:44 <mmaslano> what in case of puppet? we would have to rebuild it anyway, wouldn't we?
17:24:52 <mmaslano> so it wouldmake more sense to put it also in scl
17:25:09 <abadger1999> What do you mean by rebuild?
17:25:37 <Rathann> point is, the SCLs make it more difficult to run and build against stuff as you need to set up the environment first
17:25:45 <RemiFedora> Rathann, we should have 2 policies, one for using a SCL at buildtime, another at runtime (I think first could be acceptable)
17:25:53 <Rathann> hm that reminds me
17:26:02 <Rathann> we already have something called environment modules
17:26:17 <Rathann> that's for different implementations of MPI, mostly
17:26:33 <abadger1999> <nod>  slavek had said that environment modules weren't powerful enough for their needs but I don't think he ever said what it lacked.
17:27:25 <mmaslano> i guess switching of environment is easier with scl
17:29:29 <Rathann> well, it seems the discussion is stalled due to lack of answers
17:29:31 <abadger1999> So I think ther'es some high level informatoin we need from slavek as well as fesco.
17:29:51 <abadger1999> * what packages can't be natively parallel installed and why?
17:30:03 <abadger1999> (that an scl for them would fix it)
17:30:14 <abadger1999> * What makes scls better than environment modules.
17:30:26 <Rathann> and compat-* packages
17:30:45 <abadger1999> Rathann: would that fit under the "what can't be natively parallel installed"?
17:30:54 <Rathann> ah, right
17:31:34 <abadger1999> * what are the pros and cons of non-scl packages deping on SCLs?
17:31:53 <abadger1999> mmaslano: puppet would be a real-world example where it could be done that way, correct?
17:32:10 <mmaslano> abadger1999: yeah
17:32:14 <abadger1999> k
17:34:37 <abadger1999> what else would people like to ask either fesco or slavek?
17:35:02 <RemiFedora> approval of new scl ?
17:36:48 <abadger1999> RemiFedora: Could you expand on that?
17:37:04 <RemiFedora> yes
17:37:27 <RemiFedora> should a new SCL be accepted as another new package (simple package review) or as a new feature.
17:37:43 <RemiFedora> (I think the later)
17:37:55 <abadger1999> Or a third process.
17:37:57 <abadger1999> <nod>
17:38:20 <RemiFedora> I'd like to see SCL in fedora, but I don't want to see tons of SCL
17:38:34 <abadger1999> RemiFedora: k.  I think fesco might need to decide that eentually... but I think that somewhat depends on the goals and the criteria being defined.
17:38:45 <RemiFedora> yes
17:39:17 <abadger1999> for instance, if we end up with thin SCLs.. we'll have a lot more SCLs than if we have thick SCLs.
17:39:44 <abadger1999> In turn, if we hae backwards compat as an explicit goal, then I would be very much against thick SCLs.
17:39:57 <Rathann> abadger1999: you'd need to define thick and thin carefully first
17:40:03 <abadger1999> yes.
17:40:50 <abadger1999> and there's a grey area in between which for linking with the backwards comapt arguments, I'd lump in with the thick SCLs.
17:42:39 <geppetto> but, again, the only cases where SCLs for back compat. _might_ be better than using normal packages are in the "thick" cases, where it might be easiest to dump an entire stack into a set of SCLs than to try to make it parallel.
17:42:51 <abadger1999> thickest SCL is SCL has a platform and any dependent packages that are needed to run that paltform.  grey area -- SCL has a platform where some of the packages included are optional to that platform [like rails being included in a ruby1.9 compat SCL].  thin -- SCL only has enough packages to implement a platform.  Other SCLs would be generated to establish platfrms built on top of that platform. [so ruby1.9 would be one scl.  rails3 on ruby1.
17:42:53 <abadger1999> 9 would be a different platform].
17:43:46 <abadger1999> geppetto: k... So let me update the fesco quesetoin about this.... It seems like we've come to something that may mean that SCLs are just a bad idea for backwards compat.
17:47:22 <abadger1999> mmaslano: Oh -- we also really need to establish the definition list.  so that we don't use "SCL" to mean a collection, the metapackage for the collection, and all the packages that go into an scl.
17:47:37 <tibbs|w> Yes, please.
17:47:41 <abadger1999> mmaslano: If you don't have an objection to what I wrote in the notes, we can just add that.
17:48:18 <mmaslano> abadger1999: definition list might be good
17:48:39 <mmaslano> abadger1999: notes where?
17:48:52 <abadger1999> mmaslano: In the mailing list post -- I think it was near the bottom.
17:50:10 <mmaslano> abadger1999: you mean your long email? i didn't agree with everything, but we can work on it on your wiki
17:50:14 <mmaslano> that would be best
17:51:16 <abadger1999> mmaslano: sure -- I'm specifically asking about hte definitions of terms, though -- I think that getting that into the draft will let us not get confused when we talk.
17:51:23 <mmaslano> ok
17:52:08 <abadger1999> mmaslano: do you want to quickly review it and make sure it's not inaccurate?    It's the "Include "definitions" at the beginning" bullet point at https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_Q%26A#General_Comments
17:53:30 <mmaslano> abadger1999: I'll slightly fix it
17:54:14 <abadger1999> mmaslano: Cool.  Feel free to edit it in place.
17:54:18 <mmaslano> or add notes, you can rewrite it
17:59:52 <abadger1999> geppetto: http://www.fpaste.org/40793/13580137/
18:00:28 <geppetto> abadger1999: looks good to me
18:01:34 <geppetto> abadger1999: Might also want to say with the thick version we court the possability of shipping ruby1.9 in two different SCLs
18:01:54 <abadger1999> <nod>  /me adds that
18:03:44 * RemiFedora will have to go soon... nearly 2hours
18:04:03 <abadger1999> added: Where we have stacks built on stacks we also run the risk of having duplication: ruby1.9 and rails3 in in one SCL, ruby1.9 and rails4 is in a different SCL, ruby2.0 and rails3 is in a third, etc
18:04:27 <abadger1999> <nod>  yeah, we've hit two hours.
18:04:53 * inode0 notes the Board is meeting in fedora-meeting now instead of here
18:04:58 <abadger1999> mmaslano, RemiFedora: I've though of something else about the approval.
18:05:03 <abadger1999> inode0: We can wrap up.
18:05:15 <inode0> we are off and running there so no problem
18:05:18 <abadger1999> k
18:05:47 <abadger1999> mmaslano, RemiFedora: We both need approval for the SCL (via the metapackage) and for the packages that are being added to the SCL.
18:06:57 <abadger1999> Otherwise adding to an SCLs API  can be done by any packager who adds the macros to their package.
18:07:13 <abadger1999> I think we've only talked about the former so far.
18:07:17 <RemiFedora> abadger1999, yes, that's the reason why I think a new SCL should be considered as a feature, with a desciption of its goal and content
18:07:35 <mmaslano> RemiFedora: yeah, feature would be probably good solution
18:08:09 <RemiFedora> ... life cycle ... update policy ...
18:08:31 <mmaslano> I mentioned life cycle, but forgot on updates...
18:08:32 <RemiFedora> ... owner
18:10:41 * mmaslano needs to leave. Bye
18:12:32 <RemiFedora> abadger1999, can we close this meeting ?
18:13:09 <abadger1999> RemiFedora: This is for you: http://www.fpaste.org/40796/96143801/
18:13:18 <abadger1999> RemiFedora: That look good for what I send to fesco?
18:13:40 <RemiFedora> yes
18:13:44 <abadger1999> Cool.
18:13:48 <abadger1999> #endmeeting