2018-04-21 15:00:19 @K_F meeting time
2018-04-21 15:00:45 @ChrisADR !proj security
2018-04-21 15:00:46 willikins ChrisADR: (email@example.com) a3li, ackle, blueknight, bman, chrisadr, creffett, k_f, pinkbyte, whissi, zlogene, zx2c4
2018-04-21 15:01:17 * Pinkbyte is here
2018-04-21 15:01:24 * K_F here
2018-04-21 15:01:26 * ChrisADR here
2018-04-21 15:01:41 * b-man is here
2018-04-21 15:03:09 * Whissi is here
2018-04-21 15:03:49 @ChrisADR ok, 2 more mins and shall we begin?
2018-04-21 15:04:08 @K_F just begin
2018-04-21 15:04:37 @K_F if others joins we'll just record it as present
2018-04-21 15:04:47 @ChrisADR ok, so first topic on the list, Security GLEPs
2018-04-21 15:05:29 @K_F due to other issues, I haven't gotten around to writing up a specific GLEP 14 replacement at this time
2018-04-21 15:05:57 @K_F but the current status is we likely want to change sufficient enough to do a replacement..
2018-04-21 15:06:10 @b-man K_F: Do you have a shell or rough draft already?
2018-04-21 15:06:29 @K_F in terms of the implementations I'm going in direction we implement it in portage, and use that as reference implementation
2018-04-21 15:06:39 @K_F if other PMs wants glsa-check support they can implement it themselves
2018-04-21 15:06:43 @b-man I know you are doing a lot of work with big Gentoo problems... so if I can help let me know
2018-04-21 15:07:13 @K_F but yeah, we should keep timeline for this meeting to 2h, as trustee meeting starts then
2018-04-21 15:07:35 @ChrisADR ok, sounds good, talking about implementations, are we going to split glsa-check in a different GLEP?
2018-04-21 15:07:58 @ChrisADR or better stated, the standard so other PMs can use our data
2018-04-21 15:08:02 @K_F glsa-check would be an implementation, so not a specific GLEP needed per se
2018-04-21 15:08:13 @K_F if we want a GLEP it would be to describe the format of our GLSAs
2018-04-21 15:09:03 @K_F there are two ways of doing that, one is to describe that we maintain a schema for GLSAs in the security GLEP but not the details
2018-04-21 15:09:27 @K_F but directing to where the schema is described and in what format, which gives us more flexibility
2018-04-21 15:09:40 @K_F and of course we should version it appropriately
2018-04-21 15:10:06 @b-man agreed
2018-04-21 15:10:29 @K_F I don't necessarily see the need for a GLEP for the GLSA format specifically, as long as we take care of some timeline before introducing backward breaking changes
2018-04-21 15:11:08 @K_F but my take is we should provide the reference implementation in the standard stage3 which is portage
2018-04-21 15:11:16 @Whissi The format itself doesn't need a GLEP like we don't have a GLEP for ebuilds. But I am not sure if we should define basic functionality we expect from a security tool implementation.
2018-04-21 15:12:02 @K_F well, ebuilds have PMS
2018-04-21 15:12:06 @Whissi Things like "checking against GLSA data, when affected MUST end with non-zero exit or something like that.
2018-04-21 15:12:53 @b-man Looks to me like you are thinking along the same lines.
2018-04-21 15:14:55 @b-man We would not be blocking any PM from implementing their own security methods.
2018-04-21 15:15:24 @K_F right, we should describe the format and a reference implementation, but not support for all PMs
2018-04-21 15:15:42 @K_F but we should of course take that into consideration when doing actual changes
2018-04-21 15:16:05 @K_F e.g a 1-2 month delay from using new features after they are described
2018-04-21 15:16:09 @b-man and I am favor of *not* making security responsible for a specific tools development
2018-04-21 15:16:56 @b-man We can define the standard as Kristian has descibred and let the PM's do their development
2018-04-21 15:17:46 @K_F currently that is a dtd, we likely want to move it to a xml schema to have some flexibility, but it doesn't really affect GLEP 14 replacement per se
2018-04-21 15:18:58 @ChrisADR I guess it all will be clearer once we have the first draft about what we expect the kind of data to present to users, with that each PM could prepare the best way to approach the situation
2018-04-21 15:19:54 @K_F in all fairness, that won't deviate much from the current dtd
2018-04-21 15:20:03 @b-man +1
2018-04-21 15:20:04 @Whissi K_F: We already created a new XSD (thanks to mgorny).
2018-04-21 15:20:24 @K_F yes, which I prefer to use as the specs
2018-04-21 15:20:43 @ChrisADR ok then, do you agree to skip this topic until we have more solid information about the implementation?
2018-04-21 15:20:52 @K_F wfm
2018-04-21 15:21:07 @K_F or rather, the implementation has less interest, the specs does
2018-04-21 15:21:20 @Whissi OK, let's move to the next topic.
2018-04-21 15:21:50 @ChrisADR ok, glsamaker status...
2018-04-21 15:22:19 @ChrisADR on my mail I made the mistake of writing LTS support, it should have been community support for rails 4.x
2018-04-21 15:23:10 @ChrisADR but the result is pretty much the same I guess... do we need to start working in the documentation for an update or from scratch project?
2018-04-21 15:23:33 @Whissi Given that glsamaker isn't a public application it is acceptable to keep running code without support. Not nice, but not a big drama.
2018-04-21 15:23:36 @K_F rewriting from scratch is a big job
2018-04-21 15:24:15 @K_F I'm generally very sceptical of doing it, and if doing it, we need to take the time to write up a proper RFP for where we want to end
2018-04-21 15:24:37 @Whissi Yeah...
2018-04-21 15:24:51 @ChrisADR ok, is someone willing to take the RFP paperwork?
2018-04-21 15:25:09 @K_F at this time I'd say we stick to working with the current implementation
2018-04-21 15:25:16 @Whissi I have talked about this with blueknight before, we maybe should look into https://github.com/archlinux/arch-security-tracker
2018-04-21 15:26:16 @Whissi Goal should be to automate it a lot with the result to have GLSA for more packages, i.e. even for B/C and 3/4 rated things... just because we track things differently
2018-04-21 15:26:34 @b-man How would moving impact our database impl and CVE status with upstream?
2018-04-21 15:27:02 @ChrisADR yea, the thing is that I think that with our current implementation we are not achieving the goal
2018-04-21 15:27:19 @b-man Whissi: I agree on automation.
2018-04-21 15:27:24 @Whissi Sorry, don't get this. Please re-phrase, b-man
2018-04-21 15:27:37 @ChrisADR which, agree, should be to cover as much as possible from the stable gentoo ebuild repository
2018-04-21 15:27:38 @Whissi (the database impl thing)
2018-04-21 15:27:49 @b-man If we look at more automation though we will need to agree on dropping some of the verbiage in GLSA's.
2018-04-21 15:28:24 @K_F I find actually working through the bugs to be necessary in determining the impact for gentoo
2018-04-21 15:28:31 @b-man Whissi: Our database implementation which has all of our CVE data. I want to ensure we don't impact that as (to my understanding) it can affect our standing as a CVE source?
2018-04-21 15:28:48 @Whissi We are no CVE source.
2018-04-21 15:29:04 @b-man Maybe Kristian can clarify what our CVE standing/status is.
2018-04-21 15:29:11 @K_F we're not a CVA atm, so that doesn't change much
2018-04-21 15:29:36 @b-man Whissi: Right, I am using the wrong term, but whatever our CVE role may or may not be
2018-04-21 15:29:41 @K_F we likely want to become one at some point, in particular for Gentoo specific issues which is a natural step (e.g init scripts etc)
2018-04-21 15:29:52 @K_F CNA*
2018-04-21 15:29:59 @b-man CNA... that's it
2018-04-21 15:30:30 @K_F but I don't see a reason for us to be a global CNA at this point, so if we go that route it is for gentoo specific issues
2018-04-21 15:30:55 @b-man Whissi: Have you deployed this Arch security tool? Will it assist our workflow?
2018-04-21 15:31:12 @Whissi It will be a new workflow.
2018-04-21 15:31:21 @Whissi Arch Linux use to to group vulns
2018-04-21 15:31:30 @Whissi and to track vulns in first place
2018-04-21 15:31:36 @ChrisADR and before moving to a CNA role, we first need to be able to track our packages, for example we have >200 vulns that need to be tracked in cvetool
2018-04-21 15:31:39 @Whissi b.g.o would only be the detailed bug per packages
2018-04-21 15:31:45 @Whissi bug the main thing will happen in this tool
2018-04-21 15:32:04 @Whissi This is necessary because b.g.o doesn't really allow grouping
2018-04-21 15:32:06 @ChrisADR or at least sorted and/or reported
2018-04-21 15:32:09 @Whissi and such a thing
2018-04-21 15:32:40 @b-man Whissi: Ok, do you see it as an easy task to include code to output the GLSA XML?
2018-04-21 15:32:49 @b-man i.e. integrate
2018-04-21 15:32:54 @Whissi Yes.
2018-04-21 15:33:13 * b-man is a fan of testing it
2018-04-21 15:33:36 @ChrisADR Whissi: could you prepare a testing env so that we all could see it?
2018-04-21 15:33:38 @Whissi https://security.archlinux.org/ frontend
2018-04-21 15:33:54 @b-man Whissi: Yes, checking it out :)
2018-04-21 15:33:56 @K_F testing alternative implementation is of course always good, but I'd say we can work on automating our current implementation instead of switching over
2018-04-21 15:34:38 @b-man K_F: I would like that very much, but I think the learning curve is a hinderance to whatever the hell that thing is designed in.
2018-04-21 15:34:50 @b-man (I know what it is built in... sorry for the dramatic response :))
2018-04-21 15:35:36 @ChrisADR besides, in my understanding, the current codebase is not overwhelmingly big yet
2018-04-21 15:35:54 @Whissi Keep in mind, arch's tool is doing things differently. See there "AVG-..." group.
2018-04-21 15:35:54 @K_F its relatively easy to grasp
2018-04-21 15:35:56 @b-man Plus, we have some underlying performance issus as well. I know Thomas has tried to fix some
2018-04-21 15:36:19 @Whissi s/there/their/
2018-04-21 15:36:48 @ChrisADR yes, and since it's easy to grasp now, it's a good time to consider new implementations, with a more complex tool, considerations wouldn't be an option
2018-04-21 15:37:57 @ChrisADR that grouping system is most likely what I was pretending to do with the custom field from bugzilla
2018-04-21 15:38:23 @ChrisADR but that's next topic
2018-04-21 15:38:35 @b-man Motion: Coordinate with Gentoo infra to deploy a testing environment for the Arch Security Tool.
2018-04-21 15:39:08 @K_F given that the delay in most cases is waiting for stabilization etc, I don't see a major need for rework of the current glsamaker
2018-04-21 15:39:13 @Whissi But to be clear: I don't have time for a new GLSAmaker yet. Maybe at the end of this year, but not in the next 3-4 months.
2018-04-21 15:39:24 @b-man Haha ok.
2018-04-21 15:39:27 @b-man disregard
2018-04-21 15:39:29 @K_F in the process of making a GLSA we often find things that needs to be adjusteed
2018-04-21 15:40:25 @ChrisADR to be fair, the GLSA generation process does indeed work with glsamaker right now
2018-04-21 15:40:43 @ChrisADR I'm more concerned about our capability of tracking all the issues
2018-04-21 15:41:33 @Whissi Creating GLSA isn't the problem right now, right.
2018-04-21 15:42:04 @ChrisADR and as we saw last week, first time we created a ncurses GLSA,
2018-04-21 15:42:25 @ChrisADR and that's probably because we can't track all the issues right now,
2018-04-21 15:42:55 @b-man Whissi: How is data fed to the Arch Security tool? Is it parsing CVE's automatically?
2018-04-21 15:43:00 @ChrisADR and I guess that's where we need automation
2018-04-21 15:43:17 @ChrisADR more than GLSA generation
2018-04-21 15:43:37 @b-man ChrisADR: point taken, but I would also say that it is *possible* we bumped and stabilized ncurses before a CVE was released.
2018-04-21 15:43:53 @b-man Which happens quite often in Gentoo
2018-04-21 15:44:29 @b-man So, what are we wanting to do here?
2018-04-21 15:44:30 @Whissi Well, from my p.o.v. the problem is a different one. If you have _one_ vuln in _one_ pkg everything is easy. Especially when we can create bug from CVEtool because CVE was already published.
2018-04-21 15:45:08 @Whissi But once there are multiple vulns and/or a vuln affecting multiple packages, things become hard to manage.
2018-04-21 15:45:40 @Whissi And this is was arch's implementation is addressing because they added a CVE tracker on top, decoupled from bugs.
2018-04-21 15:46:09 @K_F right, but that is a difficulty that is natural, and we'd still likely want to release the GLSAs as they are fixed
2018-04-21 15:46:34 @K_F the typical example is embedded small libraries
2018-04-21 15:46:35 @Whissi ...and this is something I would want change when we build something new :p
2018-04-21 15:46:51 @K_F which we should try to avoid to begin with
2018-04-21 15:47:10 @K_F embedding is only negative
2018-04-21 15:47:22 @Whissi But this is going off topic right now.
2018-04-21 15:47:48 @ChrisADR ok, I think we all agree that GLSAs are not the problem
2018-04-21 15:47:54 @ChrisADR right now at least
2018-04-21 15:48:28 @Whissi Yeah, creating the GLSA is the easiest thing in our process.
2018-04-21 15:48:32 @ChrisADR but we need to take in consideration arch's perspective and other options for tracking issues or CVEs that may help us to have better response times
2018-04-21 15:49:30 @K_F we still need to track that in bugzilla to include workflow of other devs, and fixes in revbumps vs full versions
2018-04-21 15:49:52 @ChrisADR yes, we need that too
2018-04-21 15:50:17 @ChrisADR which takes us back to the point, is someone willing to write a document describing the situation and requirements? :P
2018-04-21 15:50:34 @Whissi Let's move on. I think I am the only one who have seen Arch backend... questions like the one from K_F are good but if you would know the backend you wouldn't ask that. Let's move one to the next topic for now :)
2018-04-21 15:50:36 @ChrisADR I can draft it if you want
2018-04-21 15:50:56 @b-man Whissi: If you have seen it then I stand by my motion
2018-04-21 15:51:04 @b-man Why not give it a go :shrug:
2018-04-21 15:51:13 @b-man I trust your judgement enough
2018-04-21 15:51:38 @b-man If it does not prove worthwhile then we can move on.
2018-04-21 15:52:10 @K_F yes, I haven't seen the arch backend before
2018-04-21 15:52:36 @ChrisADR b-man: could you help with infra request for deploying a testing env?
2018-04-21 15:52:42 @b-man sure
2018-04-21 15:53:03 @ChrisADR but without any major change, just to see how it works by default
2018-04-21 15:53:17 @ChrisADR and use that info to see if it's worth it
2018-04-21 15:53:18 @Whissi We cannot just test it and keep our workflow. We would either have to test it side-by-side keeping our old workflow which would limit the experience or we would have to stop current workflow for some time.
2018-04-21 15:53:51 @ChrisADR couldn't we connect it to development bugzilla env?
2018-04-21 15:54:03 Irishluck83 I would think doing it side by side just in case this doesn't work out
2018-04-21 15:54:13 @b-man Whissi: I defer to you then to determine what is the best way forward.
2018-04-21 15:54:38 @ChrisADR I think we can have it running and see how it works, but without changing our current workflow
2018-04-21 15:54:38 @K_F Whissi: right, which goes back to writing up a RFP on what we want for changing, if the arch variant satiesfies that , even better
2018-04-21 15:54:40 @Whissi Also keep in mind that Arch doesn't care about unstable/stable. They don't have such a thing. From security perspective I'd like to have the same. I.e. when we know there's a vuln it doesn't matter if the package is stable. We need a solution. For ~arch and arch..
2018-04-21 15:54:49 @K_F but we should have a positive gain from any switch
2018-04-21 15:55:24 @K_F ~arch isn't security supported, so we should have that distinction
2018-04-21 15:55:58 @b-man Whissi: Are you suggesting that the increased ability to process things will allow us to drop that distinction?
2018-04-21 15:56:06 @Whissi Yeah, but like said I would change our workflow if we move to something new in many ways. :)
2018-04-21 15:56:15 @Whissi b-man: Exactly!
2018-04-21 15:56:32 @ChrisADR it would be the best for us, indeed
2018-04-21 15:56:42 @ChrisADR then we could support gentoo as a whole
2018-04-21 15:56:50 @b-man K_F: Is there some historical reasoning as to why we differentiated between ~ and stable?
2018-04-21 15:57:12 @b-man (from a security perspective)
2018-04-21 15:57:50 @K_F b-man: as we don't restrict what developers put into no-kw or ~arch, but require a higher degree of conciousness of what goes into stable
2018-04-21 15:58:03 @K_F but mostly it is a matter of what we can track as a project
2018-04-21 15:58:13 @K_F that goes into auditing as well on some level
2018-04-21 15:58:42 @b-man I don't forsee an issue with devs putting things in ~arch
2018-04-21 15:58:48 @Pinkbyte b-man, stable versions require more work(stabilization) than ~keyword ones
2018-04-21 15:58:52 @Pinkbyte just that
2018-04-21 15:58:54 @b-man If it is open source it is open to the same scrutiny any other package is
2018-04-21 15:58:55 @Whissi If we tell people running ~arch they are using a vulnerable package some of them will start asking us "Ugh? And why don't you fix it?!"... so we would get a lot more user requests... but I think we can handle that and in the end I hope we will gain something. Maybe new devs who will help bumping because their PM keep nagging them "You are vulnerable" :p
2018-04-21 15:59:20 @K_F Whissi: ultimately we support stable version of Gentoo
2018-04-21 15:59:37 @Whissi Yup.
2018-04-21 15:59:45 @ChrisADR yes, but I guess that if we were able to support every package, we could say that we support all gentoo?
2018-04-21 15:59:47 @b-man Whissi: I would take the opposite stance. ~arch can generally be looked at as more secure
2018-04-21 16:00:26 @b-man the delay from ~ to stable is the problem we have right now...
2018-04-21 16:00:32 @K_F b-man: only if upstream fixes things timely
2018-04-21 16:00:44 @b-man K_F: Agreed, but compound that with our stabilization delays...
2018-04-21 16:01:08 @ChrisADR well, let's land the ideas, do you agree if I work on a RFP to see what we need in matters of tracking and coordinating with other devs, and begin with that?
2018-04-21 16:01:11 @K_F b-man: a DoS due to failure of a fix on info leakage might have more severe consequences
2018-04-21 16:01:27 <-- sokan (~Henry@unaffiliated/totaloblivion) ha salido (Remote host closed the connection)
2018-04-21 16:01:46 @ChrisADR because it seems that GLSA by itself is not an issue with our current procedures
2018-04-21 16:01:51 @Whissi ChrisADR: Everyone can always do that. Than we can talk about it in detail instead of wasting time like now ;-) So please do that, if you have that time.
2018-04-21 16:02:13 @b-man +1 from Whissis comment
2018-04-21 16:02:16 @ChrisADR ok, I'll prepare that and leave it in firstname.lastname@example.org
2018-04-21 16:02:26 @ChrisADR that brings us to the last topic
2018-04-21 16:02:52 @b-man K_F: I agree a DoS is an issue, but if that DoS is known and fixed then it naturally lands in ~. We stabilize following that thus leaving our stable users vulnerable until then.
2018-04-21 16:03:25 @ChrisADR long story short, I've seen myself and every other padawan in the situation of discovering how to track bugs in bugzilla, search and all of that... we may need some more visibility from bugzilla and our "saved searches"
2018-04-21 16:03:52 @Whissi b-man: K_F is talking about a DoS due to program error in a new version undetected because it wasn't tested before, not about a DoS vuln I think. That's my understanding.
2018-04-21 16:04:01 @b-man Ah, Ok.
2018-04-21 16:04:23 @b-man I don't believe AT's are setup to detect a DoS :-P
2018-04-21 16:04:26 @ChrisADR that's why I wanted to propose a new field in bugzilla, for vulnerabilities component, that way we could generate a single report containing all the active bugs, sorted by whiteboard and package-affected(only one)
2018-04-21 16:05:18 @K_F Whissi: yes
2018-04-21 16:05:31 @Whissi ChrisADR: Can you show us a an example in detail? A bug, the problem, your new field with the values you are thinking of... how this should help us...
2018-04-21 16:06:17 @ChrisADR I sent you an email about bugzilla metrics, on that I listed some reports, one example was with wireshark
2018-04-21 16:06:34 @K_F my immediate take is we can re-use package list for stabilization
2018-04-21 16:06:55 @ChrisADR if we generate a report based in the "summary" field, we'll have 4 different lines for each wireshark-2.x, wireshark-2,3.x
2018-04-21 16:07:24 @K_F but I'm personally less interested in the statistics than the actual fixes
2018-04-21 16:07:25 @ChrisADR same goes for package-list, wihch would have one line for packege-v1, samepackage-v1-r1, and so on
2018-04-21 16:07:51 @Whissi To be honest I don't understand the problem you want to solve with metrics.
2018-04-21 16:08:31 @ChrisADR it's a matter of visibility, with one report, I saw that we had over 22 opened bugs that were not just from a couple of weeks ago, but months
2018-04-21 16:08:45 @ChrisADR without been seen
2018-04-21 16:08:56 @b-man ChrisADR: The same package?
2018-04-21 16:08:59 @Whissi This is my security todo query: https://bugs.gentoo.org/buglist.cgi?component=Vulnerabilities&email1=security%40gentoo.org&email2=alpha|amd|arm|hppa|ppc|x86&emailassigned_to1=1&emailcc2=1&emailtype1=equals&emailtype2=notregexp&list_id=3912024&query_format=advanced&resolution=--- -- Works fine :-)
2018-04-21 16:09:02 @ChrisADR different packages
2018-04-21 16:09:36 @ChrisADR resulst were limited to 500 with that approach
2018-04-21 16:09:54 @b-man ChrisADR: I don't doubt you found something that works for you, but I am not understanding it either.
2018-04-21 16:09:56 @Whissi When you view it via b.g.o... query via API and you get all details.
2018-04-21 16:10:19 @b-man ChrisADR: I think if you expound on the problem and the solution we will get it.
2018-04-21 16:10:32 @Whissi Like I am using Deskzilla (Gentoo has a free site license)
2018-04-21 16:10:54 @ChrisADR yes, maybe that's just it, I need to better prepare the idea
2018-04-21 16:11:30 @ChrisADR but that's something I think we should have written down somewhere, all of us here have their own method of "tracking" bugs
2018-04-21 16:12:06 @ChrisADR which causes a duplication of effort discovering the wheel and maybe it's not helping us as a whole to keep good track of every open bug
2018-04-21 16:12:07 @b-man I think that is due to individuality honestly
2018-04-21 16:12:52 @ChrisADR yea, it's about taste I think :) but it would be good to share that somewhere, so that all of us have all the possibilities and see which one fits us better :)
2018-04-21 16:12:56 @K_F well, some duplication of effort there is useful for BUS-factor reasons, but sounds like it can be solved by more comments in the bugs
2018-04-21 16:13:55 @K_F and coordination here in the channel
2018-04-21 16:14:02 @ChrisADR yea, I'll work on a better example for the next time :)
2018-04-21 16:14:39 @ChrisADR ok, any other item before welcoming our scouts / padawans?
2018-04-21 16:14:55 @K_F not anything from me
2018-04-21 16:14:59 @b-man Whissi broke my kernel again
2018-04-21 16:15:08 @b-man :-P
2018-04-21 16:15:12 @ChrisADR haha
2018-04-21 16:15:20 @b-man (inside joke... just messing around) :)
2018-04-21 16:15:28 @ChrisADR ok how many padawans are still here?
2018-04-21 16:15:43 Irishluck83 i am but i need to leave soon
2018-04-21 16:15:57 @ChrisADR anyone else?
2018-04-21 16:16:08 @ChrisADR ok then :)
2018-04-21 16:16:36 @ChrisADR well we just wanted to welcome you Irishluck83, to the meeting and to the security project
2018-04-21 16:16:48 * b-man has a saved round
2018-04-21 16:16:52 @b-man 2 GLSA's need approving :)
2018-04-21 16:16:52 @ChrisADR I know that you have been talking with b-man regularly
2018-04-21 16:17:01 Irishluck83 thanks. i have
2018-04-21 16:17:25 Irishluck83 i think we closed out like 3 bugs in the last 3 days
2018-04-21 16:17:29 @b-man bang gavel?
2018-04-21 16:17:30 Irishluck83 so trying to get there
2018-04-21 16:17:44 @ChrisADR I also wanted to comment you that we all would like to see you actively around
2018-04-21 16:18:14 Irishluck83 will do
2018-04-21 16:18:16 @ChrisADR not just IRC, bugzilla and any other way you can imagine or contribute with
2018-04-21 16:18:17 @b-man He has limited time due to real world stuff, but he is active for a couple hours each night when we work together.
2018-04-21 16:18:43 @ChrisADR yea :) that's good, and good to all of us to know too
2018-04-21 16:19:18 Irishluck83 i would like to help more but tim and all
2018-04-21 16:19:24 @ChrisADR Irishluck83: so keep working hard and try to learn something new everyday, we need much more work to get done, and i'd be good to have your help with that
2018-04-21 16:19:43 @ChrisADR s/i'd/it'd/
2018-04-21 16:19:45 Irishluck83 i am willing to help you guys
2018-04-21 16:19:53 @ChrisADR well, welcome again :)
2018-04-21 16:19:55 Irishluck83 thanks again. i need to go and celebrate my wife bday
2018-04-21 16:19:57 Irishluck83 thanks
2018-04-21 16:20:14 @b-man someone bang the gavel!
2018-04-21 16:20:16 @ChrisADR that's it I think, I'll update the wiki page to reflect our current padawans
2018-04-21 16:20:21 @b-man K_F: Councilman!
2018-04-21 16:20:44 @K_F I don't have anything else to add, so fine with banging gavel
2018-04-21 16:20:52 * ChrisADR waiting for gavel
2018-04-21 16:21:02 @K_F but I'll leave the pleasure for ChrisADR
2018-04-21 16:21:29 @ChrisADR well thank you all, sorry for making this such a long meeting, we'll try to keep it shorter
2018-04-21 16:21:35 @K_F since he's chairing this meeting
2018-04-21 16:21:37 * ChrisADR bangs gavel
2018-04-21 16:22:03 @b-man ChrisADR: I don't mind the length, but more targeted agenda items.
2018-04-21 16:22:19 @K_F the timing of this isn't bad
2018-04-21 16:22:45 @K_F but indeed, we can likely try to discuss more ahead of meeting and more specific meeting items going forwards
2018-04-21 16:22:45 @ChrisADR I expected it to be <60 mins :) but agree, better targeting next time
2018-04-21 16:22:48 @b-man Things we can considerable actionable. We do have some items to consider from this though.
2018-04-21 16:22:59 @b-man s/considerable/consider
2018-04-21 16:23:22 @K_F I generally like that we have more frequent meetings though
2018-04-21 16:23:28 @b-man +1
2018-04-21 16:23:31 @ChrisADR +1