Hi all,
I wanted to send this earlier but we've had two quite busy weeks, and
now things are cooling down.
I want to propose a plan for the 1.8 development cycle. Everyone has
noticed that 1.7's was a terrible mess with nothing happening at the
beginning and everything being merged in a hurry in the last few month.
Since it's difficult to enforce merge windows on a year-long project, we
have two options :
- release very often and maintain only a small set of versions along
time (more or less the Linux model). We're quite not ready for this,
it may only make sense if we reach a level of contributions which
require to release every 3-4 months but that's not the case now and
that would be counter-productive ;
- have two distinct merge windows, one for unplanned stuff and another
one for planned stuff that people advertise in advance so that
others can watch their progress and know that some merge/rebase may
ultimately be needed.
For 1.8 I'll go via the second approach. What I intend to do is the
following :
- phase 1 : pending queue and unplanned changes : every contribution
is welcome (well, based on technical quality and usefulness) until
Friday 2017-03-31. We do already have some stuff pending that I
still didn't have the time to merge (don't stress, if I told you
I'll pick it, I'll do it or I'll have to invent a good excuse for
not doing so).
- phase 2 : completion of planned changes : some changes take more
than a few months to be completed and will have to be merged
later. Such changes *must* be announced in advance so that others
have some time to discuss the impact on their work (or even oppose
to the inclusion). I haven't fixed a deadline yet for the announces
but let's say end of February. This phase will allow some of us to
only focus on planned work and not to have to review code arriving
at random time. This phase 2 will end on 2017-09-30. At this point,
all incomplete features will be postponed for 1.9.
- phase 3 : tests, fixes, cleanups and reverts before the release : no
new feature is supposed to arrive here. It's very similar to a
maintenance branch except that we can revert stuff that doesn't work
if it's considered unfixable in a short time. These versions are
release candidates. This phase has no strict end date though we'll
focus on October or November but not later, and we'll privilege
reverts instead of postponing fixes.
We'll need to emit numerous development versions if we want to have
testers. It's important to ask for them, as developers generally don't
see time flying.
With such a model I expect that we'll be able to implement some stuff
which requires more concentration than what we could have during 1.7-dev
(but 1.6 bugs have plagued us for a while).
We do already have the following features in queue for phase 1 (they're
subject to evolve, change or even to disappear) :
- JSON stats
- PCRE2 support
- crt-bind-list
- proxy-addr
- asynchronous / pipelined SPOP
For phase 2, an option was already taken for such features (remember
that it only means we'll attempt to get them merged) :
- HTTP/2
- multi-threading
- RAM-based "favicon" cache
- DNS SRV records
- openssl async API implementation
There are also a number of interesting features which are looking for an
adopter in the ROADMAP file and a few extra things like these ones :
- stack-based expression evaluator to merge sample fetch functions and
converters, providing extended possibilities (string compare etc)
- reintegration of the systemd wrapper into the main program to run in
a master-worker mode (see how that conflicts with multi-threading).
This work was already attempted by Simon a few years ago but the
internal architecture was quite not ready for this. I don't know how
it compares now.
- one log-format per log server
- multi-process support for peers
- check result broadcasting over peers protocol
If you intend to work on something in these areas or any other one you
have in mind and want to reserve a slot for phase 2 (merge no later than
end of September), please announce it here. Otherwise you'll have to get
it in a mergeable state before end of March, or it will only be for 1.9.
I've explained this at a meetup two weeks ago, the slides are now online
here for those interested (not many more info than what is explained here
though) :
http://www.slideshare.net/MichaelCarney6/whats-new-in-haproxy
Any questions, comments, objections ?
Thanks,
Willy
