16:02:48 <abadger1999> #startmeeting fpc
16:02:48 <zodbot> Meeting started Thu Sep  5 16:02:48 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:54 * geppetto is here
16:03:02 <abadger1999> #chair geppetto tibbs|w
16:03:02 <zodbot> Current chairs: abadger1999 geppetto tibbs|w
16:03:32 <abadger1999> racor, spot, SmootherFrOgZ: any of you here?
16:03:32 <tibbs|w> Sorry about last week.  I was at worldcon and assumed I'd have wireless there.
16:03:57 <abadger1999> tibbs|w: No problem.  conference networking often ceases to exist.
16:04:13 * racor is here
16:04:26 <abadger1999> that's foure of us... Not enough for quorum.
16:04:34 <tibbs|w> Actually they didn't even have public wireless at all.
16:04:49 <abadger1999> Are there any items that we'd like to discuss so that we could vote on them in ticket?
16:05:11 * SmootherFrOgZ is here
16:05:26 <abadger1999> tibbs|w: interesting.  I didn't think conferences without at least attempted wifi existed anymore :-)
16:05:33 <abadger1999> Cool, that makes 5.
16:06:29 <abadger1999> geppetto: Was there an agenda announced htis week?  (I go down the list of agenda items if it was published).
16:06:35 <geppetto> yeh
16:06:39 * abadger1999 finds it
16:07:27 <SmootherFrOgZ> abadger1999: still need to finish up the new workflow so you will found them quickly
16:07:45 <geppetto> abadger1999: https://lists.fedoraproject.org/pipermail/devel/2013-September/188728.html
16:07:52 <abadger1999> #topic %doc and %_pkgdocdir duplicate files and cause conflicts https://fedorahosted.org/fpc/ticket/338
16:07:55 <abadger1999> geppetto: thanks
16:10:33 <abadger1999> So... We have a problem.  It seems to have been exacerbated by the unversioned docdir change (but existed before that).
16:11:23 <geppetto> I'm tempted to agree to banning %doc
16:11:31 <abadger1999> One potential fix is to tell packagers not to mix %doc with manual installation of docs within one spec file.
16:11:47 <tibbs|w> To be honest I didn't realize you could even do that.
16:12:34 <abadger1999> geppetto: I'd be for that if manual installation is being done.  (ie: no mixing).
16:13:09 * geppetto nods … that's fair enough, I guess there are probably some packages which only have %doc … although hopefully not that many.
16:13:22 <abadger1999> tibbs|w: I didn't either.   scop says that it wentinto rpm-4.9.1.
16:13:36 <racor> tibbs|w: You and and you could. Actually I think the unversioned docdir changes expose such cases. Before, in such cases, rpm swept away dirs.
16:14:08 <abadger1999> racor: https://fedorahosted.org/fpc/ticket/338#comment:5  rpm-4.9.1 change, not the unversioned docdir change.
16:17:16 <abadger1999> proposal:  Add "Packages must not use both relative %doc in the %files section and manual installation of documentation files into %{_docdir} in a single spec file" somewhere in the guidelines (I'll probably find where we added the unversioned docdir change and put it there)
16:17:34 <geppetto> +1
16:17:34 <racor> abadger1996: .. then in rpm >= 4.9.1 with versioned docdir, docs must have been  copied twice to the same location, if mixing %doc and explict install rules.
16:18:33 <racor> with unversioned docdirs w/o using _pkgdocdir  they get copied to different locations => duplicates.
16:18:36 <SmootherFrOgZ> +1 on proposal
16:19:09 <abadger1999> +1
16:19:10 <tibbs|w> +1
16:19:29 <racor> -1
16:19:50 <geppetto> racor: What would you prefer?
16:20:14 <racor> right now, I do not understand what you are aiming at.
16:20:42 <racor> conversely, I've seen cases where mixing %doc with %docdir was the solution to doc-packaging.
16:20:55 <geppetto> People install lots of things in docdir, and have a subpackage … main package has %doc AUTHORS … and that dumps all the docs in there too.
16:21:21 <racor> That said, I consider accepting this prpoposal at this point in time to be premature
16:21:42 <geppetto> I can't think of any cases where it isn't easy enough to just add the cp -a for AUTHORS or whatever, instead of using %doc.
16:22:14 <racor> geppetto: The classic situation is %configure --docdir=%{_pkgdir}, combined with %doc COPYING AUTHORS
16:22:43 <geppetto> racor: Again … you can replace the last bit with a cp -a, and listing those files in %files explicitly.
16:23:19 <racor> geppetto: Again, %doc COPYING AUTHORS had worked for decades.
16:23:39 <racor> ... is being used in 1000s of packages
16:23:49 <geppetto> but it's broken now due to unversioned docdir.
16:24:01 <racor> ... which means banning %doc <rel files> is an utter nonsense
16:24:11 <racor> geppetto: No, it is not
16:26:52 <geppetto> abadger1999: I guess we move on, come back to it another week.
16:27:01 <abadger1999> yeah.
16:27:29 <abadger1999> also, afaics, we didn't add anything about using pkgdocdir to the guidelines.
16:28:26 <racor> geppetto: What is needed is to adopt this presumably handful of packages which has visible issue to the new behavior, not forcing 1000s packages to be modified.
16:29:34 <geppetto> racor: You could alter the proposal to add words about there needing to be a sub-pacakge as well, I guess.
16:30:00 <geppetto> racor: But that seems over complicated … and people are unlikely to remember that timebomb if they ever decide to split their package at a later time.
16:30:54 <abadger1999> racor: I could try and draft something that says not to mix manual installation into the directory used by %doc with %doc.  that would be the same as what rpm  < 4.9.1 made problematic.
16:31:01 <abadger1999> racor: Would that be more acceptable?
16:31:28 * abadger1999 just has to figure out how to explain that simply.
16:32:13 <racor> abadger1999: I am not sure. Probably not, because I don't think the current behavior is broken by any means. It has changed, yes, but that's it.
16:32:31 <abadger1999> k
16:32:38 <abadger1999> Well, we should just revisit next week then.
16:33:05 <abadger1999> I'll try to write up a complete draft so that people can vote in ticket if needed.
16:36:12 <abadger1999> #topic #336     Please clarify the General Naming Guidelines for packages https://fedorahosted.org/fpc/ticket/336
16:37:44 <abadger1999> I don't think we can pass this today since racor and I are on opposite sides of this debate.
16:37:53 <abadger1999> But does anyone want to discus this?
16:38:46 <abadger1999> Is general sentiment that we want to emphasize maintainer discretion or that we want to emphasize following the tarball?
16:39:05 <tibbs|w> Personally I strongly prefer trying to have consistent package names rather than just using whatever random convention upstream may have used for a particular tarball.
16:39:07 <abadger1999> Someone can propose a draft and we can vote in ticket if we know that.
16:39:14 <abadger1999> <nod>
16:39:16 <tibbs|w> That means all lower case, dashes instead of underscores, etc.
16:39:18 <geppetto> Yeh, +1 to tibbs.
16:39:32 <geppetto> I'm not sure "maintainer discretion" is the best way of saying that.
16:39:48 <geppetto> But certainly "distro. discretion" over upstream.
16:40:15 <abadger1999> tibbs|w: +1 to that desire.  and yeah, geppetto, I agree if we moved in that direction it's not maintainer discretion either.
16:40:43 <geppetto> If we don't say so already I'd add that it'd be nice to say "add a provide for the upstream name".
16:40:44 <tibbs|w> Well, we could say "maintainer discretion but here are the recommendations"
16:41:13 <tibbs|w> Sometimes upstream is adamant about how a package gets named, because one distro did things a certain way and they want the rest to follow.
16:41:20 <racor> abadger1999: I wonder why we are discussing this at all. We repeatedly had discussed this topic before, and ... seems to me as if each generation of newbies wants to propagate their Ubuntu habit to Fedora
16:41:29 <geppetto> Sometimes upstream don't get what they want.
16:41:31 <tibbs|w> So there's a balance to be struck.  But having to remember case just to yum install something kind of sucks.
16:42:09 <racor> tibbs: Yum supports case-insensitive search for quite a while
16:42:57 <abadger1999> racor: IIRC, every time we (FPC) discuss this, it's contentious and leads to some sort of compromise wording.
16:44:18 <abadger1999> which is likely why we're discussing it again -- the current FPC members are different than the previous ones who discussed it and may want to swing the compromise in a different direction.
16:45:38 <abadger1999> Sounds like we're split but both sides would like to see if we can make more of a distro-policy than before.
16:45:50 <abadger1999> does anyone wnat to write up a draft?
16:46:58 <abadger1999> if not, I'll stick it on my huge FPC-draft-todo list but might not get to it soon.
16:47:13 * geppetto nods … probably fine at the bottom of the list
16:47:46 <geppetto> as much as I'd kind of like to vote +1 on "packages must be lower case and use '-' and not '_', I'm not sure it's worth the effort to write it"
16:48:15 <racor> abadger1999: with all due respect, but you don't want to know what I think about this "swinging majority games"
16:49:20 <abadger1999> racor: yeah, I don't usually like them either but -- 1) it can't be helped 2) philosophies do have to be allowed to evolve.
16:49:31 <abadger1999> so *shrug*
16:50:11 <abadger1999> #topic #337     Guidelines needed for header only libraries https://fedorahosted.org/fpc/ticket/337
16:51:18 <abadger1999> I like the direction of this ticket.
16:51:22 <abadger1999> But there's no draft.
16:51:49 <abadger1999> Do other people have any comments on it?
16:52:17 <orionp> I suppose I could be roped into writing one if I had suggestions
16:52:18 <geppetto> just that it seems fine to me, seems like we should treat these much like static only libs.
16:52:39 <abadger1999> orionp: Cool :)
16:52:53 <racor> abadger1999: Guidelines exist to be enforced and refined, not to be redefined, for reasons of personal taste.
16:54:15 <abadger1999> orionp: Okay, I think we do like the idea of treating them like static libs.
16:54:58 <orionp> My first question was whether to reuse the "-static" name, or have something else.
16:55:07 <orionp> Is there a meaningful difference?
16:55:21 <abadger1999> I don't think we need a separate -headers suffix from a techical perspecitve.
16:55:29 <abadger1999> Not sure about hte confusion factor, though.
16:55:46 <racor> abadger1999: I like the idea of using *-static
16:55:54 <abadger1999> It might be confusing to people why they follow the static library guidelines when they're just using headers.
16:56:16 <abadger1999> otoh, it'll likely be confusing to people packaging "normal" libraries why they don't have a -header subpackage
16:57:33 <abadger1999> orionp: I think I lean towards reusing -static as it's already there and fits the actual use.
16:57:39 * orionp has always felt it's been hard to enforce dependencies to use -static
16:58:19 <racor> abadger1999: It might also be confusing, when they hear that they are supposed to provide *-devel, also (IIRC, we have a rule that *-static must R: -devel or P: *-devel)
16:58:20 <geppetto> yeh, I think the fit -static close enough ("library package" needed to build, not needed after build).
17:00:22 <abadger1999> orionp: k.  Does that answer that question?
17:00:57 <orionp> So, treat them just like static libraries?  Seems reasonable.
17:01:40 <orionp> Should there also be a recommendation to make the -devel/-static package noarch and keep the main arch specific for tests?
17:02:47 <abadger1999> orionp: I like the main package being arch ful for tests.  The -devel/-static.... there could be cases  where they need to be archful as well.
17:03:17 <orionp> right - but suggest noarch where possible?
17:03:19 <abadger1999> I've always been uncomfortable with people making headers noarch because they may miss an architecture-related conditional in ther.
17:03:44 <abadger1999> allowed but not suggested?  that would be my preference.
17:04:03 <orionp> okay.  anyone else?
17:04:31 <abadger1999> I'd probably still vote +1 if you were adamant that it should be suggested, though.
17:05:35 <geppetto> yeh, pretty much agree with abadger1999 :)
17:07:16 <abadger1999> orionp: Okay, I think that's everyone who cares :-)
17:07:37 <geppetto> abadger1999: You want to skip 339? :)
17:07:40 <abadger1999> orionp: anything else you need to make a draft?
17:07:51 <orionp> I don't think so.
17:07:59 <abadger1999> Cool.
17:08:15 <abadger1999> geppetto: So..... we're at the end of our hour.
17:08:39 <geppetto> yeh, wasn't sure if you wanted to try and do some of 40/41/43 so we can catch up a bit.
17:08:46 <orionp> Could I please get the copylib  issue for x2goclient addressed?
17:08:59 <abadger1999> We should look at 43
17:09:14 <abadger1999> #topic #343     copylib bundling exception for qtbrowserplugin in x2goclient https://fedorahosted.org/fpc/ticket/343
17:09:53 <abadger1999> So this is needed for a Fedora 20 Change.
17:10:11 <geppetto> that is … not small.
17:10:58 <geppetto> from a rough guess, it'd be copying over 2k
17:11:28 <geppetto> orionp: Is the bit you want to copy much small than the entire thing?
17:12:02 <orionp> Well, pretty much the whole thing is in x2goclient
17:12:55 <geppetto> I'm tempted to say -1 then, and just make a new package … maybe as a -static lib. if API or building as shared is a problem.
17:13:05 <orionp> It seems to be how the qtbrowserplugin upstream expects it to be used
17:13:29 <orionp> There are no upstream methods for building it as a library
17:13:47 <orionp> I tried, but end up with an undefined symbol
17:13:51 <SmootherFrOgZ> +1 with geppetto, although I think we should dig more into what's up with building as shared.
17:14:17 <geppetto> orionp: That was as a shared lib. though, right? … or did you try building a static lib. and that failed?
17:14:30 <SmootherFrOgZ> orionp: would you mind share your test on the ticket so we can look at it?
17:14:41 <orionp> I did shared, but i wouldn't have imagined that mattered
17:14:59 <SmootherFrOgZ> ah, didn't notice. will double check then
17:18:01 <abadger1999> SmootherFrOgZ: orionp was answering geppetto :-)
17:18:04 <geppetto> orionp: Yeh, it looks like the instantiate stuff goes in the main program via. the QTNPFACTORY_BEGIN/END thing … and that problem will go away if you make it static.
17:18:55 <orionp> so, how to make a static lib with qmake?
17:19:31 <orionp> ah CONFIG+=staticlib
17:19:33 <orionp> will try
17:19:40 <SmootherFrOgZ> orionp: that's it
17:19:56 <SmootherFrOgZ> you can even just put "static"
17:20:14 <SmootherFrOgZ> abadger1999: thx, indeed.
17:20:35 <abadger1999> Cool.  So we'll see if that works and get back to this if it doesn't.
17:20:59 <orionp> okay
17:24:56 <abadger1999> Okay. do we still have quorum?
17:25:11 <abadger1999> if so, this one looks doable.
17:25:25 <tibbs|w> I'm still around, mostly.
17:25:25 <abadger1999> #topic How to replace "docker" package with an entirely different package of the same name? https://fedorahosted.org/fpc/ticket/341
17:26:22 * SmootherFrOgZ is still here
17:26:32 <geppetto> I'm in two minds about this … docker seems so generic, and it's not obvious if Fedora will be using this eventually … so having it called docker.io instead doesn't seem like a big deal.
17:26:35 <abadger1999> So the basic question here is value for people who have already installed the current docker package vs people who are going to be interested installing the new docker package.
17:27:01 <tibbs|w> Is the old package retired or something?
17:27:05 <geppetto> no
17:27:11 <abadger1999> tibbs|w: the old package is going to rename to wmdocker.
17:27:15 <tibbs|w> Ah, I see that now.
17:27:15 <geppetto> just "not that many people use it, probably"
17:27:31 <abadger1999> mattdm: just to let you know, we're discussing docker.
17:27:38 <tibbs|w> There is no way to do what appears to be wanted.
17:27:46 <mattdm> abadger1999 hi I just noticed. thanks.
17:27:49 <abadger1999> epoch will work I think.
17:27:57 <tibbs|w> Nope.
17:28:06 <tibbs|w> Because on upgrade you'll get the new package and all of its dependencies.
17:28:13 <tibbs|w> Rename and retire the existing docker package.
17:28:15 <tibbs|w> Wait two releases.
17:28:19 <tibbs|w> Then you can have the name.
17:28:27 <mattdm> two releases = a whole year
17:28:29 <mattdm> possibly more
17:28:34 <tibbs|w> Precisely.
17:28:35 <mattdm> that puts fedora in a bad position.
17:28:45 <tibbs|w> It gets to have some other name for that time.
17:29:01 <misc> mattdm: but doesn't docker depend on unmerged kernel patch like aufs ?
17:29:03 <mattdm> which seems silly to be in over a small package from 2003 whose maintainer is happy to rename
17:29:05 <geppetto> tibbs: It will mostly work with obsoletes.
17:29:07 <tibbs|w> The only people in a bad position are the ones who chose a name which had obviously been used for ages.
17:29:16 <misc> ( ie, we may not be able to package it for a while )
17:29:27 <mattdm> misc we're going to land it using a different device-mapper based approach
17:29:30 <geppetto> But that assumes we want to do it, which I'm not convinced of.
17:29:41 <mattdm> tibbs|w all the good names are taken by _something_
17:29:52 <tibbs|w> And that is somehow Fedora's fault?
17:29:55 <misc> mattdm: shiny :)
17:30:04 <tibbs|w> I mean, I just don't see how any of this puts Fedora in a bad position.
17:30:06 <geppetto> mattdm: Using docker.io for the name seems good enough IMO
17:30:07 <misc> but there is a precendent, see git vs git-core
17:30:10 <tibbs|w> Rename the old package out, wait, rename the new package in.
17:30:14 <geppetto> mattdm: Using "docker" is very generic
17:30:52 <tibbs|w> But if this can be done smoothly with versioned obsoletes, then fine, but even then you get to deal with epoch.
17:30:53 <mattdm> tibbs|w we look silly because we are blocked from using a natural package name because of an basically abandoned and completely unrelated package from 2003
17:31:20 <mattdm> the intersection between someone wanted to install both packages is very small
17:32:12 <mattdm> at least carrying an epoch isn't (unless things break) user-facing
17:32:20 <mattdm> but it also seems less desirable
17:32:35 <abadger1999> From the name perspective alone (not the how question) -- I think that precedent allows this if the two maintainers agree.
17:33:18 <abadger1999> http://fedoraproject.org/wiki/Packaging:Conflicts#Conflicting_Package_Names
17:34:00 <geppetto> Fair enough … so from a purely technical POV … using obsoletes for the rename on the wmdocker package will work near 100% of the time.
17:34:30 <geppetto> Basically the user has to do an upgrade and turn obsoletes off, to break it.
17:35:02 <geppetto> So if we aren't deciding if it _should_ happen … then I'm pretty sure it's doable.
17:35:37 <abadger1999> <nod>
17:35:58 <mattdm> So, the release-notes alternative that i'm advocating is that nothing obsoletes anything. In the release notes, we say "if you had docker installed and upgraded, you now have a differnet program with the same name. don't panic -- install wmdocker and remove docker".
17:36:17 <geppetto> Yeh, so -666 on rel-notes only.
17:36:26 <mattdm> except actually since the new program is a lower version number that won't even happen.
17:36:34 <geppetto> Nobody reads release notes … I know because I don't read release notes before upgrading ;)
17:36:41 <mattdm> what will happen is that the upgrade will just keep working
17:36:56 <mattdm> geppetto so put it in commonbugs.
17:37:04 <geppetto> mattdm: You need to use epoch, of the obsoletes will hit the new package.
17:37:20 <mattdm> i'm suggesting not putting any obsoletes in at all.
17:37:30 <geppetto> Yeh, instead of creating a bug and documenting it … just don't create the bug.
17:37:54 <geppetto> What is the gain of not having the obsoletes?
17:38:26 <mattdm> I don't think the bug will affect very many people.
17:38:37 <mattdm> we don't have to carry around an epoch forever?
17:38:42 <geppetto> IMNSHO that's a terrible reason.
17:39:24 <mattdm> I'm okay with doing it if that's what has to be done. I'd just rather have a little bit of pain once and then it's done.
17:40:10 <geppetto> I don't see the pain in doing it properly using epoch+obsoletes.
17:40:49 <mattdm> okay :)
17:41:20 <abadger1999> geppetto: Here's a convuluted hypothetical: what affect will the Obsoletes: docker < 1.5 have if the new package was named docker.io but had a Provides: docker-0.5 ?
17:42:32 <abadger1999> will the Obsoletes cause the wmdocker package to be installed as an upgrade if docker.io is installed?  Will yum install docker choose to install wmdocker?
17:43:34 <geppetto> abadger1999: obsoletes only work on package names
17:44:04 <geppetto> And "yum install foo" first looks for package name matches, then for provides.
17:44:40 <abadger1999> Okay.  So the upgrade should work.  The yum install foo will run into problems if wmdocker has a Provides: docker = 1.5
17:44:41 <geppetto> So that would work, and not require an epoch in docker.io.
17:44:54 <abadger1999> but would be okay if that Provides was omitted.
17:44:57 <abadger1999> <nod>
17:45:12 <geppetto> Yeh, if wmdocker also did a provides then wmdocker and docker.io would hit compare_providers.
17:45:13 <abadger1999> mattdm: What do you think about that alternative?
17:45:39 <geppetto> But if docker.io was the only one that did the provides then it'd be the same as naming it docker and using an epoch.
17:45:59 <mattdm> i'm still trying to wrap my head around how that works :)
17:46:26 <geppetto> mattdm: Basically wmdocker does the rename as before, you all the new thing docker.io and add a provides.
17:46:31 <abadger1999> geppetto: <nod> except that in the future (2 fedora releases from now), the Obsoletes can be dropped from wmdocker and mattdm can rename docker.io to docker without using an epoch.
17:46:40 <geppetto> abadger1999: yeh
17:46:47 <mattdm> I think i can live with that.
17:47:44 <mattdm> more excited about something that'd get it named docker for f20, but if that's not reasonable I'll take the next-best thing.
17:48:58 <abadger1999> Proposal: Allow the wmdocker rename to omit the Provides: docker [It will keep the Obsoletes: docker for the standard 2 fedora releases].  This means that docker.io can go in with a Provides: docker now and be renamed to docker when the Obsoletes are removed.
17:49:16 <abadger1999> +1
17:49:58 <tibbs|w> +1
17:50:25 <geppetto> +1
17:50:48 <abadger1999> SmootherFrOgZ, racor: Voting on a proposal to resolve How to replace "docker" package with an entirely different package of the same name? https://fedorahosted.org/fpc/ticket/341
17:50:55 <abadger1999> If you guys are still around.
17:51:46 <SmootherFrOgZ> sure
17:51:50 <SmootherFrOgZ> +1
17:52:13 <abadger1999> Okay, that's +4.  I'll ask that we get more votes in the ticket.
17:52:25 <mattdm> thanks everyone!
17:52:45 <abadger1999> #info Proposal: Allow the wmdocker rename to omit the Provides: docker [It will keep the Obsoletes: docker for the standard 2 fedora releases].  This means that docker.io can go in with a Provides: docker now and be renamed to docker when the Obsoletes are removed.  (Currently +4.  need more votes in ticket)
17:52:54 <abadger1999> Oh there was one other thing we were voting on in ticket.
17:54:16 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/318 broken scriptlets %systemd_post
17:54:33 <abadger1999> Proposal is:
17:54:34 <abadger1999> Proposal: Add BuildRequires?: systemd to the examples here:
17:54:36 <abadger1999> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29
17:54:39 <tibbs|w> Sorry, should have +1'd that earlier.
17:54:47 <geppetto> yeh, fine, +1
17:55:06 <abadger1999> SmootherFrOgZ: Want to vote on that^ it'll get us to +5 if you do.
17:55:34 * SmootherFrOgZ was reading
17:55:37 <SmootherFrOgZ> +1
17:56:10 <abadger1999> #info Add BuildRequires?: systemd to the examples (.fpc 318) passes, (+1:5, 0:0, -1:0)
17:56:18 <abadger1999> #topic Open Floor
17:56:27 <abadger1999> Okay, we're at the end of two hours.
17:56:38 <abadger1999> anyone have anything they want to put on our radar?
17:56:44 <SmootherFrOgZ> :)
17:57:04 * SmootherFrOgZ has nothing more to discuss
17:57:15 <abadger1999> (SCLs have moved up the list -- I think we'll all need to ask questions about that this week/be ready to discuss it next week).
17:57:42 <tibbs|w> A lot of the SCL stuff seemed to be directed towards EPEL, though.
17:57:53 <tibbs|w> At least that's how I read the motivation in the ticket.
17:58:01 <abadger1999> yeah -- and other parts towards the not yet defined ring2/3
17:58:41 <abadger1999> mattdm: ^ I envision scls being able to be in fedora commons as well as in ring2/3.
17:58:52 <abadger1999> mattdm: is there any problem with us proceeding on that basis?
17:59:13 <mattdm> abadger1999 That seems reasonable, yes.
17:59:36 <abadger1999> Cool.  I'll write that to the ticket.
17:59:41 <mattdm> tibbs|w I have strong motivation to have it in Fedora too
18:00:04 <tibbs|w> And we had strong motivation to keep the insanity out of Fedora the last time this came up.
18:00:17 <tibbs|w> But I'm guessing I'm not going to win that argument.
18:00:19 <mattdm> because I'd like to be able to easily provide the older rails stack once rails goes to 4.0 in f20
18:00:36 <mattdm> This version attempts to keep the insanity to a minimum
18:03:01 <abadger1999> Okay, so more scl stuff in ticket, on ml, and then discussion in next week's meeting.
18:03:16 <abadger1999> I'll close in 60s if there's nothing else for open floor.
18:04:18 <abadger1999> #endmeeting