15:02:51 <dmsimard> #startmeeting RDO meeting - 2017-11-15
15:02:51 <openstack> Meeting started Wed Nov 15 15:02:51 2017 UTC and is due to finish in 60 minutes.  The chair is dmsimard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:55 <openstack> The meeting name has been set to 'rdo_meeting___2017_11_15'
15:03:01 <jpena> o/
15:03:09 <dmsimard> #chair hguemar myoung jpena jruzicka
15:03:10 <openstack> Current chairs: dmsimard hguemar jpena jruzicka myoung
15:03:21 * Duck o/
15:03:21 <amoralej> o/
15:03:34 <dmsimard> #chair Duck amoralej
15:03:35 <openstack> Current chairs: Duck amoralej dmsimard hguemar jpena jruzicka myoung
15:03:37 <dmsimard> #topic rollcall
15:03:42 <hguemar> Yep
15:03:46 <hguemar> o/
15:03:57 <chandankumar> \o/
15:03:58 <dmsimard> hguemar: feel free to take over :D
15:04:36 <adarazs|ruck> o/
15:04:43 <hguemar> #nick adarazs|ruck
15:04:48 <hguemar> I guess we have quorum now
15:04:54 <hguemar> #topic Queens Test day
15:05:03 <hguemar> Anyone who has info about it?
15:05:18 <hguemar> I'm not sure that I could help since I have no network at home tomorrow
15:05:23 <adarazs|ruck> #chair adarazs|ruck
15:05:35 <dmsimard> When is it ?
15:05:35 <adarazs|ruck> hmm, I guess I can't add myself :)
15:05:40 <dmsimard> I guess tomorrow ?
15:05:40 <hguemar> #chair  adarazs|ruck
15:05:41 <openstack> Current chairs: Duck adarazs|ruck amoralej dmsimard hguemar jpena jruzicka myoung
15:05:49 <hguemar> sorry, I used wrong command
15:06:03 <adarazs|ruck> np :)
15:06:05 <hguemar> dmsimard: yes, tomorrow and friday but is anyone leading that?
15:06:43 <hguemar> https://www.rdoproject.org/testday/queens/milestone1/
15:07:09 <amoralej> i'll check #rdo if someone asks for help
15:07:10 <dmsimard> wow we need to update that
15:07:12 <dmsimard> there's a bunch of mistakes
15:07:17 <hguemar> Well, since I don't know when rbowen will be back, would someone step up to lead that
15:07:24 <dmsimard> stuff around 7.3 upgrading to 7.4
15:07:25 <hguemar> dmsimard: please fix it then!
15:07:25 <ykarel> o/
15:07:27 <amoralej> we still have the 7.3
15:07:29 <amoralej> yeahh
15:07:32 <dmsimard> yeah I can send a patch
15:07:42 <hguemar> volunteer to lead test day?
15:07:43 <weshay> o/
15:07:54 <hguemar> #chair ykarel amoralej  weshay
15:07:54 <openstack> Current chairs: Duck adarazs|ruck amoralej dmsimard hguemar jpena jruzicka myoung weshay ykarel
15:08:03 <dmsimard> I can't quite lead but I'll be there to help with questions and general help
15:08:44 <hguemar> dmsimard: well, if rbowen is back tomorrow, it'll be good enough, I just want to avoid that it fails because nobody is testing or reporting issues
15:09:01 <hguemar> Well
15:09:07 <chandankumar> \o
15:09:17 <hguemar> #action hguemar sends reminder about test day on user/devel lists
15:09:20 <hguemar> #chair chandankumar
15:09:21 <openstack> Current chairs: Duck adarazs|ruck amoralej chandankumar dmsimard hguemar jpena jruzicka myoung weshay ykarel
15:09:29 <hguemar> Let's move to the next topic
15:09:46 <hguemar> #topic rdopkg: what to do with `rdopkg update-patches`?
15:09:49 <hguemar> jruzicka: ^
15:09:50 <jruzicka> hai
15:10:14 <jruzicka> #info `rdopkg patch -l --bump-only` is smarter and more robust alternative to old `rdopkg update-patches` (which is in turn a rewrite on ancient `update-patches.sh` script that started this whole patches branch thing)
15:10:30 <jruzicka> #info users tell me it's convenient to have a `rdopkg patch`-like action that is guaranteed to work on local patches branch and not overwrite it (implicit -l/--local-patches)
15:11:00 <hguemar> b is fine with me, but I'd add a big deprecation warning
15:11:11 <jruzicka> this is basically about two actions doing similar thing so it would make sense to unify them as much as possible but we have a legacy usage to consider as well
15:11:19 <jruzicka> jschlueter, jjoyce ^
15:11:39 <hguemar> jruzicka: IMHO, it has to be removed but we have to give time for people to fix their tooling
15:11:49 <jruzicka> options:
15:11:56 <jruzicka> a) leave it as is - a legacy (replace obsolete warning with info about `rdopkg patch -l` alternative)
15:12:03 <jruzicka> b) make it `rdopkg patch --local-patches [--no-bump]` alias which might lead to slight change of behavior but same code path for both actions.
15:12:43 <jruzicka> hguemar, I'm fine with either way, I'd hope some users would help me decide :)
15:13:10 <jruzicka> given b), should we preserve the --no-bump behavior as well? (.spec Release isn't bumped by default)
15:13:13 <hguemar> b is better as it allows removing dead code, but yeah up to users to decide
15:13:46 <jruzicka> hguemar, correct, I'd slightly prefer b) although much of the code is still reused, it's just different code path throught it with different perks :)
15:14:15 <jjoyce> jruzicka: I don't use update-patches any longer so my workflow is to always use patch -l
15:14:56 <jruzicka> jjoyce, cool.
15:15:13 <jruzicka> allright, that's something. Let's move on.
15:15:50 <jruzicka> jjoyce, hguemar btw do you ever use `rdopkg patch --no-bump/-B`?
15:16:16 <hguemar> jruzicka: I only use automatic bumps with new-version
15:16:55 <hguemar> nice to have as a feature but I like having separate commits for bumps (easier cherry-picks)
15:16:58 <jruzicka> also, there already is obsolete removal warning in update-patches, so it can be even removed
15:17:24 <hguemar> Then I think we have consensus on option b) (at least a soft one)
15:17:41 <jruzicka> hguemar, yeah, I'll discuss with jschlueter who wanted to preserve update-patches.
15:17:43 <hguemar> soft consensus == nobody disagree, hard consensus == everyone agree
15:17:47 <jruzicka> hguemar, let's move on
15:17:58 <hguemar> #action jruzicka discuss rdopkg update-patches with jschlueter
15:18:21 <hguemar> #topic rdopkg .spec Release bumping
15:18:30 <hguemar> jruzicka: again ^
15:18:43 <jruzicka> As part of automatic DLRN Release bumping support, I'd like to give rdopkg users a way to specify howto bump release
15:19:13 <jruzicka> #info under review with some relevant comments: https://softwarefactory-project.io/r/#/c/10200/
15:19:15 <amoralej> jruzicka, will default keep as-is?
15:19:15 <jjoyce> jruzicka: From time to time I use it, but not too often.
15:19:37 <jjoyce> jruzicka: Rebase to a tag with extra patches, is when I use it.
15:20:02 <hguemar> I have yet to chime in, so no opinion for now
15:20:06 <jruzicka> amoralej, default stays the same, it only changes for DLRN Releases and as there is automagic involved, I added manual control.
15:20:20 <amoralej> jruzicka, ok
15:20:23 <jruzicka> The main question is when you specify you want to bump 2nd release part of a release like 1.2.3 (`-R 2`), what should happen?
15:20:28 * hguemar wants to see how we handle pre/post-releases which is tricky
15:20:34 <jruzicka> Given Release: 1.2.3
15:20:34 <jruzicka> When bumping 2nd Release part (Y of X.Y.Z, minor version) using `-R 2`/`-R Y`/`-R minor`
15:20:34 <jruzicka> Then Release is
15:20:34 <jruzicka> a) 1.3.3 (bump selected part only)
15:20:35 <jruzicka> b) 1.3.0 (bump semver, keep all parts like pbr does)
15:20:36 <jruzicka> c) 1.3   (bump semver, drop unneeded zeros)
15:22:00 <hguemar> #chair rbowen
15:22:01 <openstack> Current chairs: Duck adarazs|ruck amoralej chandankumar dmsimard hguemar jpena jruzicka myoung rbowen weshay ykarel
15:22:04 <jruzicka> This gets further complicated with hashes and other non-numbers in Release like 1.2.foo.1 etc.
15:22:10 <PagliaccisCloud> i'm late but here! o/
15:22:12 <rbowen> Hi, folks. Sorry I'm late.
15:22:15 <hguemar> #chair PagliaccisCloud
15:22:16 <openstack> Current chairs: Duck PagliaccisCloud adarazs|ruck amoralej chandankumar dmsimard hguemar jpena jruzicka myoung rbowen weshay ykarel
15:23:47 <hguemar> Has anyone something to add?
15:24:02 <hguemar> I haven't done my homework on that topic so I need more time
15:24:44 <jruzicka> #action everyone with mad .spec Release bumping skillz please review this patch: https://softwarefactory-project.io/r/#/c/10200/
15:24:51 <jruzicka> hguemar, done here
15:25:37 <hguemar> #topic Looking for new project ideas which can done as a part of easyfix in order to foster new contributors
15:25:39 <hguemar> chandankumar: ^
15:26:10 <chandankumar> So here is the things, we started easyfix to get more contributors, packaging issues are almost done
15:26:47 <chandankumar> I am looking for new project ideas which will be useful for RDO /openstack community so that new contributors can start working on
15:27:25 <chandankumar> If you have anything in mind feel free to create an issue here https://github.com/redhat-openstack/easyfix/issues
15:27:35 <Duck> frak, contributors are too efficient :-)
15:27:42 <chandankumar> that's it from my side
15:27:48 <hguemar> #action everyone help finding new ideas for easyfix
15:28:09 <chandankumar> from pycon india 2017, what i find that people look for code contribution too much
15:28:34 <hguemar> Then, we can look for documentation ideas
15:28:40 <chandankumar> since openstack is too vast, they do not want to jump as another reason is hardware constriants they look for small ideas
15:29:04 * hguemar would love seeing a small pamphlet explaining how to deploy real cloud using RDO that we can hand out during events
15:29:20 <rbowen> +100000
15:29:28 <PagliaccisCloud> +
15:29:34 <ykarel> +1
15:29:40 <amoralej> what do yu mean by "real cloud"?
15:29:49 <rbowen> The bookmarks are always popular. Anything more in that direction would be even better.
15:29:53 <chandankumar> if we get project ideas, we might approach for upcoming gsoc or opw in order mentor contributors
15:30:01 <hguemar> amoralej: something that is not single node, packstack is too easy ;-)
15:30:07 <amoralej> :)
15:30:14 <chandankumar> hguemar: you mean something like zines.
15:30:17 <jpena> packstack support multinode
15:30:19 * jpena hides
15:30:22 <rbowen> We have the TripleO bookmark which we had at OpenStack Summit last week.
15:30:22 <PagliaccisCloud> ^
15:30:41 <amoralej> btw, https://review.openstack.org/#/c/517644/ to add multinode to packstack gate
15:30:43 <rbowen> https://www.rdoproject.org/use/bookmarks/01-tripleo-cheatsheet-deploying-tripleo.pdf
15:30:51 <hguemar> jpena: /o\
15:30:52 <chandankumar> hguemar: https://jvns.ca/zines/ ?
15:31:11 <hguemar> chandankumar: something that cool would be terrific
15:31:17 <EmilienM> rbowen: the doc is outdated and doesn't work anymore
15:31:22 <EmilienM> I see it deploys EPEL
15:31:52 <chandankumar> that's it from my side.
15:31:58 <PagliaccisCloud> i actually talked to my boss yesterday about getting into writing books. I'd love to write a "fancy openstack 4 beginners" book
15:32:20 <chandankumar> what about RDO cookbook ?
15:32:25 <dmsimard> rbowen: btw https://github.com/redhat-openstack/website/pull/1105
15:32:39 <PagliaccisCloud> maybe with little breakdowns on lesser-known services that can be enabled with the answers file?
15:33:07 <rbowen> That sounds very useful.
15:33:16 <chandankumar> hguemar: better i can start a thread for project idea
15:33:18 <hguemar> That's all excellent ideas, don't forget to submit them to  https://github.com/redhat-openstack/easyfix/issues
15:33:27 <hguemar> chandankumar: ack
15:34:37 <chandankumar> hguemar: next topic?
15:34:48 <hguemar> Yes
15:34:56 <hguemar> #topic DLRN on TripleO CI usage of GitHub reposa
15:35:00 <hguemar> #undo
15:35:01 <openstack> Removing item from minutes: #topic DLRN on TripleO CI usage of GitHub reposa
15:35:04 <hguemar> #topic DLRN on TripleO CI usage of GitHub repos
15:35:20 <hguemar> long-standing issue
15:35:34 <jpena> if you look at https://bugs.launchpad.net/tripleo/+bug/1730931, we are discussing the situation
15:35:34 <openstack> Launchpad bug 1730931 in tripleo "Github.com is used in TripleO CI for cloning distgit repos" [Critical,Triaged]
15:36:09 <jpena> TL;DR: DLRN uses stuff from GitHub (or review.rdo) to build packages, and that can cause trouble when we run CI jobs inside the OpenStack infra
15:36:12 <hguemar> The change looks good, but can we ensure that our mirrors are more reliable than github's ?
15:36:37 <hguemar> I suspect that 3o CI is just hitting throttling limiters from github
15:37:00 <jpena> I'm not sure. In some cases we see DNS resolution errors (sounds familiar?)
15:37:10 <hguemar> Interesting
15:37:24 <dmsimard> We also don't have a dedicated git cluster like upstream has
15:37:42 <dmsimard> I'd be wary of the load involved in making all upstream jobs clone directly off of review.rdo
15:37:43 <jpena> so afaik the policy for OpenStack CI is to not use external resources, which is an issue no matter if we use github or review.rdo
15:37:46 <hguemar> My fear is that we don't have manpower and hardware to provide HA repo hosting
15:37:52 <dmsimard> jpena: yes, +1
15:37:54 <amoralej> imho review.r.o is less reliable that github
15:38:00 <dmsimard> amoralej: +1
15:38:05 <hguemar> *nods*
15:38:15 <dmsimard> jpena: that particular bit was discussed briefly at the previous PTG
15:38:18 <amoralej> unles we implement some synchronization to openstack-infra
15:38:25 <jpena> then, what can we do? Is there a way to mirror our distgit and rdoinfo repos inside openstack-infra?
15:38:31 <dmsimard> It was actually supposed to be brought up to the technical committee
15:38:54 <hguemar> So has been it discussed?
15:38:55 <dmsimard> jpena: the problem is not that tripleo pulls from outside openstack
15:38:57 <hguemar> EmilienM: ^
15:39:04 <dmsimard> it's that it *compiles* sources from outside openstack
15:39:19 <dmsimard> RDO is outside openstack and can be used fine
15:39:37 <EmilienM> tbh I was out the last 8 days
15:39:37 <hguemar> dmsimard: what are they compiling?
15:39:41 <jpena> mmm
15:39:42 <dmsimard> but it's a grey area because this is only for CI purposes
15:39:43 <EmilienM> I might miss context
15:39:44 <jpena> I don't get that
15:39:55 <hguemar> EmilienM: no worries :)
15:40:23 <dmsimard> jpena: OpenStack projects under governance are supposed to be self-contained and independant, TripleO pulls spec files and builds packages that are not under OpenStack governance
15:40:46 <dmsimard> It doesn't end up being in the actual TripleO "product" (or deliverable) so it's very grey
15:40:54 <dmsimard> because tripleo only does that for testing purposes
15:41:02 <jpena> dmsimard: that sounds like an excuse to me
15:41:04 <jpena> i mean
15:41:21 <EmilienM> OpenStack projects under governance AREN'T independant at all
15:41:26 <EmilienM> they rely on python libraries, etc
15:41:33 <jpena> dmsimard: if you do pip install cryptography, it's going to *compile* stuff locally
15:41:37 <dmsimard> EmilienM: pulling from pypi or repositories is fine
15:41:42 <hguemar> dmsimard: ha, building packages. Well, tripleo being an installer relying on third-party packages, it is normal, that they do that
15:41:42 <jpena> and that stuff is external from openstack
15:41:48 <hguemar> *nods*
15:41:51 <dmsimard> jpena: but you're not cloning python-crypto and then building the actual python module
15:42:15 <jpena> dmsimard: we're not doing that either in tripleo. The actual sources come from Zuul
15:42:39 <dmsimard> jpena: I'm not sure I follow.. from zuul ?
15:42:46 <jpena> yes, let me explain
15:42:51 <hguemar> dmsimard: how could they test if they can deploy latest code using packages if they don't do that?
15:43:07 <jpena> if we send a patch to tripleo-heat-templates, it will be built by DLRN as part of the TripleO job
15:43:10 <amoralej> dmsimard, i'm a bit lost, when we run p-o-i or tripleo we install RPMs from RDO
15:43:12 <amoralej> is that ok?
15:43:20 <dmsimard> amoralej: yes
15:43:35 <hguemar> it's the build part of the jobs that seems to be a problem
15:43:39 <amoralej> then what's the problem with building a package in the job?
15:43:44 <jpena> but we are not pulling the tripleo-heat-templates source from github, we're copying that from the Zuul-generated output
15:43:58 <jpena> which is why we build a package to begin with: because we want to test that code in its context
15:43:59 <dmsimard> jpena: but it's pulling the spec file
15:44:09 <dmsimard> jpena: which doesn't live in openstack
15:44:14 <jpena> then we're back to python-cryptography
15:44:35 <dmsimard> meh, I don't know.
15:44:45 <hguemar> dmsimard: except for a licensing question, there are no real issues
15:44:51 <dmsimard> Anyway, I'm the messenger here, and just trying my best to represent what was discussed in Denver
15:45:18 <dmsimard> We should bring this up to mordred/clarkb/fungi/pabelanger who are more knowledgeable about the implications than I am
15:45:25 <hguemar> dmsimard: well, I'd like to understand myself
15:45:41 <jpena> seriously, I don't understand the concerns. Multiple projects use .deb/.rpm packages, which are external and accepted
15:46:12 <hguemar> I see an issue if our spec file were licensed under a non-openstack compatible licenses (which should not be the case)
15:46:21 <dmsimard> ok, let me take the action to clarify this with the committee
15:46:23 <jpena> and a deployment project that tests packages needs a way to build them if it needs to use the new code
15:46:40 <hguemar> e.g: spec file license that forbids explicitly redistribution of resulting rpms
15:46:53 <dmsimard> #action dmsimard to talk to Technical Committee about external sources in TripleO (follow-up from Denver discussion)
15:47:02 <EmilienM> :-O
15:47:17 <hguemar> If it's licensing, I'd be happy (not litterally) to sync with legal to provide clearance
15:47:21 <dmsimard> EmilienM: you were at that discussion I think
15:47:26 <dmsimard> EmilienM: or maybe not, I don't remember
15:47:28 <EmilienM> yeah now I remember it
15:47:47 <dmsimard> EmilienM: it came up when we discussed reliability of github (or lack thereof)
15:47:58 <dmsimard> and it forked up to tripleo (and puppet-openstack) using sources from github
15:48:25 <dmsimard> There was no conclusion as I recall, it just statu-quo'd
15:48:29 <EmilienM> the lack of reliability and also the speed
15:48:29 <amoralej> so, is the problem relying on github or using non-openstack code?
15:48:42 <hguemar> yeah, two different matters
15:48:53 <dmsimard> amoralej: the fact that it's on github, gitlab or wherever else is not relevant
15:49:06 <hguemar> But I guess that we're running out of time
15:49:09 <dmsimard> amoralej: the topic of "openstack projects using external sources" came about when we were discussing reliability of github
15:49:38 <hguemar> I think the github/hosting discussion is important, but review.rdoproject.org may not be a reliable alternative to github
15:49:44 <dmsimard> discussions at the PTG tend to fork and explode very often :)
15:50:01 <jpena> dmsimard has an action, so let's take the discussion offline and move on with the agenda
15:50:07 <amoralej> ok
15:50:08 <dmsimard> +1
15:50:21 <hguemar> #topic Upstream LTS releases discussion
15:50:26 <EmilienM> o/
15:50:30 <hguemar> EmilienM: if you can explain us what was discussed :)
15:50:32 <PagliaccisCloud> oooo
15:50:32 <EmilienM> #link https://etherpad.openstack.org/p/LTS-proposal
15:50:42 <EmilienM> well, it was interesting and intense
15:50:59 <EmilienM> the discussion is now happening on the ML & this etherpad ^
15:51:32 <EmilienM> one of the problems we tried to solve was:
15:51:39 <EmilienM> "how can we keep stable branches longer"
15:51:46 <PagliaccisCloud> so... is it kind of like the rhosp model, but open source?
15:52:20 <EmilienM> it's a collaboration of efforts between folks willing to take ownership of stable branches
15:52:21 <hguemar> More or less (it's a bit different)
15:52:26 <EmilienM> that can be operators, distros, etc
15:52:53 <hguemar> Well, if we can agree to keep some branches living longer and with *tested* upgrades, that'd be awesome
15:52:56 <EmilienM> details are being figured out now
15:53:21 <PagliaccisCloud> interesting. not a bad idea at all
15:53:23 <hguemar> EmilienM: is there a specific tag to follow on devel list?
15:53:24 <EmilienM> where RDO could be helpful is to maintain builds for stable releases
15:53:37 <EmilienM> hguemar: the LTS thread, did you see it?
15:53:50 <EmilienM> #link http://lists.openstack.org/pipermail/openstack-dev/2017-November/124308.html
15:53:54 <EmilienM> and https://etherpad.openstack.org/p/LTS-proposal
15:54:20 <hguemar> EmilienM: yes, but i feared missing a discussion
15:54:46 <hguemar> AFAIK, if we stick to our own rules, as long as a release is not EOL, we keep building it
15:55:24 <dmsimard> We need to plan accordingly
15:55:46 <dmsimard> What's worrying me the most is the strain that supporting one or more additional releases will take on people and systems
15:56:17 <EmilienM> probably
15:56:30 <dmsimard> If upstream decides to support LTS releases that's great and I hope companies sponsoring this work will provide the necessary resources to keep the things maintained and tested
15:56:32 <EmilienM> that's why one of the biggest asks during the discussion was "you want it, help us"
15:56:53 <dmsimard> But this also means that RDO has to keep an extra release, maintaining packages, mirrors, CI, etc.
15:56:55 <hguemar> Yes, but I suspect that some of the work that the internal OSP team is doing can be done in RDO so we'd be able to mutualize some manpower and maybe hw resources
15:57:19 <EmilienM> probably
15:57:23 <dmsimard> hguemar: that's a fair *assumption* which I would very much like to formalize if Red Hat wants to move forward with this
15:57:23 <amoralej> companies which require it probably are already doing it closely so doing it upstream will be more efficient
15:57:47 <hguemar> dmsimard: yes, we should consider this granted, but I'd try to see if we can do something along that line
15:58:18 <dmsimard> We're already struggling to keep up with the load in RDO cloud is just one of many examples
15:58:35 <dmsimard> I'm not against the idea at all, I'm just saying we'll need help if we're going to do this
15:58:35 <amoralej> dmsimard, about systems, i'm pretty sure we'll have to do it, so let's think what we need
15:59:24 <hguemar> dmsimard: well, we need to write a Xmas list and ask apevec to give it to Santa :o)
15:59:36 <hguemar> Well, the Santas
15:59:59 <amoralej> :)
16:00:17 <jpena> we can try to make up some numbers once we know what the upstream idea is
16:00:39 <jpena> e.g. if we need to support 2 more releases, it means X more jobs per day, etc
16:00:51 <hguemar> As for build systems, stable repos, CentOS has already prepared to support bigger load so I'm fine with that side (much is automated now, and it will be even simpler in the future)
16:00:54 <dmsimard> EmilienM: when will we know if upstream is moving forward with this ? Newton is already EOL'd, is it going to be un-EOL'd or would this be for a next eventual release ?
16:01:07 <EmilienM> I'm not sure
16:01:22 <EmilienM> it's hard to tell when things happen in open-source
16:01:30 <EmilienM> it's being discussed
16:01:45 <dmsimard> ok, can you be our liaison for this? :)
16:01:55 <rbowen> I would expect that it would be going forward.
16:02:03 <rbowen> un-EOLing something seems complicated.
16:02:05 <EmilienM> I can help for sure
16:02:13 <EmilienM> but not sure I'll spend much time on that
16:02:21 <dmsimard> rbowen: yeah it's not really a question of "if", more than a "when" and "how"
16:02:29 <dmsimard> EmilienM: who else is driving it ?
16:02:45 <EmilienM> dmsimard: dhellmann is also involved
16:02:51 <hguemar> rbowen: not possible in classical mechanics, but maybe in quantic mechanics :)
16:02:57 <EmilienM> dmsimard: imho, it should be driven by people who actually maintain stable releases :D
16:03:08 <dmsimard> fair
16:03:12 <EmilienM> if they aren't involved, this project won't work
16:03:12 <hguemar> Well, we're passed the hour mark
16:03:15 * chandankumar reminds, we already running out of time.
16:03:16 <hguemar> please wrap up
16:03:24 <EmilienM> I think it's the last chance for LTS topic to survive
16:03:34 <EmilienM> the community has been talking about it for years
16:03:38 <EmilienM> and this time was imho the last shot
16:03:48 <EmilienM> if nothing is kicked off, we'll move on
16:03:53 <PagliaccisCloud> :/
16:04:07 <hguemar> Let's revisit this point next week
16:04:08 <EmilienM> but it seems like discussions are making good progress on that etherpad
16:04:39 <hguemar> (anyone up for chairing next week btw?)
16:04:56 <jpena> I can chair next week
16:04:57 * chandankumar will be on PTo for 2 weeks
16:05:07 <hguemar> #info jpena chairing next week
16:05:26 <hguemar> Ok, let's close meeting, I'll add this point to the next meeting since we need to follow this topic
16:05:31 <hguemar> Thank you for attending!
16:05:34 <hguemar> #endmeeting