Hi Aleks, On Thu, May 23, 2019 at 08:05:18AM +0200, Aleksandar Lazic wrote: > From my point of view is the ci and issue tacker a good step forward but for > now we should try to focus on the list as it is still the main communication > channel.
I mean, there are multiple valid communication channels, since there are multiple communications at the same time. For example, Lukas, is doing an awesome job at helping people on Discourse and only brings here qualified issues so that I almost never have to go there. Same with the github issues that we've wanted to have for quite some time without me being at the center of this, they work pretty well right now, and if something is ignored for too long, someone will ping here about the problem so it works remarkably well. > How about to add into the tools mailing forward and reply? Given that there are people who manage to sort this info first, I'd rather not for now. This is less stuff to concentrate on. For me it is very important to have a set of trusted people who I know do the right thing, because when an issue is escalated here or when I get a patch that was said to be validated regarding a GitHub issue, in general, I apply it without looking at it and it's a big relief not to have to review a patch. > We can then use the mail clients for communication and the tools will > receive the answers automatically. Someone would have to set this up, and possibly to develop a bot like Lukas did for the PRs. At the moment the stuff is more or less well balanced, it's just that we have added lots of useful tools in a short time and that these ones still need to be cared about because, well, it's the beginning. Also for me it's important that we don't forget the real goals : the goal is to improve haproxy, not to improve the tools. If improving the tools improves haproxy, fine. But the tools are not the goal but a way to reach the goal faster. For example, the CI is very useful since we now detect build breakage much earlier. However we need to keep in mind that it's an indication that we broke something, it must not be a goal to have green lights all the time. If something is broken on a platform (even an important one) because of an ongoing change and we consider it's more important to finish the changes than to fix this platform, I'm perfectly fine with this. It eases the developers' work by giving them the feedback they need without having to actively re-test their changes everywhere (and Travis is particularly good at this because it triggers a build almost instantly after a push so the loop feedback is very fast). For example, the problem that was reported by Cirrus on the FreeBSD build breakage by the recent watchdog changes annoys me, not because Cirrus is red, which I don't care about, but because it's still broken after the fix that I thought valid, and now I know that the supposedly valid POSIX defines I used to detect support are not portable, so I will need to be extra careful about this and to fix it while it's still fresh in my head. So let's just try to put a pause in the tooling improvements so that we still have a bit of time available for the code, and see what can be improved in 3-6 months once we feel that things are going well except a few that need to be addressed. It will save us from wasting time doing mistakes. Cheers, Willy