13:00:45 <mmaslano_> #startmeeting Env and Stacks (2014-03-04)
13:00:45 <zodbot> Meeting started Tue Mar  4 13:00:45 2014 UTC.  The chair is mmaslano_. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:51 <mmaslano_> #meetingname env-and-stacks
13:00:51 <zodbot> The meeting name has been set to 'env-and-stacks'
13:00:55 <mmaslano_> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
13:00:56 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano mmaslano_ pkovar samkottler tjanez
13:01:01 <mmaslano_> #topic init process
13:01:09 <hhorak> Hi guys!
13:01:11 <juhp> hi
13:01:16 <bkabrda1> hey
13:02:00 <tjanez> hi
13:02:13 * sgallagh lurks. Mention my nick if you need me.
13:02:35 <mmaslano> #topic additional repository
13:02:39 <pkovar> hi
13:02:57 <mmaslano> #undo
13:02:58 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x102ecc90>
13:03:05 <mmaslano> #topic additional repository - Playground requirements
13:05:51 <mmaslano> let's start with abadger1999 draft https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29
13:06:59 <tjanez> Maybe we start with easy things that were agreed upon on the ML
13:07:04 <tjanez> Like Open question 3)
13:07:16 <mmaslano> #info  how do updates work (rolling? bodhi? Will we constantly be regenerating the repodata [like the rawhide build repo?])
13:07:43 <mmaslano> we said rolling, and repository per Fedora release, right?
13:07:57 <tjanez> mmaslano, yes
13:08:00 <bkabrda1> my idea of this is rolling + constantly regenerating repodata
13:08:14 <bkabrda1> and yes, one repo per Fedora release
13:08:20 <tjanez> to be more precise, one repo per Fedora release + arch
13:08:30 <bkabrda1> tjanez: right
13:09:12 <mmaslano> bkabrda1: so, no stable repo, fine
13:10:26 <mmaslano> #info rolling + constantly regenerating repodata
13:10:29 <juhp> sounds good
13:10:35 <juhp> daily push?
13:10:54 <mmaslano> did we say not to mirror data?
13:11:04 <mmaslano> it might be a problem if we want to mirror everything every day
13:11:14 <tjanez> #info one repo per Fedora release + arch
13:12:11 <mmaslano> juhp: let's say daily push and we'll figure out later if it's a problem or not
13:12:16 <juhp> okay
13:12:23 <juhp> sure
13:12:25 <mmaslano> #info daily push
13:12:29 <mmaslano> what about bodhi?
13:12:39 <mmaslano> I guess we don't need it either for Playground repo
13:13:04 <hhorak> mmaslano: I hope mirroring use some "delta algorithm", so it shouldn't be so big problem to mirror in the future, but not necessary now I guess
13:13:17 <juhp> right but maybe we need some sanitizing check when composing the updated repo
13:13:25 <tjanez> I would say we don't need bodhi initially
13:13:41 <mmaslano> juhp: definitely
13:13:52 <juhp> (right > no bodhi:)
13:13:59 <juhp> yes
13:14:02 <mmaslano> #info no bodhi yet
13:14:17 <hhorak> mmaslano: Mabye just an apparatus to remove a build from repo? I know it will not remove from installed though, so maybe a bad approach.. but what do we do if one package breaks something too ugly?
13:14:45 <juhp> hhorak, true abandoned copr could be a problem
13:15:12 <tjanez> hhorak, we remove it from the repo and announce which manual steps the affected users should make to recover
13:15:20 <mmaslano> probably
13:15:38 <sgallagh> I'd suggest that we also shouldn't make it copr-owner capable to add to the playground.
13:15:50 <sgallagh> I think that should be a pull operation from a whitelist of approved COPRs
13:15:51 <tjanez> basically, the same thing as we do now (when occasionally something breaks badly)
13:16:09 <sgallagh> Otherwise, I guarantee it will just become a dumping ground for bypassing Fedora rules.
13:16:11 <juhp> copr karma?
13:16:30 <mmaslano> sgallagh: yes, I agree
13:17:08 <tjanez> sgallagh, it could be initiated by the copr-owner, but would then be checked to satisfy our (small) policy
13:17:11 <mmaslano> juhp: might work, but it might work as bodhi testing ;-)
13:17:11 <juhp> actually I was kind of curious - what candidate coprs do we have in mind for the initial repo - any examples?
13:17:18 <juhp> mmaslano, true
13:17:52 <sgallagh> juhp: Chromium seems like an obvious choice
13:18:24 <mmaslano> server roles, SCLs
13:18:25 <juhp> tjanez, aha - request to add to Playground
13:18:27 <juhp> sgallagh, ok
13:18:36 <juhp> aha okay
13:18:40 <tjanez> juhp: and we have Python scientific software that likes to bundle libraries
13:18:45 <juhp> sounds good
13:18:53 <sgallagh> I'd say that part of the policy for approval would be maintainer trust.
13:18:55 <hhorak> I'd rather see an optimistic workflow -- just add packages there and remove them only if they're bad
13:18:56 <juhp> I also play to start some scl haskell repos...
13:18:57 <mmaslano> and perl-Padre with bundled library
13:19:08 <sgallagh> i.e. Do we trust this person to keep the repo up to date and address serious bugs/security issues.
13:19:22 <juhp> okay thanks - I think I am convinced with examples already :)
13:19:33 <sgallagh> hhorak: That doesn't work, because RPM can't remove packages that someone already installed
13:19:49 <juhp> sgallagh, this is just a Playground but hmm yeah
13:19:54 <sgallagh> hhorak: So we have no way to fix things if a package needs to die
13:19:58 <tjanez> sgallagh, "Do we trust this person to keep the repo up to date and address serious bugs/security issues." -> a good question
13:20:12 <tjanez> I would say, by default, not
13:20:19 <juhp> right
13:20:37 <tjanez> If it is a security-critical piece of your infrastructure, try to bring it into Fedora's main repo
13:20:40 <sgallagh> hhorak: The best we can do is blast out an email announcement asking people to uninstall it if they are using it.
13:20:45 <hhorak> sgallagh: it's doable with some previous build re-built with higher release/epoch
13:20:50 <mmaslano> #info Do we trust this person to keep the repo up to date and address serious bugs/security issues.
13:20:56 <sgallagh> (Or do a really NASTY hack where we bump epoch and push an empty package...
13:21:12 <juhp> I would say if you are security then you should not be using this repo :)
13:21:15 <sgallagh> hhorak: That works if it's a regression
13:21:20 <juhp> security conscious, sorry
13:21:34 <sgallagh> Not so much if the package has been abandoned or has veered off into being malware
13:21:59 <tjanez> juhp, or keep up with security issues yourself
13:22:04 <juhp> nod
13:22:16 <sgallagh> tjanez: That's well understood to be impossible for the end-user
13:22:28 <tjanez> sgallagh :)
13:22:52 <sgallagh> I only maintain a couple dozen packages, and keeping those up to date for security issues is hard.
13:22:56 <hhorak> sgallagh: right, then I'd be also fine with removing using the hack you described, if it is real dangerous thing, but usually I'd just let the packages intalled
13:23:01 <tjanez> sgallagh, regarding malware, we could use a system where we "flag" packages as malware (similarly as we do with licensing in COPR)
13:23:15 <mmaslano> tjanez: fine by me
13:23:16 <sgallagh> tjanez: Still doesn't help us remove things
13:23:26 <juhp> sgallagh, this is not a stable repo though more of an experimental one but I hear you
13:23:39 <sgallagh> juhp: I disagree with that statement
13:23:45 <sgallagh> COPRs fits that description better
13:23:55 <sgallagh> This repo should be *more* stable than COPR, or it's worthless
13:24:06 <juhp> sgallagh, we are planning more stable repo than Playground
13:24:10 <tjanez> sgallagh, hmm, you see the problem of package removal an issue here but not in the main repos?
13:24:25 <sgallagh> tjanez: No, that problem also exists in the main repos
13:24:36 <sgallagh> However we have two things in our favor there:
13:24:49 <sgallagh> 1) Larger maintainer pool for addressing orphans
13:24:56 <hhorak> tjanez: sgallagh: right, if we don't care in main repos, we probably don't have to care in playground either
13:25:00 <pingou> tjanez: the assumption is the packager in the main repos know more the rules and are more careful (and more checked that they are not in fact $dangerous_cracker)
13:25:02 <sgallagh> 2) Short lifecycle means that abandoned packages disappear in about a year.
13:25:22 <sgallagh> hhorak: I didn't say we didn't care
13:25:29 <sgallagh> I said the problem is mitigated there.
13:25:44 <hhorak> sgallagh: correct
13:25:46 <tjanez> sgallagh, pingou, I see your point
13:25:57 <tjanez> The issue will be more "exposed" here
13:26:01 <sgallagh> ack
13:26:25 <tjanez> So, does anyone have an idea for a solution?
13:26:57 <hhorak> tjanez: I think it's quite easy and quick to set up an empty package that would obsolete some very bad one, so we can just document the process and wait until something like that happens?
13:27:16 <sgallagh> tjanez: Well, my suggestion was that by vetting the list of things that can go in, we minimize that risk
13:27:20 <mmaslano> hhorak: I concur
13:27:43 <sgallagh> i.e. Popular projects from someone who's already a Fedora maintainer for other stuff? Probably going straight in.
13:28:04 <sgallagh> python-arbitrarymodule from a drive-by contributor... maybe needs more attention.
13:28:20 <tjanez> hhorak, if someone wants to put something bad into the repo, what prevents him from packaging the same/similar thing under a different name over and over?
13:28:45 <pingou> tjanez: we'll likely want/need to flag the user
13:28:53 <sgallagh> Hmm, I suppose we could always have the fedora-playground-release package "Obsoletes: badapp-$version"
13:28:54 <pingou> and look at things like IP address as well
13:29:09 <mmaslano> #info we could always have the fedora-playground-release package "Obsoletes: badapp-$version"
13:29:13 <sgallagh> tjanez: the fact that no one will know what it's called to install it?
13:29:15 <sochotni> we need to differentiate playground from "ordinary" copr repo. That differentiation is higher quality. I'd require people to have at least fedora cla
13:29:16 <mmaslano> it seems to me as easiest solution
13:29:28 <tjanez> sgallagh, your proposal conflicts with the automated and quick review that we are after :(
13:29:50 <hhorak> if we find ourselves to add obsoletes into fedora-playground-release package every second day, we can change the rules, but I believe it won't happen
13:30:00 <sgallagh> tjanez: I realize that. I'm hoping we can find a middle ground if we discuss the extremes together :)
13:30:24 <sochotni> rwmjones: I heard you were working on copr support in packagekit (or something in that sense)?
13:31:08 <rwmjones> sochotni: I don't think that's me
13:31:09 <sochotni> rwmjones: my bad most likely, nvm
13:31:18 <mmaslano> probably hughsie
13:31:37 <pingou> I thought he said PK was in maintainance only?
13:31:37 <tjanez> Ok, I think flagging of users (and their IPs) is likely to be enough
13:31:53 <mmaslano> pingou: really? hm
13:31:55 <sgallagh> pingou: no
13:31:59 <pingou> ok
13:32:00 <pkovar> was it gnome-software then?
13:32:02 <sgallagh> PK-gnome is in maintenance mode
13:32:06 <sgallagh> not PackageKit itself.
13:32:09 <mmaslano> sochotni: https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#Open_Questions
13:32:22 <sgallagh> Just the old GNOME user interface to it
13:32:25 <mmaslano> ok
13:32:27 <pingou> tjanez: except when we have multiple person behind 1 IP
13:32:50 <mmaslano> we were discussing few times how to create repo with lot of same libraries with different versions...
13:32:59 <mmaslano> sochotni: will be so kind and put it on wiki :)
13:33:13 <mmaslano> I guess that's the most problematic part of Playground
13:33:15 <hhorak> pingou: right, I'd stay with blacklisting FAS accounts for now
13:33:17 <sgallagh> mmaslano: mirror ruygems.org? /me runs
13:33:31 <mmaslano> sgallagh: you might if you want
13:33:37 <sgallagh> It was a joke.
13:33:45 <mmaslano> sgallagh: we thinking about more versions of v8 and such stuff
13:34:02 <sgallagh> Well, v8 *really* is meant to be bundled.
13:34:10 <mmaslano> sgallagh: and that's the problem :)
13:34:13 <bkabrda1> sgallagh: more versions of Django? ;)
13:34:23 <sgallagh> Right, but the playground is a place where bundling is acceptable.
13:34:29 <sgallagh> Or am I mistaken?
13:34:30 <hhorak> sgallagh: try tell that to the SRT guys
13:34:32 <sgallagh> bkabrda1: We solved that!
13:34:53 <sgallagh> hhorak: There's no support expectation for Playground. They won't care as long as that's clear to anyone enabling it.
13:34:56 <sgallagh> (I suspect)
13:35:06 <mmaslano> sgallagh: let's assume different library
13:35:15 <tjanez> Regarding automatic/manual entry into the repo: Maybe we could skip manual approval/check if the packager has some packages already in Fedora and only require it if the person is completely new to Fedora?
13:35:24 <bkabrda1> sgallagh: yeah, but that way can't be generally applied to any package
13:35:27 <mmaslano> tjanez: yes, we might
13:35:27 <sgallagh> mmaslano: Well, "library" is too overloaded.
13:35:34 <sgallagh> bkabrda1: Works for most python, though
13:35:56 <hhorak> sgallagh: right, bungling is fine for playground, I had other use cases in my mind.. never mind..
13:36:03 <sgallagh> mmaslano: Are we talking C libraries with proper version-info? Rubygems that break compat every point release?
13:36:07 <mmaslano> sgallagh: call it whatever you like. I'm speaking about two same packages in different versions. That can happen.
13:36:09 <bkabrda1> sgallagh: true, but I guess we need to think about stuff like v8/yourClibraryofchoice
13:36:16 <sgallagh> hhorak: I appreciate the 'bungling' typo ;-)
13:36:49 <hhorak> sgallagh: :)
13:36:50 <sgallagh> mmaslano: Well, I'm saying that it differs wildly between languages.
13:36:57 <mmaslano> sgallagh: C or gem, it doesn't matter
13:37:11 <mmaslano> in this case you will have a conflict
13:37:28 <sgallagh> mmaslano: Don't gems just drop into different paths so they can coexist?
13:37:33 * sgallagh thought he remembered that.
13:37:43 <bkabrda1> sgallagh: they do
13:37:57 <mmaslano> sgallagh: but yum will install the latest version
13:38:00 <juhp> I presume the problem is at the rpm level?
13:38:12 <mmaslano> nevermind :) I'll leave the problem to Stano on wiki :)
13:38:19 <sgallagh> mmaslano: that can be sort-of resolved by including the version in the name
13:38:35 <sgallagh> But that's admittedly a hack
13:38:41 <mmaslano> sgallagh: that can be solved by adding SCL
13:38:49 <sgallagh> Another option would be for rubygems to simply always install their entire history :)
13:38:50 <sochotni> mmaslano: https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#1_Big_repo_vs_multiple_small_ones
13:39:02 <mmaslano> I thought we are trying to make packaging faster and easier, not more complicated and bound by rules
13:39:06 <bkabrda1> sgallagh: what do you mean install their entire history?
13:39:18 <sgallagh> rubygem-foo installs /path/to/foo_1.0 and /path/to/foo_1.1 and ...
13:39:27 <sgallagh> So every new version contains all the old ones too
13:39:28 <hhorak> mmaslano: +1
13:39:30 <mmaslano> I would stop the discussion here
13:39:32 <sgallagh> It's hideous, but would work
13:39:35 <sochotni> sgallagh: this has to be universal and not everything is done as nice as ruby :-)
13:39:39 <mmaslano> let's go back to Open Questions
13:39:46 <sgallagh> sochotni: Well, that's the point I was making
13:39:53 <sgallagh> Trying to solve this universally is futile
13:40:02 <sgallagh> It's okay to target policies at different technologie
13:40:08 <sochotni> sgallagh: not really, we can't avoid conflicts completely...
13:40:33 <sochotni> but if we split if off per feature (chromium, django 1.6) we minimize likely problems for users even with current tech
13:40:59 <sochotni> i.e. without involving complications as SCLs and changing of rpm/yum/dnf/rel-eng/infrastructure
13:41:08 <sgallagh> sochotni: I *think* you're agreeing with me?
13:41:14 <sochotni> sgallagh: possibly :-)
13:41:28 <sgallagh> Anyway, mmaslano asked us to stop talking about this for now.
13:41:32 <sochotni> anyway...marcela wanted to move to open questions
13:41:34 <sochotni> yeah
13:41:45 <mmaslano> sgallagh: I'm trying to solve at least some questions
13:41:59 <mmaslano> conflicts are not so easy to solve during irc meeting
13:42:12 <mmaslano> #info  is there a testing repo?
13:42:17 <mmaslano> I'd say no
13:42:29 <pingou> the testing repo are the individual copr
13:42:32 <pingou> no?
13:42:32 <juhp> yeah probably not for now
13:42:51 <mmaslano> yeah
13:42:55 <tjanez> I would also think not necessary initially
13:43:01 <sgallagh> If that's the case, then we probably have to be able to tag individual builds to go to playground
13:43:03 <sgallagh> Not entire coprs
13:43:07 <mmaslano> #info testing repo - not needed, testing are coprs
13:43:16 <hhorak> +1 for coprs being the testing space
13:43:19 <sgallagh> (Or the maintainer would have to maintain two coprs, one for playground and one for testing)
13:43:24 <pingou> sgallagh: good point
13:43:46 <mmaslano> #info does it need adding to mirrormanager?
13:43:52 <mmaslano> I guess we also agreed on NO
13:43:56 <hhorak> sgallagh: two-coprs-approach seem good for me
13:44:07 <juhp> mmaslano, +1
13:44:21 <sgallagh> hhorak: It's a reasonable workaround for the immediate future, at least
13:44:51 <mmaslano> what? we didn't understand each other earlier
13:45:12 <hhorak> sgallagh: I wouldn't necessarily call it a work-around, just a way how it is done in Copr.
13:45:12 <tjanez> mmaslano, I would agree
13:45:52 <mmaslano> my bad, let's go back to testing repo
13:45:59 <mmaslano> #undo
13:45:59 <zodbot> Removing item from minutes: INFO by mmaslano at 13:43:46 : does it need adding to mirrormanager?
13:46:03 <sgallagh> hhorak: I just mean it's a workaround for a nice user experience
13:46:27 <sgallagh> Ideally in the future, we'd extend COPR so you'd only need to maintain one.
13:46:44 <sgallagh> I didn't mean to suggest that this was a bad plan.
13:47:34 <tjanez> We might want to tell people explicitly that Playground means a "playgroud" in the packaging sense, not the actual software being very unstable?
13:47:55 <bkabrda1> tjanez: well I think it can mean both
13:48:18 <tjanez> bkabrda1, yes, so it needs a clarification :)
13:48:37 <tjanez> Or what do others think of stable/unstable software in Playground?
13:48:50 <sgallagh> tjanez: from earlier discussions about allowing anything in, I think we're clearly talking about the latter.
13:49:09 <sgallagh> If we want to have it limited to something stable, then we're back to approving things individually.
13:49:21 <juhp> right
13:50:01 <juhp> I guess some pieces will be more unstable than others :)
13:50:01 <tjanez> sgallagh, ok, we probably won't enforce it, but what about setting some goals, a moto even?
13:50:25 <juhp> sure - some guidance might help
13:50:49 <sgallagh> tjanez: At this point, aren't we just setting ourselves up for effectively just getting every COPR dumped in here?
13:51:19 <juhp> sgallagh, conflicts with fedora packages are not allowed anyway
13:51:40 <tjanez> sgallagh, I hope we can *promote* the idea that very bleeding edge/alpha software should be rather put into a COPR with a warning description next to it?
13:51:41 <juhp> I believe
13:51:48 <sgallagh> juhp: They had better be
13:52:01 <sgallagh> But if we can't enforce that, someone *will* do it anyway.
13:52:06 <juhp> whereas many copr do
13:52:06 <sgallagh> Probably by accident
13:52:17 <juhp> sgallagh, we have to
13:52:24 <sgallagh> Have to what?
13:52:29 <juhp> to enforce it
13:52:44 <sgallagh> Allow me to rephrase
13:53:12 <sgallagh> Reactive enforcement won't be sufficient, because we'll get into a situation where we may need to force the main repo to bump epoch to fix problems caused by the playground.
13:53:30 <sgallagh> So we have to know beforehand whether it would be replacing something in the main repo
13:54:03 <tjanez> sgallagh, I'm for educating our future contributors and believing they will try to behave well.
13:54:16 <juhp> sgallagh, I am only referring to name conflicts
13:54:24 <tjanez> But yea, probably, bad things will happen by accident
13:54:43 <sgallagh> juhp: Sure, name conflicts are easy.
13:54:48 <sgallagh> But Obsoletes:?
13:55:08 <sgallagh> For example, suppose the python-imaging -> python-pillow change happened in the playground first.
13:55:30 <juhp> shrug too hard I guess - I think Playground get to keep all the pieces...
13:55:37 <juhp> Playground uers
13:55:38 <juhp> s
13:56:20 <sgallagh> It just seems to me like at least a minimal review should be required for a COPR to enter the playground
13:56:29 <sgallagh> Most of the likely issues could be caught at that point.
13:56:34 <juhp> well I agree that would be ideal
13:56:48 <sgallagh> (Things probably won't add an Obsoletes: after the initial release)
13:57:08 <mmaslano> sgallagh: minimal automatic review
13:57:09 <sgallagh> It shouldn't be as comprehensive as a Fedora review
13:57:17 <sgallagh> mmaslano: We can automate parts of it, sure.
13:57:27 <juhp> I suppose Obsoletes should be checked too
13:57:30 <sgallagh> Probably even reuse the fedora-review tool logic in some places.
13:58:05 <sgallagh> Or even just check 1) does the name conflict? 2) does it contain a Conflicts: or Obsoletes: directive in the spec?
13:58:20 <sgallagh> If either thing occurs, require manual verification.
13:58:20 <mmaslano> I guess refusal of Obsoletes is premature at this point
13:58:25 <sgallagh> mmaslano: Why?
13:58:38 <sgallagh> I don't want to refuse it outright; only if it Obsoletes the main repo
13:58:41 <hhorak> I'd rather like to see the review be fully automaticm than only some places
13:58:46 <sgallagh> If it obsoletes an older playground package, that's fine
13:59:00 <sgallagh> hhorak: I mean it should be fully automatic for success cases
13:59:09 <sgallagh> And only if we hit a known trouble spot, ask for a human review
13:59:15 <mmaslano> sgallagh: because we don't have a full list of examples
13:59:17 <hhorak> sgallagh: sounds fine
13:59:23 <mmaslano> follow if you want, I need to go another meeting
14:00:12 * sgallagh probably should get back to his regularly-scheduled firefighting.
14:00:20 <tjanez> sgallagh, +1 on manual review only in "problem" cases
14:01:12 <sgallagh> Could someone who is a chair #info that suggestion, please?
14:01:38 <sgallagh> Proposal: attempt to do automatic package review, falling back to human intervention on known trouble cases such as Obsoletes.
14:02:13 <tjanez> #info The repo will attempt to do automatic package review, falling back to human intervention on known trouble cases such as Obsoletes.
14:03:12 <tjanez> Also, we reached the conclusion that testing repo is not needed initially?
14:03:38 <mmaslano> tjanez: seems to me
14:03:58 <tjanez> mmaslano, ok, I saw you already put it into #info
14:05:36 <tjanez> Is there enough energy/interest to continue the meeting?
14:06:06 * mmaslano is on call
14:06:09 * sgallagh has to run
14:06:43 <hhorak> tjanez: I have a couple of minutes, but if we'd be only two, it doesn't make sense
14:06:46 <mmaslano> tjanez: I'll come with better agenda and discussion about beating dead horse can happen on Open Floor
14:06:56 <mmaslano> I mean next week
14:07:56 <tjanez> mmaslano, I though the meeting was quite constructive, but maybe we derailed it at some topics a bit
14:08:24 <mmaslano> tjanez: do you want to add info to Open Questions? ;-)
14:08:24 <juhp> (I think we also need to prevent copr that conflict with Playground)
14:08:36 <mmaslano> I don't think we have new information to them
14:09:05 <tjanez> mmaslano, no problem, I will be happy to do it :)
14:09:14 <mmaslano> tjanez: sounds great!
14:09:24 <tjanez> mmaslano, just put an action item so I don't forget
14:09:55 <mmaslano> #action tjanez will add comments from our today's meeting to Open Questions
14:11:33 <mmaslano> I'll finish the meeting if you don't want to discuss anything else
14:12:48 <juhp> okay
14:13:06 <juhp> I'll try to follow to some of the remaining open questions on the ml
14:13:15 <tjanez> Let's continue discussions on the ML (maybe we could even open separate threads about specific questions)
14:13:19 <juhp> sounds good
14:13:31 <tjanez> juhp, you beat me to it :)
14:13:45 <juhp> synchronicity :)
14:16:56 <mmaslano> #endmeeting