Hi guys,

just a reminder, if you have pending code that you'd like to get merged
in 1.8 and which you didn't explicitly mention, try to be quick, as 03/31
is approaching (two weeks left), and it is the deadline for unscheduled
code submissions. After this date we'll only accept the already announced
stuff handled by identified people (and fixes for existing stuff of course).

By the way, this is not a placeholder to put 3 lines and expand them
later. I'll happily revert anything before the release if we have dirty
or broken code (and blame the submitter :-)).

The initially planned stuff that already got merged includes :

  - pcre2 (David Carlier)
  - crt-bind-list (Manu)
  - JSON stats (Simon)
  - asynchronous SPOE (Christopher)

And lots of stuff that wasn't initially planned like libressl/boringssl
support and various improvements and cleanups all over the place. That's
not bad at all considering that 1/3 of the patches were bug fixes!

The next phase will only focus on planned stuff to limit disturbance
(which doesn't guarantee that everything will be completed in time).
I'm listing what I have in mind here with the people mostly in charge
of them (when I know them). The purpose is so that we all know who is
supposed to be busy and why a maintainer sometimes doesn't want to be
disturbed :

  - openssl async API (Grant Zhang, currently being reviewed by Emeric
    and looks nice)
  - dynamic cookies support (Olivier Houchard, sent today, I have to
    review it unless someone else wants to take a look)
  - server-template (Hi Fred!)
  - HTTP/2 frontend (me)
  - initial multi-threading support (Emeric+Christopher)
  - DNS improvements (SRV records, server provisioning, etc) (Baptiste
    and maybe a few others)
  - RAM-based "favicon" cache (William)
  - switch of userlists to maps to enable hot updates (William)
  - master/worker model to get rid of systemd-wrapper (William)
  - maybe the ability to pass the listening FDs from the old to the
    new process during a reload to workaround the painful (rare but
    existing) RST issue under Linux when closing the listener
    (Olivier).
  - a few connection management fixes/improvements that are pending
    in a few of my branches (improved close handling & polling
    accuracy)

That's already a lot of stuff! The other points that were suggested will
be very unlikely to be done for 1.8 :

  - stack-based sample expression evaluator (Thierry and I gave thoughts
    to this but found corner cases with recursivity, needs more thinking)
  - per-server log-format (nobody seems to be working on this)
  - multi-process support for peers (same)
  - health checks broadcasting over peers (same)

We also recently discussed about the possibility to improve the error-file
handling (splitting headers and body), I consider that it's still accepted.
Same for all the patches sent here which didn't receive feedback due to the
bottleneck represented by having too few reviewers also dealing with complex
bug fixes. However if you didn't get any response at all nor a mention of
your work above, that's not a good sign so please retransmit to ensure
someone notices it in time.

Let me be clear, I'm not going to be nice with late submissions, they've
caused far too much trouble during the last two releases.

Conversely, if you're running with a patch that I asked to test and you
don't remember sending the feedback, please send it so that we merge it
(this mostly happens with obscure bug fixes but better deal with them
early, saving everyone's time later).

For the next steps, we'll really have to avoid sending patches to add
new features since they systematically disrupt any other activity and
we'll focus only on either bug fixes or the features currently being
developped. I personally consider that since most painful bugs will have
been dealt with by then (expect 1.7.4 and 1.8-dev1 at the same time),
we'll be able to slow down on bug hunting and focus more on the remaining
sub-projects. So in short, I'll be fine with taking obviously valid bug
fixes and that's about all.

If we're seeing a sustained rate of new contributions, we may open a
"next" branch to queue them until 1.8 is released. Let's just avoid the
hassle for now and have each developer work on their respective branch
based on 1.8-dev1.

In the mean time, happy coding, testing and fun with production :-)

Willy

Reply via email to