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.


Reply via email to