12:02:01 <hhorak> #startmeeting Env and Stacks (2014-12-03)
12:02:01 <zodbot> Meeting started Wed Dec  3 12:02:01 2014 UTC.  The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:02:07 <hhorak> #meetingname env-and-stacks
12:02:07 <zodbot> The meeting name has been set to 'env-and-stacks'
12:02:14 <hhorak> #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell
12:02:39 <hhorak> #topic init process
12:02:52 <bkabrda> hi everyone, sorry I'm late a bit
12:02:53 <hhorak> Hi, who do we have here today?
12:03:07 <hhorak> bkabrda: not much more late than me :)
12:03:18 <ncoghlan> here :)
12:03:42 <ncoghlan> another meeting at 11 though, so I'll be leaving right on time :)
12:04:12 <hhorak> so let's make it effective today :)
12:04:26 <hhorak> #topic Follow-ups
12:05:04 <hhorak> I wanted to shortly touched the 'upstream repositories' thing
12:05:55 * bkabrda still has to deploy the testing devpi instance, but being sick and having lots of internal RH work ATM prevents him from doing so...
12:05:55 <hhorak> That we need to move some internal thoughts move to fedora, as Matt proposed..
12:06:03 <ncoghlan> #link https://fedoraproject.org/wiki/Env_and_Stacks/Projects/LanguageSpecificRepositories
12:06:30 <ncoghlan> that's the initial draft I put together after last meeting
12:08:23 <bkabrda> ncoghlan: some notes from me - the Java guys in my team has reached a conclusion that downstream maven repository wouldn't have significant benefit, so I'd say that Python is alone as a pilot right now
12:08:43 <hhorak> ncoghlan: thanks, that seems fine..
12:09:22 <ncoghlan> bkabrda: interesting quirk there is that Python is the one Pulp already has a plugin for (although I've never tried it)
12:09:42 <ncoghlan> but with only one language involved, there's less need for a generic server...
12:09:43 <bkabrda> ncoghlan: I've had a very long discussion with them and do agree with their opinions... basically, it would only make sense if we mirrored upstream maven precisely as it is, in which point we're not adding any value...
12:10:05 <ncoghlan> yeah, the ability to add wheel files makes the Python case more interesting
12:10:13 <bkabrda> ncoghlan: really? I'll need to have a look at that plugin
12:10:29 <ncoghlan> hang on, I'll find the link
12:10:50 <ncoghlan> #link https://github.com/pulp/pulp_python
12:11:09 <juhp> sorry i am late
12:11:28 <bkabrda> ncoghlan: also, I think that all points in the "Open questions" section can be summarized as (and I've been thinking about this since I started packaging devpi21 SCL): "What workflow will we use?"
12:11:29 <ncoghlan> I also started a Python upstream distutils-sig discussion regarding overriding/changing the platform tag in wheel files
12:11:40 <bkabrda> ncoghlan: yeah, I'm watching that
12:12:26 <ncoghlan> for the meeting notes: Python wheel's currently have a problem where all prebuild Linux binaries get tagged "linux_<arch"
12:12:43 <ncoghlan> which rather underspecifies the ABI they're linked against
12:13:54 <ncoghlan> I initially thought /etc/os-release might be usable for the purpose, but that *over*specifies the ABI
12:14:20 <hhorak> #info the Java guys has reached a conclusion that downstream maven repository wouldn't have significant benefit, so I'd say that Python is alone as a pilot right now
12:14:20 <hhorak> #info Python wheel's currently have a problem where all prebuild Linux binaries get tagged "linux_<arch"
12:14:27 <ncoghlan> so current thinking is more along the lines of just providing a general purpose override mechanism
12:14:58 <bkabrda> ncoghlan: also, in Fedora we have an interesting feature that I've run into just a week ago: a "generic" release: http://koji.fedoraproject.org/koji/buildinfo?buildID=587037
12:15:35 <bkabrda> I've heard it's used on custom community Fedora spins or something like that
12:15:57 <ncoghlan> huh, interesting
12:16:08 <bkabrda> the problem is that this says that distro name is not "Fedora", but "Generic"
12:16:19 <ncoghlan> I guess it may also be useful for anyone making a Fedora downstream
12:16:26 <juhp> bkabrda, right that is for unbranding
12:16:52 <bkabrda> so the only reliable way with generic-release is making sure that "fedora-release" file exists
12:16:59 <ncoghlan> bkabrda: the thing that actually made me realise /etc/os-release wouldn't work was EPEL compatibility
12:17:10 <bkabrda> otherwise there's no way to tell that the system is Fedora
12:17:25 <bkabrda> ncoghlan: hmm, good point, I haven't thought of that
12:17:37 <ncoghlan> since we'd like to share wheels across RHEL/CentOS/etc as well as across point releases within each major release series
12:19:17 <ncoghlan> so yeah, unless someone comes up with a really clever idea (happy to hear them!), "make the platform tag configurable" is likely to be our approach upstream
12:19:53 <ncoghlan> that actually allows other potentially neat things like hash based tags for a unique build set
12:20:16 <bkabrda> ncoghlan: I haven't been following the discussion closely... is there any document/proposal on this behaviour? I'm not sure what "configurable" should behave like in this case
12:20:22 <ncoghlan> so I don't actually consider it a bad outcome
12:20:28 <ncoghlan> no, that's the downside
12:20:42 <ncoghlan> more design work involved than "just use /etc/os-release"
12:22:04 <hhorak> I've kind of lost myself here, could you, guys somehow summarize what problem are we talking about? I see we need to define OS identification somehow differently for wheels, but don't follow connection..
12:22:06 <bkabrda> I need to reread the discussion on distutils mailing list to see what's up :)
12:22:20 <hhorak> bkabrda: do you have a link for the discussion?
12:23:06 <bkabrda> hhorak: yeah, give me a sec
12:23:12 <ncoghlan> my suggestion: https://mail.python.org/pipermail/distutils-sig/2014-November/025297.html
12:23:42 <bkabrda> hhorak: yeah, there you go ^^ :)
12:23:50 <ncoghlan> me explaining why it won't actually work: https://mail.python.org/pipermail/distutils-sig/2014-December/025337.html
12:24:00 <hhorak> ah, ok, thanks
12:24:08 <hhorak> #link https://mail.python.org/pipermail/distutils-sig/2014-November/025297.html
12:24:15 <hhorak> #link https://mail.python.org/pipermail/distutils-sig/2014-December/025337.html
12:26:33 <hhorak> A bit back to the general idea -- I still have a feeling that so far not enough from fedora users know some ideas like this are being discussed here, since it seems to be important enough to me to get not much feedback so far...
12:26:38 <langdon> bkabrda, so.. sorry to weigh in a little late.. but, if the java guys aren't convinced having an alt-maven is a good ideas, doesn't that somewhat kill the whole concept at large? why would ruby or node or whatever be more receptive? Python is such a unique case in the linux world I am not sure it is a representative test.
12:27:21 <hhorak> so what I'm thinking about is making it a bit more public, post some tl;dr version of the Nick's wiki page (just a link with few sentences about purpose) to give it some marketing.. or is it too soon?
12:27:28 <ncoghlan> right, I don't think it will generalise
12:27:29 <hhorak> I'd just like to see bigger part of fedora community to discuss.. and get them more involved as well...
12:27:36 <bkabrda> langdon: I think the point is to apply this concept where it makes sense. it makes sense for Python, so let's do it there; we should approach this case by case
12:28:06 <ncoghlan> hhorak: I was thinking that would be if *we* thought it was a worthy enough idea to put an actual Fedora change proposal together
12:28:33 <ncoghlan> then we'd have the broader discussion of people yelling at us what a terrible idea it is
12:29:01 <hhorak> ncoghlan: so you'd like to wait with it to be it more concrete?
12:29:05 <ncoghlan> yeah
12:29:15 <ncoghlan> at least have the devpi instance up
12:29:20 <hhorak> ncoghlan: ok
12:29:46 <ncoghlan> so we could at least have an example of using that in a Dockerfile to install a Python app
12:30:43 <ncoghlan> going back to langdon's question, I think that gets us back to the idea of a potentially more general purpose language independent tool
12:31:13 <hhorak> #info we should make some marketing for the 'upstream repository' ideas, so we get feedback from broader community, but not sooner than the devpi instance is out and we have an example of using that in a Dockerfile to install a Python app
12:31:34 <ncoghlan> I personally know a bit about two Fedora compatible user level package management tools (being NixOS and conda)
12:32:12 <langdon> where is the docu for why this is even potentially good idea? cause it doesn't sound like y'all are convinced :)
12:32:49 <ncoghlan> langdon: I'm convinced personally, but that's not the same as being sure I can sell it to FESCo :)
12:33:14 * bkabrda feels the same as ncoghlan
12:33:38 <ncoghlan> #link https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement
12:33:43 <langdon> the early discussions at flock seemed to be pretty favorable with fesco... but maybe i missed something
12:33:44 <ncoghlan> is the higher level write-up
12:33:59 <ncoghlan> I'm probably just being overly pessimistic
12:34:41 <bkabrda> I think that we just need a working proof of concept before approaching fesco with this
12:35:20 <bkabrda> and I understand that we still don't have it because of me not having enough time to deploy devpi testing instance...
12:35:31 <langdon> bkabrda, yes.. i would agreee...
12:35:33 <ncoghlan> for myself, I think it's a good idea in principle, but also still a lot of unanswered questions
12:35:41 * langdon didn't mean the 2nd part :)
12:36:02 <bkabrda> yeah, and these unanswered questions can only be solved with the testing instance, I think
12:36:19 * ncoghlan nods
12:36:25 <langdon> i think the doc misses a very important aspect of the proposal... providing a trusted source of build of "not-rpm-packages" that doesn't currently exist
12:36:54 <ncoghlan> huh, I left that out?
12:36:57 <bkabrda> langdon: source as in dist-git/tarballs cache?
12:37:29 <ncoghlan> huh, I did
12:38:01 <ncoghlan> that's kinda silly, since creating a curated repo is why *I* got interested in the first place.
12:38:28 <langdon> bkabrda, uhh... not even a 1/2 cup of coffee.. "source" as in "provider" where "provider" = fedora
12:38:36 <langdon> bkabrda, does that help?
12:39:04 <bkabrda> langdon: sorry, I don't follow. I haven't had a coffee in months :)
12:39:24 <langdon> ncoghlan, take a stab?
12:39:40 <ncoghlan> the aspects I was talking about originally: the initial review to say the licensing is sensible and the package isn't actively malicious
12:40:01 <ncoghlan> i.e. "pip install python-nation" should just fail if using the Fedora repo
12:41:12 * langdon realizes that is yet another slang term.. "take a stab" means to "give something a try" with probably the obvious, murderous, origins :)
12:41:17 <bkabrda> ncoghlan: yeah, that I understand. langdon, is that what you mean?
12:41:23 <langdon> bkabrda, yeah
12:41:46 <langdon> that isn't in the doc ncoghlan pointed at (well, i didn't see it)
12:41:53 <ncoghlan> no, its not there
12:42:11 <juhp> some langs like ruby and haskell already have user package support
12:42:18 <ncoghlan> (not for any good reason, I just forgot to include it)
12:42:27 <juhp> maybe a generic tool could wrap those dunno
12:42:36 <bkabrda> ok, so for this, we're going to do some whitelisting. I think we initially thought that we'd whitelist all packages packaged in Fedora/RHEL/RHSCL (the two former being subset of the first one, I believe)
12:42:51 <hhorak> so one missing piece on my side now, why installing python-nation would fail -- is it licensing insensible or actively malicious?
12:42:57 <bkabrda> (and packages not on whitelist would be prevented from being mirrored)
12:43:10 * hhorak is not a pythonist
12:43:12 <ncoghlan> hhorak: benignly malicious to prove a point about uncurated repos
12:43:38 <juhp> benignly?
12:43:51 <ncoghlan> Jacob Kaplan-Moss wrote it after being inspired by the "gem install ruby-nation" incident
12:44:15 <ncoghlan> juhp: it reads and uploads an md5 hash of /etc/passwd
12:44:22 <juhp> ah
12:44:22 <ncoghlan> from its setup.py
12:44:33 <juhp> ok ;)
12:44:34 <hhorak> ah, understand now
12:45:14 * langdon thinks that might be bad but is no sys-admin </snark>
12:45:37 <ncoghlan> working in upstream package management involves a lot of "well, if you insist on shooting at your own feet, try to only take out the toes you don't need" :P
12:46:14 <langdon> bkabrda, ncoghlan is mirroring sufficient? as in, don't you need to do rebuilds? or is that just for the pilot?
12:46:27 <bkabrda> langdon: mirroring is one part of it
12:46:38 <bkabrda> langdon: the second part is building binary wheels
12:46:50 <ncoghlan> step one is to mirror the sdists
12:47:02 <langdon> yeah..ok..
12:47:19 <ncoghlan> step two is TBD, because we haven't figured out where or how to build the binaries yet
12:47:23 <bkabrda> and making certain groups of them (e.g. "here you have prebuilt upstream packages that make up RHSCL 1.2")
12:48:18 <langdon> ncoghlan, just go with "qed" as certain math professors do...
12:48:19 <bkabrda> (or prebuilt packages that you can use to *extend* RHSCL 1.2... there are really tons of approaches we can try out)
12:48:46 <ncoghlan> still, we're not going to solve the whole problem tonight, and I need to head to another meeting shortly :)
12:50:17 <langdon> bkabrda, i think those are lots of "added values" beyond the original proposal.. i guess i had always thought that just providing a "trusted source" would be a strong start
12:50:37 <ncoghlan> langdon: depends on the audience
12:50:47 <bkabrda> langdon: I agree, I'm just mentioning what *further* steps we'll be able to make
12:50:58 <bkabrda> once we get the basic use case running
12:51:52 <ncoghlan> #action ncoghlan: add the "trusted curator" rationale to LanguageSpecificRepositories page
12:52:21 <langdon> bkabrda, i think it would be very helpful to capture (on the wiki page or something) the specific argument(s) against the plan from the java folks.. they seem like the most obvious candidates to me, and if they aren't convinced...
12:53:02 <bkabrda> langdon: ok, I'll ask them to create a wiki page summarizing the approaches we thought of and why we think it's not worth the effort
12:53:10 <langdon> personally, pypi is way better curated than many of the other repos
12:53:25 <bkabrda> I'll post the link to WG ML once it's ready
12:54:03 <ncoghlan> langdon: I suspect that's an artifact of the barriers to entry historically being really high
12:54:30 <langdon> bkabrda, from your last, it sounds as if the issue is not around value but around implementation, if that is the case, that is a different problem. Let's just be sure to keep the problems separate.
12:54:38 <hhorak> well, why I initially began with this topic today was that there are some similar discussions taking place internally. And I want to make sure we're all on the same page regarding to way forward.. So, I'll again point them to the Nick's text and hopefully they will join the next time :)
12:55:04 <bkabrda> langdon: no, it's around value, I just probably didn't word it right
12:55:31 <bkabrda> langdon: either way, we'll create a wiki page and you can see for yourself once it's ready :)
12:55:32 <langdon> bkabrda, s'ok more argument for a write up then
12:56:05 * langdon grumbles about feisty missing commas
12:56:37 <hhorak> #action bkabrda will ask java guys to create a wiki page summarizing the approaches we thought of and why we think it's not worth the effort + post the link to WG ML once it's ready
12:57:29 <hhorak> ok, are we done with upstream repos topic?
12:57:48 * ncoghlan nods
12:57:54 <juhp> we =they? :)
12:58:01 <ncoghlan> heh, sorry
12:58:17 <ncoghlan> that's probably a good time for me to depart, too
12:58:28 <ncoghlan> congrats on getting the CentOS SCL sig set up!
12:59:43 <hhorak> #topic SCLs and CentOS
13:00:26 <hhorak> This was meant just as a quick heads-up since SCLs are part of this group focus..
13:00:45 <hhorak> Software collections development is now slowly moving to CentOS, since that is nice open platform where software collections make much more sense.
13:01:01 <hhorak> One reason why SCLs did not happen in Fedora yet is because there is significantly lower demand for that concept.
13:01:16 <hhorak> (maybe better to use some #info here :) )
13:01:22 <hhorak> #info Software collections development is now slowly moving to CentOS, since that is nice open platform where software collections make much more sense.
13:01:49 <hhorak> #info So, what is happening is that CentOS SIG was established that would help to develop some better ecosystem around SCLs where more people can actively participate.
13:01:53 <hhorak> #link http://wiki.centos.org/SpecialInterestGroup/SCLo
13:01:58 <langdon> hhorak, can we disagree with infos? ;)
13:02:15 <hhorak> langdon: sure!
13:03:08 <hhorak> langdon: what don't you agree with?
13:03:25 <langdon> so, i think it is correct to say, centos is more receptive, but not nec. that it is a better use case :)
13:03:42 * langdon might be feeling nitpicky
13:04:11 <bkabrda> I think it's supposed to say "make much more sense than in Fedora"?
13:05:08 <hhorak> So what could be more accurate is that it does not make so much sense to use SCLs in Fedora to bring newer versions as it does in CentOS/RHEL.
13:05:13 <langdon> bkabrda, ha.. no.. i definitely disagree with that sentiment.. i think the use cases are = but know that many disagree... i just probably wouldn't make a declarative statement of the opinion
13:05:44 <bochecha> hhorak, but then in Fedora it might make a lot of sense to sometimes bring **older** versions of the stacks through SCL
13:05:47 <langdon> hhorak, newer, probably, but not necessarily (e.g. python3) but older, definitely
13:05:48 <hhorak> I think there is another use case (still valid) in fedora
13:05:49 <bkabrda> langdon: I'm speculating about what the sentence should say exactly to prevent misunderstanding. I don't agree with it either
13:06:09 * bkabrda is not making himself very clear today :)
13:06:37 <langdon> oh.. i would just propose "centos seems to like scls more than fedora" (or something better :) ) just without an opinion on "why"
13:06:53 <bkabrda> langdon: +1
13:06:57 <juhp> hmm but given the long life of EL there is obviously a stronger case of SCL for EL :)
13:07:16 <juhp> not that I am a against the fedora use case :)
13:07:25 <langdon> juhp, well.... we could loop on that for a few montths or just agree to disagree :)
13:07:27 <bkabrda> juhp: stronger case of new stuff in SCL. for Fedora, it makes perfect sense to provide SCLs with older versions of stuff...
13:07:29 <hhorak> #info better said centos seems to like scls more than fedora
13:07:51 <hhorak> (not sure how to erase already used #info, will learn for the next time :) )
13:08:05 <bkabrda> hhorak: I think #undo does that
13:08:05 <bochecha> hhorak, #undo will... undo the last #command
13:08:13 <juhp> I have to leave soon I am aftaid
13:08:14 <juhp> r
13:08:49 <juhp> langdon, no doubt - I think it is hard to argue that the case is stronger for fedora though :)
13:08:51 <hhorak> bochecha: thanks, will do the next time :)
13:09:15 * langdon admits he is good at arguing.. and often enjoys it ;)
13:09:29 * bkabrda can confirm that ;)
13:09:40 <juhp> any impact of the scl move to Centos?
13:10:08 <juhp> well might not be ideal for fedora scl... perhaps
13:10:50 <langdon> do y'all foresee "changes" coming from centos that might need to come back to fedora? (primarily thinking scl-utils rather than scls themselves)
13:11:28 <langdon> do future plans for scl-utils need to be vetted in the centos community before landing in fedora?
13:11:43 * langdon has an aversion to capital letters
13:12:07 <hhorak> juhp: if some impact, then positive imho :) since we would like to do more 'upstream development' there, which then may be quite easily moved to fedora (while fedora would be de-facto downstream)
13:12:35 <bkabrda> langdon: good question. I think that scl-utils development is still up to the upstream. I think that the upstream will reach out to stakeholders to make sure any changes are acceptable for everyone
13:12:53 <Southern_Gentlem> i am sorry people but i see this as the wrong direction, Fedora is a place if you want to do something you can do it and it then goes downstream to everything else including rhel and Centos
13:12:59 <bkabrda> langdon: and also I think that Fedora will still pick up changes in scl-utils faster
13:13:53 <langdon> Southern_Gentlem, i think that was what i was wondering... but if fedora doesn't see a need for the tech, they probably shouldn't be a "constituent" in its design
13:14:16 <bochecha> langdon, I'm not sure I've seen anywhere that Fedora doesn't see a need for the tech
13:14:37 <langdon> bochecha, could you elaborate?
13:14:37 <bkabrda> so are we talking about scl-utils or SCLs as in built collections, e.g. python33
13:14:55 <Southern_Gentlem> langdon, if there are people to work on it fedora is a great place for it to be otherwise you are creating a circular dependancy  fedora>rhel>centos>fedora
13:15:06 <bochecha> langdon, you say « if fedora doesn't see a need for the tech », so in a way, I was asking you to elaborate on what gives you this impression :)
13:15:15 <bochecha> because it's not the one I have
13:15:19 <hhorak> imho scl-utils should be taken as ordinary package -- upstream -> fedora -> centos -> ...
13:15:25 <bkabrda> hhorak: agreed
13:15:55 <bkabrda> and at the same time for SCLs as in "built collections" this approach doesn't make much sense
13:16:07 <Southern_Gentlem> fedora is a meterocisy if you have people to do it do it
13:16:14 <bkabrda> I mean why would we create python34 SCL for Fedora when Python 3.4 is already in base Fedora?
13:16:27 <Southern_Gentlem> after all thats how alot of things exist in fedora (kde etc..)
13:16:43 <bochecha> bkabrda, it's not in F20 for example
13:17:12 <bkabrda> bochecha: true, but I'm not sure that there is enough desire for it (unlike in CentOS community)
13:17:19 <langdon> bochecha, well, fedora rejected (via fpc) the scl concept as being in violation of the packaging rules = I extrapolate, fedora is not a consumer of scls (which i loosely translated to "not interested in the tech).. maybe you disagree with my rewording?
13:17:22 <bochecha> bkabrda, there is, someone even made a copr for it: https://copr.fedoraproject.org/coprs/hguemar/python34-fedora20/
13:18:02 <bochecha> langdon, what I've seen is that fesco agreed on the concept, and decided we wanted it in fedora, then tasked the fpc to figure out the « how »
13:18:08 <RemiFedora> langdon, please, "FPC not interested", which doesn't means "Fedora not interested"
13:18:25 <bochecha> langdon, the fpc never figured out the « how », but I still see Fedora contributors in general being interested in the concept
13:18:27 <bkabrda> bochecha: that's not a collection, or is it?
13:19:08 <bochecha> bkabrda, it isn't, but that doesn't matter much: what matters is that contrarily to what you said, there IS a demand in fedora for newer/older stacks to be available
13:19:14 <langdon> ha.. ok.. lets not reopen the argument.. :) how about focus on the "envs and stacks may need something like scl to fufill its mission" ... does scl-utils feature set being driven by rhel/centos impact that?
13:19:27 <bochecha> bkabrda, the fact it isn't a scl is merely due to the fact that scls are entirely unneeded for python
13:19:30 <Southern_Gentlem> guys you are arguing over symantics now , but any development needs to be fedora based.
13:19:33 <bkabrda> bochecha: yeah, I see your point, I was "justsaying"
13:19:51 <RemiFedora> Southern_Gentlem, huge +1
13:20:30 * langdon knows he saw a dead horse in here somewhere :)
13:21:23 <bkabrda> bochecha: so Python is one case, but what about Rubys, Perls, ... my point is that I'm not sure that there is enough interest for all the SCLs.
13:22:07 <langdon> bkabrda, ruby 2 & rails 4 is definitely a case for going backwards.. or are you looking for forward cases?
13:22:09 <bkabrda> and we may not like it and we may think it's the wrong way; but I think it's just a fact that we need to work with
13:22:14 <langdon> if forward.. gcc?
13:22:24 <bochecha> bkabrda, there is a difference between the scls as content, and the scl as a technology to build/distribute that content
13:22:53 <bkabrda> bochecha: I thought we were discussing the specific SCLs that would then be rebuilt for CentOS... were we not?
13:22:54 <bochecha> bkabrda, the latter seems extremely interesting, something that would provide lots of value to fedora, something we really need... even if we don't need some of the existing scls as content
13:23:08 <hhorak> #info there are still valid use cases for SCLs in Fedora
13:23:18 <langdon> bochecha, +1
13:23:29 <bkabrda> bochecha: I do agree that evolving scl-utils (SCL as a technology) should happen in Fedora first
13:23:49 * bkabrda is a bit confused
13:24:09 <bochecha> bkabrda, except that's moving to CentOS, because « fedora isn't interested » or « it makes more sense in CentOS », isn't it?
13:24:34 <hhorak> #info One specific and strong need in Fedora is to have the SCL as a technology to build/distribute that content
13:25:33 <langdon> hhorak, did you mean "SCLs as a technology should be implemented in Fedora first, irrelevant of its consumption of the content" ?
13:26:18 <bkabrda> bochecha: well, I'm quite sure that there will always be some people interested in using scl-utils in Fedora and building SCLs in Copr. and the latest upstream releases will also  reach Fedora first. so in this sense the development will still be "Fedora first"
13:26:44 <bkabrda> bochecha: I think we're actually in agreement here :)
13:27:27 <hhorak> langdon: even though I don't see much difference there, I will at least try the #undo :)
13:27:28 <hhorak> #undo
13:27:28 <zodbot> Removing item from minutes: INFO by hhorak at 13:24:34 : One specific and strong need in Fedora is to have the SCL as a technology to build/distribute that content
13:27:41 <hhorak> #info SCLs as a technology should be implemented in Fedora first, irrelevant of its consumption of the content
13:29:00 <hhorak> bkabrda: +1
13:30:53 <hhorak> and that brings me to another question I don't remember any specific decision yet -- is copr good enough tool to be source of the official bits for collections? (now thinking about particular content already, e.g. python26 collection)
13:32:38 <langdon> i thought playground (some day) would support scl, no?
13:32:43 <bkabrda> hhorak: I don't see why it wouldn't... any specific concerns?
13:33:20 <hhorak> langdon: definitely
13:33:43 <hhorak> bkabrda: no, just wanted to check if we're on the same page..
13:36:17 <hhorak> ok, thanks for all the opinions, I'll try to summarize all already made decisions and the ideas from today somehow..
13:37:43 <hhorak> And I think we're exceeding enough today.. Does anybody has something to mention?
13:39:01 <hhorak> #topic Chairman for next meeting
13:40:51 <hhorak> timeout 2 minutes for closing the meeting and for volunteer to chair the next meeting..
13:41:24 <bkabrda> not sure if I'll be able to make it next time, so I don't think I'm an ideal candidate for chairman
13:43:01 <hhorak> np, I should be here..
13:44:03 <hhorak> #endmeeting