Re: do we consider using patchwork ?
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
Re: do we consider using patchwork ?
Hi. Wed May 22 23:41:13 GMT+02:00 2019 Willy Tarreau : > Hi Ilya, > > On Thu, May 23, 2019 at 01:29:53AM +0500, ??? wrote: > > Hello, > > > > if we do not like using github PR and Willy receives 2k emails a day... > > do we consider using something like that > > https://patchwork.openvpn.net/project/openvpn2/list/ ? > > At least not now, please let's slow down on process changes, I cannot > catch up anymore. Really. I find myself spending 10 times more time in > a browser than what I used to do 6 months ago, for me it's becoming > very difficult. Between the issue tracker, the CI, github settings, the > links to dumps, confs or logs that are lazily copy-pasted instead of > sending the info itself etc... In the end I find myself working far > less efficiently for now, having to spend more time at work to produce > the same, however it helps others work more efficiently, which is nice. > But since I've always been a bottleneck, it remains important that we > don't forget to optimize my time, or everyone will spend their time > waiting for me, which I cannot accept. And the worst that can happen > is that I become a bottleneck due to processes because this would be > something I wouldn't be able to improve at all. Full ack. >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. How about to add into the tools mailing forward and reply? We can then use the mail clients for communication and the tools will receive the answers automatically. Jm2c > I hope you can understand that no change comes with zero cost and that > for some people (like me) they come with a higher cost. Sometimes this > cost can be recovered over time, sometimes it's a pure loss. So let's > not engage too many changes at once and keep some time to observe the > outcome of everything we've done for now. > > Cheers, > Willy Regards Aleks
Re: do we consider using patchwork ?
Hi Ilya, On Thu, May 23, 2019 at 01:29:53AM +0500, ??? wrote: > Hello, > > if we do not like using github PR and Willy receives 2k emails a day... > do we consider using something like that > https://patchwork.openvpn.net/project/openvpn2/list/ ? At least not now, please let's slow down on process changes, I cannot catch up anymore. Really. I find myself spending 10 times more time in a browser than what I used to do 6 months ago, for me it's becoming very difficult. Between the issue tracker, the CI, github settings, the links to dumps, confs or logs that are lazily copy-pasted instead of sending the info itself etc... In the end I find myself working far less efficiently for now, having to spend more time at work to produce the same, however it helps others work more efficiently, which is nice. But since I've always been a bottleneck, it remains important that we don't forget to optimize my time, or everyone will spend their time waiting for me, which I cannot accept. And the worst that can happen is that I become a bottleneck due to processes because this would be something I wouldn't be able to improve at all. I hope you can understand that no change comes with zero cost and that for some people (like me) they come with a higher cost. Sometimes this cost can be recovered over time, sometimes it's a pure loss. So let's not engage too many changes at once and keep some time to observe the outcome of everything we've done for now. Cheers, Willy
do we consider using patchwork ?
Hello, if we do not like using github PR and Willy receives 2k emails a day... do we consider using something like that https://patchwork.openvpn.net/project/openvpn2/list/ ? cheers, Ilya Shipitsin
