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: <[email protected]> https://www.mail-archive.com/[email protected]/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/[email protected]/msg29358.html Message-ID: <[email protected]> > 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
