16:03:58 <abadger1999> #startmeeting fpc
16:03:58 <zodbot> Meeting started Thu May 22 16:03:58 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:04 <abadger1999> #meetingname fpc
16:04:04 <zodbot> The meeting name has been set to 'fpc'
16:04:09 <abadger1999> #topic Roll Call
16:04:12 * geppetto is here
16:04:19 * RemiFedora here
16:04:27 * racor is here
16:04:39 * sgallagh lurks
16:05:47 <abadger1999> #chair geppetto RemiFedora racor
16:05:47 <zodbot> Current chairs: RemiFedora abadger1999 geppetto racor
16:06:10 <abadger1999> Rathann, SmootherFrOgZ, tibbs|w, spot, RemiFedora: FPC ping
16:06:19 <tibbs|w> Howdy.
16:06:33 <abadger1999> #chair tibbs|w
16:06:33 <zodbot> Current chairs: RemiFedora abadger1999 geppetto racor tibbs|w
16:06:36 <tibbs|w> Sorry about last week; my wife was in the hospital and I couldn't get IRC working from my phone for some reason.
16:06:41 <abadger1999> ouch.
16:06:48 <abadger1999> Hope everything is okay.
16:07:04 <tibbs|w> Yeah, she's good now.
16:07:09 <RemiFedora> :)
16:07:17 <Rathann> here
16:07:42 <abadger1999> #chair RemiFedora Rathann
16:07:42 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto racor tibbs|w
16:08:18 <abadger1999> #topic #339     software collections in Fedora
16:08:23 <abadger1999> https://fedorahosted.org/fpc/ticket/339
16:08:42 <geppetto> wheee
16:08:42 <RemiFedora> I really think we have to make some progress on this one
16:08:54 <abadger1999> geppetto: So, did you have a chance to finish out your testing?
16:08:57 <RemiFedora> Opened 9 months ago... :(
16:09:12 <geppetto> it's not finished … but we can do some stuff anyway
16:09:30 <abadger1999> RemiFedora: well -- the more I've worked with it the more comparable it becomes to "Here's guidelines for how to create dpkg's for Fedora". :-(
16:09:38 <geppetto> at worst I at least know how much I don't know about them ;)
16:10:10 <abadger1999> It's got similar concepts to regular rpm packaging but it seems like a different system.
16:10:11 <RemiFedora> I think some projects (server.. cloud...) rely on SCL.
16:10:57 <sgallagh> RemiFedora: *want to*, more than *currently do*
16:11:06 <RemiFedora> yes
16:11:25 <abadger1999> RemiFedora: Were you able to move that /etc/opt /var/opt ticket?
16:11:28 <sgallagh> In particular, I want Server to be able to ship the same version of RH Developer Toolset across releases
16:11:40 <abadger1999> sgallagh: Hmm... I don't think that will be possible.
16:11:49 <abadger1999> sgallagh: If you mean, the same SCL rpms as Red Hat ships.
16:11:56 <sgallagh> abadger1999: No, just the same versions
16:12:06 * abadger1999 not familiar with the terminology
16:12:09 <sgallagh> They don't have to be the identical RPMs
16:12:14 <sgallagh> Just provide the same end result
16:12:22 <RemiFedora> abadger1999, no real news about move "writable" part in /etc/opt, /var/opt...
16:12:25 <abadger1999> sgallagh: Ambiguity :-/
16:12:28 <sgallagh> (in terms of being able to code to the same API)
16:13:24 <abadger1999> RemiFedora: meaning, same versions of the upstream packages... but the "API" of where the code and data lives, how you enter that environment, or anything else could change?
16:13:26 <RemiFedora> perhaps we need to "explicitly" write what are the blockers
16:13:37 <abadger1999> RemiFedora: that ticket is definitely a blocker.
16:13:38 * SmootherFrOgZ is around
16:13:50 <abadger1999> * LANANA name
16:13:51 <abadger1999> * Change the vendor string to match this
16:14:00 <abadger1999> I think mmaslano and spot were working on this.
16:14:07 <sgallagh> abadger1999: I mean that if I write a package against DTS 1.0, it should be deployable on Fedora with a *compatible* set of SCLs
16:14:09 <abadger1999> * Change _sysconfdir/rpm to the rpm macrodir in /usr/lib
16:14:29 <abadger1999> I took a breif look at this before my vacation... it wasn't trivial for some reason but I don't remember why.
16:14:46 <abadger1999> * Macros to definitely define:
16:14:48 <abadger1999> * All filesystem path macros
16:14:53 <abadger1999> Those macros need to be added to the guideline
16:15:02 <abadger1999> * Macros to possibly define:
16:15:04 <abadger1999> * %scl_name appears in the metapackage template
16:15:21 <abadger1999> I have to look at my notes again to figure out what I meant here.
16:15:27 <abadger1999> * Package reviews
16:15:48 <abadger1999> I think mattdm settled this as we will do full package reviews.
16:15:58 <abadger1999> * SCL macros belong only in the SCL-branches.  not allowed in mainstream branches
16:16:23 <abadger1999> We've settled this one here but I don't know if the scl-team is willing to live by it.
16:16:31 <abadger1999> Completed:
16:16:33 <abadger1999> * We'll use fdr- as the package prefix no matter what the LANANA name is
16:16:37 <abadger1999> I think we decided that?
16:16:51 <geppetto> Not sure … but I'm fine with it
16:17:04 * abadger1999 moves the package review bullet to completed.
16:17:28 <abadger1999> That's my abbreviated punch list.  I'm still adding to it as I do more work enhancing the guidelines.
16:17:56 <abadger1999> * Figure out how to express what to put in the -scldevel subpackage vs the -build subpackage.
16:18:05 <abadger1999> RemiFedora: Is sthat one that you can help with?
16:18:58 <abadger1999> sgallagh: That may not be possible.
16:19:02 <RemiFedora> I will try to talkl with the SCL guy to have answer on this list
16:19:31 <abadger1999> sgallagh: DTS SCLs just have some problems that have to be fixed and may not fit that criteria.
16:20:33 <abadger1999> RemiFedora: okay.  Some things are just doing (like the table of filesystem macros)
16:21:04 <abadger1999> RemiFedora: others would be helped if they could explain them to you in enough detail that you could then explain them to me :-)
16:21:21 <RemiFedora> seems a plan ;)
16:21:41 <abadger1999> RemiFedora: because you and I can get together on IRC but the tz with brno means that I have 0 overlap with them.
16:21:59 <abadger1999> They're working in the 8 hours a day that I'm sleeping.
16:22:17 <RemiFedora> you sleep to much...
16:22:33 <abadger1999> RemiFedora: hah!  Other people work too little :-)
16:22:34 <sgallagh> abadger1999: Consider it a request to make it work on both ends, then :)
16:23:21 * RemiFedora notes he is on the same TZ than Brno... but very probably is more "available" online...
16:23:30 <abadger1999> sgallagh: DTS?  Who do I talk to to get changes there?  if it's the same people as are doing the work in fedora, they are very resistant to fixing things.
16:24:25 <abadger1999> Anyhow... we're at the 25 minute mark.
16:24:31 <abadger1999> Probably should move on :-)
16:24:50 <abadger1999> #topic 382 Go Packaging Draft
16:24:55 <abadger1999> https://fedorahosted.org/fpc/ticket/382
16:25:12 <abadger1999> I just updated the ticket this morning so I don't expect an answer from vbatts until next week.
16:25:30 <abadger1999> But I'll ask again, anyone want to take charge of working with vbatts on the Go Guidelines?
16:25:59 <abadger1999> I'm tied up in SCLs and Go is a second large, complex issue so I can't take on both.
16:28:11 <Rathann> hm
16:29:44 <geppetto> I'm in a similar spot with SCL, and ostree … trying to get my head around go too is not going to end well
16:30:00 <Rathann> unfortunately I don't have much time in the next two weeks
16:30:43 <abadger1999> <nod>
16:30:45 <abadger1999> Okay.
16:30:52 <abadger1999> I'll continue to do my best there.
16:31:19 <abadger1999> and either we'll handle this serially or vbatts will do most of hte heavy lifting.
16:34:08 <abadger1999> Hmm
16:34:25 <abadger1999> So The FoX ticket and the .desktop/Appdata ticket are similar.
16:34:41 <abadger1999> I promised to write up something explaining what we think in both
16:34:44 <abadger1999> and haven't had the time.
16:34:55 <abadger1999> Does anyone want to take either of those?
16:35:10 <abadger1999> They're much smaller nad more self-contained.
16:35:12 <geppetto> I can take the Appdata one
16:35:45 <geppetto> although with the holidays I can't guarantee I'll have it finished by the next meeting
16:35:59 <abadger1999> ##action geppetto to rewrite the .desktop guidelines to express our views better and help rhughes make the AppData draft match with that.
16:36:05 <abadger1999> #action geppetto to rewrite the .desktop guidelines to express our views better and help rhughes make the AppData draft match with that.
16:36:21 <abadger1999> geppetto: k.
16:36:27 <geppetto> For that we wanted to change the wording on the desktop file policy, and have Richard rewrite his proposed addition for Appdata to be similar, right?
16:36:35 <abadger1999> Right.
16:36:38 * geppetto nods
16:36:53 <abadger1999> To express that it's if you want your package to show up in a certain way, then you must do this to make that happen.
16:37:00 * geppetto nods
16:37:22 <abadger1999> Okay, I'll continue to try to get the time to writeup FOX then.
16:37:37 <abadger1999> #topic #419     ruby193 in SCL
16:37:44 <abadger1999> https://fedorahosted.org/fpc/ticket/419
16:38:44 <tibbs|w> Is this actually ready?
16:39:27 <RemiFedora> I think we still have the SCL name issue
16:39:36 <geppetto> it doesn't conform to the dots in name thing
16:39:40 <geppetto> maybe some other stuff
16:40:01 <abadger1999> So for this... It doesn't seem "ready" as in finished... but I think we could vote on whether we'd approve all of those SCLs in terms of the SCL Criteria: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#SCL_Criteria
16:40:11 <geppetto> also I'm even less convinced that we can ship a plain ruby/python stack and have it be useful
16:40:17 * abadger1999 edits the dots into names now
16:42:02 <abadger1999> The v8 SCL name... isn't okay.
16:42:18 <abadger1999> Even though it obeys the guidelines once I put the dots in.
16:42:31 <abadger1999> we need some sort of separator between the 8 and the version.
16:42:42 * abadger1999 edits package names to have the prefix
16:42:43 * RemiFedora agrees
16:43:17 <RemiFedora> abadger1999, if we add a dash betwwen name and ver, probably we need it for "all" scl
16:44:19 <abadger1999> RemiFedora: I wouldn't do a dash... OpenJDK is an example of why dash is bad.
16:44:23 <abadger1999> Maybe underscore?
16:45:38 <geppetto> maybe do that just for packages with a number in them (or those with a number at the end?)
16:45:39 <abadger1999> RemiFedora: It could be a special note: "If the base name of your SCL ends in a number, then use an undescore to separate it from the start of the embedded version:  ie: Name: fdr-v8_3.1.4
16:45:51 <abadger1999> geppetto: yeah, agreed
16:46:22 <geppetto> yeh, I'm happy with that
16:47:01 <RemiFedora> name are already quite uggly... so.. why not...
16:47:55 <geppetto> well, it'll be nice to have as little ugliness as possible … which is why no _ in the general case, is nice.
16:48:32 <geppetto> Although I do agree the scl names are pretty bad … at least they aren't as bad as some things.
16:49:28 <racor> Sorry, folks, this meeting doesn't work out for me. I got distracted on the phone and have to quit now.
16:51:16 <geppetto> we still have 5, right?
16:51:23 <abadger1999> yeah
16:51:25 <tibbs|w> I'm still around.
16:51:31 * geppetto nods
16:51:42 <tibbs|w> But my brain sort of glazes over when SCLs come up.
16:52:23 <abadger1999> Okay, I'm changing the v8 SCL to use an underscore
16:52:32 * abadger1999 makes a note to update the guidelines with that as well.
16:53:37 <abadger1999> Alright, I think that pretty much irons out hte naming.
16:54:02 <abadger1999> What else would we want to see in thesee pages as a user of a Fedora SCL?
16:54:47 <abadger1999> Like,  I'd want to see how the ruby compat guarantee relates to upstream.
16:54:55 <geppetto> So one thing I did notice is that if you change the naming to use dots, then you can't use the name directly for scl_prefix
16:55:02 <abadger1999> and whether that relates to any sort of api guarantee
16:55:14 <abadger1999> geppetto: why not?
16:55:25 <abadger1999> I think I'm doing both of those in my sample python2.4 scl.
16:57:25 <geppetto> abadger1999: sorry, not scl_prefix ... that works. It's the stuff where you double macros.
16:57:58 <abadger1999> k.  Example?
16:58:13 <geppetto> abadger1999: Eg. %global _blah_override %_@scl@_blah_override
16:58:14 * abadger1999 will check for possible errors in his sample rpms
16:58:35 <geppetto> Where you then want to replace @scl@ with %scl_prefix … so you get:
16:58:51 <geppetto> %global _blah_override %_ruby193_blah_override
16:59:19 <geppetto> That bit can't have '.' in it, because rpm doesn't allow those in macros.
16:59:29 <abadger1999> Hmm....  Shouldn't it become:
16:59:40 <abadger1999> fdr_ruby1_9_3_blah_override ?
16:59:55 <abadger1999> It already has to deal with dash, right?
17:00:58 <geppetto> Right, you can squish it back, or turn '.'/etc. into _ … just pointing out that "before" you could use it as is, and with prefix+dots you can't.
17:01:37 <geppetto> so we might want to mention that somewhere … or not.
17:02:17 <geppetto> Not sure what reminded me of that … as you were talking about ruby compat. guarantees … so sorry for derailing
17:02:49 <abadger1999> <nod>  yeah, I think it's appropriate to mention.
17:02:54 <abadger1999> Just have to figure out where.
17:03:15 <abadger1999> I wrote my python2.4 scl without those types of macros but learned that htey were a thing afterwards.
17:03:22 <abadger1999> (in relation to the scldevel subpackage)
17:03:32 <abadger1999> so I've been trying to implement an scldevel.
17:03:38 <abadger1999> and would run across it there.
17:03:48 <geppetto> And, yeh, I agree we want to see what compat. guarantees ruby has … do we expect other scls to drop modules into it … or to alter it's load path, or to just rebundle it.
17:04:39 <geppetto> all three options suck, IMO … so there's that :)
17:06:58 <abadger1999> I think remi and I were talking about other *packagers* simply adding to it.  But if you want a new scl (which adds, I'm making compat guarantees about Rails3.2.x running on ruby1.9.3) then we'd need to make sure that hte load path works.
17:07:23 <abadger1999> which I think is the way scls are designed to handle it (athough I don't know if the implementation matches).
17:07:25 <abadger1999> RemiFedora: ^
17:07:32 <abadger1999> Hmm...
17:07:37 <abadger1999> another thing about dependent SCLs....
17:07:40 <abadger1999> naming.
17:07:46 <RemiFedora> if you include a module in the "main" collection, which should be described, and part of the API gurantee
17:08:23 <abadger1999> I think both of these would be allowed under current guidelines:  fdr-python2.7  and fdr-python3.3
17:08:58 <abadger1999> And both of these: fdr-python-flask1.0  fdr-pyython-flask2.0
17:10:17 <abadger1999> but what if you want to make an fdr-python-flask1.0 scl that uses the fdr-python2.7 scl,  and someone else wants to make an fdr-python-flask1.0 scl that targets fdr-python3.3 ?
17:10:42 <RemiFedora> good question :p
17:10:45 <abadger1999> RemiFedora: hmm... that's not how I understood our discussions earlier.
17:11:03 <abadger1999> I thought we were saying the SCL maintainer controls the packages that they are listing in the SCL page.
17:11:12 <RemiFedora> yes
17:11:15 <abadger1999> But other packagers can add packages to Fedora that target the SCL.
17:11:23 <RemiFedora> yes
17:11:23 <abadger1999> those would not come with any compat guarantees.
17:11:32 <RemiFedora> yes
17:11:37 <abadger1999> would not be listed on the SCL page, etc.
17:11:52 <RemiFedora> So, if not part of the main package list, no api guaranty
17:12:03 <abadger1999> <nod>
17:12:27 <RemiFedora> But if part of the main package list, shoud also be part of the api guaranty
17:12:29 <abadger1999> So... if I have a pyhton2.7 SCL.  and geppetto has a yum3 SCL.
17:13:07 <abadger1999> and yum3 needs python2.7 and also needs python2.7 urlgrabber... we need to figure out that interaction.
17:13:17 <geppetto> yeh
17:13:35 <abadger1999> I'm thinking... someone has added fdr-python2.7-python-urlgrabber to the python2.7 SCL.
17:13:46 <RemiFedora> yes, design choice.
17:13:48 <abadger1999> geppetto could use that as part of his dep for the yum3 SCL.
17:14:03 <geppetto> the problem I forsaw was not between having flask1 using py3 and py2.7 … but if there was some intermediate dep.
17:14:12 <abadger1999> But since it's not part of the compat guarantees, he could also decide to add it to the yum3 SCL.
17:14:31 <abadger1999> As one of the packages that he depends on keeping a certain API.
17:15:12 <RemiFedora> the reason why I say the compat guarantee should apply to all the package/module in the main collection list ( not only to python or ruby)
17:15:19 <geppetto> Eg. I want flask1 on py2.7, but using postgress3 … and someone else wants bar6 on py2.7 using postgres4.
17:16:04 <geppetto> Well, psql 8 vs. 9 … but you know what I mean, I think.
17:16:13 <RemiFedora> yes, same problem already encounter in rhscl, example mod_php (for which apache ? system or scl one)
17:16:32 <abadger1999> RemiFedora: I agree if by "main collection list" you mean what is listed on the SCL Page.  Packages that other packagers have added to fedora that target the SCL are not covered by the compat guarantee (but belong to the scl in that they have the same prefix.)
17:16:44 <geppetto> yeh, and the only way out of that rabbit hole that I could see was to dump everything not in the system into the scl you were shipping.
17:17:35 <abadger1999> I think the flask1 and bar6 in your example would end up in the postgres3 and postgres4 packages.
17:17:42 <RemiFedora> geppetto, you can rely on another SCL, but only on part described and with compat guarantee
17:18:00 <abadger1999> which I suppose equates to dumping it into the scl you're shipping.
17:18:10 <abadger1999> except you might not be shipping either of hte scls.
17:18:13 <RemiFedora> (so perhaps it won't make sense to add package on someone else collection)
17:18:35 <geppetto> abadger1999: But who decides … and how? … Do we ship every python module inside your own scl … kind of defeats the point of language scls, right?
17:19:02 <geppetto> abadger1999: might as well just ship python within your scl too.
17:19:16 <abadger1999> RemiFedora: heh -- what if geppetto packages the fdr-python2.7-python-urlgrabber package though :-) Then there's not an explicit API guarantee but because he's packaging it, there's one that he's going to make sure works.
17:19:26 <RemiFedora> nightmare... if each app have to bundle its language...
17:19:44 <abadger1999> geppetto: not at the language level -- that should be covered by the compat guarantees for the SCL.
17:19:55 <geppetto> abadger1999: right … that's kind of what I'm doing at the moment … if I can ever finish it and get it to work.
17:19:59 <abadger1999> geppetto: but yeah -- for the addon libraries, there's a big grey area.
17:20:11 * RemiFedora nods
17:20:48 <RemiFedora> I think, if the python 2.7 SCL owner want to provide urlgrabber, he should have compat guarantee for it
17:21:18 <abadger1999> RemiFedora: But -- we're talking about when someone other than the SCL owner wants to ship something.
17:21:37 <abadger1999> Or even when the SCL owner wnats to ship something that's only incidental to their main purpose for the package.
17:21:55 <RemiFedora> probably make sense to have it in his yum3 scl then
17:22:02 <abadger1999> RemiFedora: For instance, if geppetto did ship urlgrabber as part of the yum3 SCL, he probably does not want to make compat guarantees about it.
17:22:13 <RemiFedora> yes
17:22:24 <abadger1999> RemiFedora: that way he can update it incompatibly if he makes a new yum3 release that needs a new urlgrabber API.
17:23:30 <geppetto> right
17:24:00 <RemiFedora> really a "grey" area. I think have to be study case per case.
17:24:27 <RemiFedora> (and I don't know anough about python.... and have think a lot for php...)
17:25:01 <abadger1999> Potential rule: try to put your package into the highest level of the stack it can be so other people can help maintain it but feel free to put it lower if you need to override someone else's version.
17:25:39 * abadger1999 thinking about how that might work with postgres
17:25:52 <RemiFedora> hm... what do you mean by "lower" / "higher" ?
17:27:00 <abadger1999> Mainstream System packages == highest level.  SCLs that only depend on mainstream packages (not other SCLs) next tier.  SCLs that depend on other SCLs the next tier.
17:27:23 <RemiFedora> I can imagine in a php scl, a php5.4-php-pgsql (for system postgresql), a ph5.4-php-pgsql92, ...
17:27:39 <RemiFedora> abadger1999, ok, so I agree.
17:27:46 <abadger1999> RemiFedora: the second one is a problem.
17:27:54 <abadger1999> RemiFedora: I think that has to go in a lower tier.
17:28:47 <abadger1999> The problem will be... we haven't made allowances for that lower tier yet.
17:28:59 * RemiFedora notice he is probably going to hurt evryone here
17:29:18 <abadger1999> both php5.4 and pgsql92 are first tier SCLs.
17:29:43 <abadger1999> ie: people are going to want to use those with just the system packages as other deps.
17:29:53 <RemiFedora> you know we alrady have some package providing different versions in system (ex php-pecl-http and php-pecl-http2), so I can imagine having both in the php54 scl...
17:30:01 <abadger1999> this really has to go into a third scl.
17:30:02 <RemiFedora> mising both world...
17:30:11 <RemiFedora> miXing
17:30:16 <abadger1999> that depends on both the php5.4 and pgsql9.2 scl.
17:30:27 <abadger1999> at the next tier down.
17:30:31 <RemiFedora> yes, this is the 'full-scl" solution
17:31:12 <abadger1999> but we currently don't have scl criteria to approve that (because it's smaller than a language stack or a "framework").  We'll have to add some criteria later to accunt for this case.
17:31:33 <abadger1999> RemiFedora: yeah -- I think mixing would be better.
17:32:19 <RemiFedora> I already done it for some extension (http and solr), where we already have 2 packages in system, simpler to have the same in the SCL
17:32:43 <RemiFedora> (because it make sense to have both available in the system, it make sense to have both in the SCL)
17:32:53 <abadger1999> RemiFedora: but we have scls because apparently providing different versions at the system level isn't always possible.  So I'm guessing that providing different versions within the scl also won't be possible in the same circumstances.
17:33:10 <abadger1999> Yeah.
17:33:43 <RemiFedora> notice, in those examples, only 1 can be installed at the same time...
17:33:56 <abadger1999> RemiFedora: oh?  Installed or used?
17:34:07 <abadger1999> If installed, then I think they break the Conflicts Guideline.
17:34:20 <RemiFedora> installed.
17:35:38 <abadger1999> yeah... that's likely a violation of hte conflicts guideline.  Although recently it was pointed out to me that the "Compat Package Conflicts" is ambiguous so some people think that's okay.
17:36:08 <abadger1999> We don't define compat packages in that section so different people have different ideas of how wide that exception is.
17:36:18 <RemiFedora> we can change them to allow install of both... but it will not work... (not able to use both)... so I don't see how it make sense to allow to install both...
17:36:39 <abadger1999> RemiFedora: that might be better.
17:36:57 <abadger1999> RemiFedora: for instance, mod_wsgi (apache module) linked against either python2 or python3.
17:37:09 <abadger1999> Can't use both at the same time because the libpython symbols conflict.
17:37:25 <abadger1999> But if the sysadmin can install both, they can run two separate apache instances on their box
17:37:47 <abadger1999> One apache for the python3 version and the other for the python2 version.
17:38:26 <RemiFedora> but default instance won't work (or will warning error on startup)
17:39:19 <abadger1999> RemiFedora: depends on what you mean -- by deafult with mod_wsgi, if both arre installed, the pyhton2 version is loaded and conditionals in the apache config keep the py3 version from loading.
17:39:21 <RemiFedora> iirc, apache just cast a warning when you try to load same module twice
17:39:28 <abadger1999> there's a comment in the config file explaining the problem.
17:39:54 <abadger1999> RemiFedora: the modules have different names, I believe, but the library symbols conflict.
17:40:08 <RemiFedora> abadger1999, And i think the conditional is not a good idea... the warning is better to raise admin attention ;)
17:40:33 <RemiFedora> well if the module have different name, this is ok
17:40:47 <abadger1999> RemiFedora: Sure -- if apache is smart enough to just raise a warning and also smart enough to always load the module that we chose as the default.
17:41:09 <abadger1999> I think we're off topic, though :-)
17:41:17 <RemiFedora> yes, we are disgressing
17:41:26 <abadger1999> So for approving the ruby SCLs...
17:41:33 <abadger1999> I have -- split page into three pages.
17:41:51 <abadger1999> I'm going to ask that release notes section be added (and add a section for that to the template)
17:42:15 <geppetto> ok
17:42:19 <abadger1999> Someone has to talk to docs about having an SCL release notes section that the rel notes authors look at the SCL templates for.
17:42:28 <abadger1999> What else still needs to be changed?
17:42:57 <RemiFedora> links ?
17:43:07 <abadger1999> https://fedoraproject.org/wiki/User:Mmaslano/Ruby193_in_SCL
17:44:09 <RemiFedora> seems minimal, but I'm fine with it
17:44:56 <RemiFedora> abadger1999, probably we need to allow a few SCL, to see how things go, what issue appear, and improve our Guidelines then
17:45:11 <RemiFedora> else we are going to be stalled for years trying to be perfect.
17:45:33 <RemiFedora> so, I think this first "ruby" one is a good candidate
17:45:34 <abadger1999> We don't have to be perfect but we do have to be acceptable.
17:45:56 <RemiFedora> yes
17:46:11 <RemiFedora> exactly what I was trying to mean
17:46:15 <abadger1999> Also unfortunately, being iterative means that the SCLs that go in have to be willing to change (even incompatibly) after approval.
17:46:45 <geppetto> yeh, and in many ways that's not a great thing to be doing inside Fedora
17:47:09 <geppetto> Would be nice if we had some option other than "yes" or "no"
17:47:40 <abadger1999> So because the scl team has been resistant to change... I suppose we've been trying to push closer to perfect from the beginning so we don't have to try to force changes on the existing packages once they're in.
17:47:51 * RemiFedora have to stop at 20:00  (in 10')
17:48:27 * geppetto nods
17:48:39 <geppetto> stopping after 2 hours is pretty std. anyway
17:48:49 <geppetto> usually need a break at that point
17:48:53 <abadger1999> <nod>
17:48:58 <geppetto> abadger1999: yeh
17:49:20 <geppetto> abadger1999: Is there anyone we could speak to about having something like a fedora-scl-testing repo?
17:49:32 <abadger1999> geppetto: besides coprs?
17:49:34 <RemiFedora> Copr ?
17:49:48 <geppetto> Well, soemthing more official than a random copr.
17:50:02 <geppetto> shipped by default, so users just have to yum-config-manager --enable fedora-scl-testing
17:50:04 <abadger1999> geppetto: env and stacks was working on a playground repo.
17:50:25 <abadger1999> That might fit the bill. (although it will have more experimental stuff besides just scls)
17:50:26 <geppetto> But something where as changes need to be made, we can make them happen or stuff won't move to fedora.
17:50:41 * geppetto nods
17:50:47 <geppetto> doesn't need to be scl specific
17:51:24 <geppetto> just something between "random copr, go away" and "you're in now, feel free to ignore everything we say"
17:52:22 <abadger1999> <nod>
17:52:33 <geppetto> I probably seem pesimistic towards scl makers … but after spending time trying to make one, I can 100% see the desire to say "lol, I'm not changing anything" after it works.
17:52:48 <abadger1999> RemiFedora: Do you want to mmaslano about the status of the playground repo/whether we can use it for this?
17:53:06 <abadger1999> geppetto: yeah -- they aren't trivial to make.
17:53:17 <RemiFedora> won't be online before monday
17:53:27 <RemiFedora> but I plan to ask her for a quick meeting
17:53:54 <abadger1999> Cool.
17:54:12 <RemiFedora> and she will (very probably) read this meeting minutes carefully
17:58:35 <abadger1999> Hmm... The detailed descriptions don't seem very targetted towards each individual SCL.
17:58:51 <abadger1999> ruby itself doesn't really need v8, does it?
17:59:10 <geppetto> I assume just rails needs that
17:59:32 <abadger1999> yeahj.
17:59:54 <geppetto> note that it's like 1 minute to go … anything we want to quickly discuss before RemiFedora has to go?
18:00:21 <abadger1999> Not from me.
18:00:36 <abadger1999> Just trying to capture everything we've discussed about the ruby SCLs in the ticket.
18:02:13 * geppetto nods
18:03:14 <abadger1999> Okay,  thanks for coming everyone!
18:03:25 <abadger1999> #endmeeting