diff options
Diffstat (limited to 'meetings/logs/sec-meeting-2018-04-21-log')
| -rw-r--r-- | meetings/logs/sec-meeting-2018-04-21-log | 269 |
1 files changed, 269 insertions, 0 deletions
diff --git a/meetings/logs/sec-meeting-2018-04-21-log b/meetings/logs/sec-meeting-2018-04-21-log new file mode 100644 index 0000000..a599742 --- /dev/null +++ b/meetings/logs/sec-meeting-2018-04-21-log @@ -0,0 +1,269 @@ +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: (security@gentoo.org) 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 security@g.o +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 +2 |