Willy,

Am 25.05.2018 um 18:10 schrieb Willy Tarreau:
> Not started yet but already planned :
>   - split certificates [William] : some users prefer to have separate .key
>     and .crt files (eg for permission reasons). William has already started
>     to look and it seems doable, there are "just" a few shortcomings to take
>     care of (I don't remember which ones).

This one would be great, as it would save me a bash script to
concatenate the output of certbot into something haproxy understands.

> It's possible I accidently missed someone's tasks, if so, please yell now.
> I'd like that any development outside the scope of what is enumerated above
> and not started yet is not submitted for now, because discussing designs and
> reviewing code takes a huge amount of time and concentration that inevitably
> postpones code progress on planned stuff.

One pain point I am missing from the list is "(add|set)-header" for
redirect responses (or is this part of something else?). We discussed
this briefly in March:

Subject: Re: add header into http-request redirect
Message-ID: <3dd0fbb0-403e-9791-be22-98c7be990...@bastelstu.be>
https://www.mail-archive.com/haproxy@formilux.org/msg29294.html

IMO this is a great example of why an issue tracker is superior to a
mailing list (I'll further get to that below): Things do not get lost in
the stream of other discussion; people can easily re-use the existing
discussion, without fishing for Message-IDs in the mail archive. You
acknowledged that in:

https://www.mail-archive.com/haproxy@formilux.org/msg29358.html
Message-ID: <20180319220157.gh26...@1wt.eu>

> For the next steps given that we've spent a lot of time dealing with bugs and
> painful patches, I'll be a bit more demanding regarding changes. While the
> vast majority of regular contributors have made an awesome progress in the
> quality of their patches, we're still spending some time reviewing huge
> patches that should be broken up into smaller pieces, or re-editing commit
> messages to avoid ruining the life of the -stable team. Sometimes patches

Personally I really want to add my 2ct to some of the patches, but
what's preventing me from doing so is:

1. My email client makes it hard to comment on specific lines in
attachments. That's why I personally send my patches inline (!) using
git send-email / git format-patch.
2. I don't feel like bombarding all the list subscribers with a mail
complaining about typos in commit messages or code comments.
3. The annoying autoresponders of misconfigured Exchange mail servers,
informing me that some random employee of random company is currently
out of office. Every other time I send an email to the list I get
several of those messages back.

I grew up with GitHub and systemd, you don't like those, I very much
like both of them. And for me the barrier to participation would be much
lower using GitHub's Pull Requests.

Yes, Pull Requests encourage drive by committers more than now, but OTOH
you don't know what you might miss out on, both on good patches and on
good review. I know that CONTRIBUTING explicitly mentions pull requests
and merge commits as "bad", but GitHub nowadays supports rebased merges
directly from the web interface, thus avoiding merge commits.

I regularly contribute to various Open Source projects I use using
GitHub pull requests, it's much easier for me to fork the project,
skimming the CONTRIBUTING file and sending a (IMO) high-quality PR that
usually gets merged without much discussion. Often the whole turnaround
time is less than half a day.
For haproxy I would need to subscribe to the list, configure my email
client properly so that my patches don't get mangled, set up filters for
my mail so I don't miss out the review etc.

> We do have a few plans with this account now, some of which seem appealing,
> and others who don't sound really compatible with some annoying GitHub
> limitations, making me think that maybe in the end we should switch to
> Gitlab (William already created haproxy.org there) :

Personal opinion: Use GitHub for the ecosystem. For me GitLab would be
an even greater pain than the mailing list.

>   - re-enable issues : we still don't have a public bug tracker/todo list
>     and it's a pain for everyone. It would be nice to show what's pending
>     or being worked on, and to sometimes add extra info regarding a given

Very much yes (see above).

>     task. The problem we've faced in the past with GitHub's issue tracker
>     is that it's impossible to restrict the creation of new issues to
>     participants. Given that haproxy is a complex component, the boundary
>     between human error, misunderstanding and bug is extremely thin. It
>     resulted in the issue tracker being filled with wrong bugs, 100% of
>     which were in fact requests for help. It makes the utility totally
>     useless for development and bug fixing as it requires more time to
>     maintain in a clean state than it takes to put issues in a mailbox.

I believe that an open issue tracker results it a net-positive overall
for the following reasons:

1. Issues can easily be triaged by volunteers (such as Lukas already
does on Discourse), be properly labeled and closed if invalid. This does
not take away time from the developers I believe. In fact it might be
even easier, because the developer can see at a glance that the issue is
closed and he must not read through a long mailing list thread.
2. Again: Barrier to entry. I outlined it above for pull requests, but
it does apply to issues as well. Projects miss out on valuable bug
reports for edge cases, because people don't bother subscribing to a
mailing list.

>     Some people suggested using issue templates, but I hardly see how this
>     will help, at best it will annoy regular participants, at worst it will

Templates are not mandatory on GitHub, experienced reporters can opt to
simply ignore them.

>     not stop polluters from filling crap there.

See above why I believe an open issue tracker is a good thing.

>     A limitation that isn't addressed by any of them is that an issue has
>     a single status and not one per maintenance branch. Some will say that
>     labels replace this but I'd say that this isn't true, it just vaguely
>     emulates this. Anyway if we don't have better we can go with this. I
>     often dream of the day someone pissed of by using prehistoric issue
>     trackers writes a modern one, just like when Linus created Git...

As bugs will be fixed in the development branch first the status would
refer to that. The bugfix will naturally appear in the maintenance
branches in the future.

>   - wiki : we all know that the architecture guide is obsolete, everyone
>     wants to refresh it and nobody can because it's a tedious task that
>     no single person can address, and nobody anymore knows all haproxy
>     pieces. In addition a lot of participants have useful tips to share
>     and would be much more at ease with putting this into a wiki than by
>     editing architecture.txt. Thus I'd like to reuse either Github or
>     Gitlab's wiki to place real contents edited and maintained by the
>     community, and to kill this obsolete file. This way the obsolete stuff
>     on the main haproxy.org page could go as well.

In my experience: GitHub / GitLab pages are far superior to the Wiki and
can be handled with Pull Requests as well. Regular contributors could be
given write access to the "guide repositories".

>   - automated builds and CI : gitlab and github have these possibilities
>     (either natively or relying on third party products). It would help
>     us detect the occasional stupid build breakage (like building with/
>     without threads, with/without SSL).

I agree this is a good thing.

>   - maybe placing the releases there will help (I don't know the upload
>     process for any of these, will have to check closer). It may even be
>     used for Aleks' docker images if that makes sense at all (I don't
>     know).

GitHub: You are able to attach downloads to git tags. This probably
would imply having all the maintenance repositories as separate branches
in a single repository (i.e. not master in haproxy-1.8.git, but 1.8.x in
haproxy.git).

Best regards
Tim Düsterhus

Reply via email to