[ech] ECH PR split/progression

[Matt Caswell]

On 22/01/2024 01:07, Stephen Farrell wrote:

> FWIW, I'm unclear if following this plan would mean that
> (all going well) each PR would be merged with master before
> the next is processed, or if the plan is really to help with
> more tractable reviews before ending up again with one PR
> that has all the functionality.

If we are aiming to have smaller PRs that can individually be merged to 
master then each PR needs to be entirely stand alone and include all 
tests etc relevant to it. From 3.3 we are doing "time based" releases 
(with 3.3 being in April this year), which means that master must be in 
a ready-to-go state at any point. We can't have "half finished" changes 
in master.

The alternative is for us to create a "feature branch" for ech and put 
reviewed PRs there, pending the complete set becoming available. We have 
one such feature branch at the moment 
(https://github.com/openssl/openssl/tree/feature/quic-server) - but 
frankly we're still figuring out how to manage things via a feature branch.

There are pros and cons to each approach.

The stand alone approach is simplest. We understand what we are doing 
with that. On the downside it might be more difficult to break things up 
to be entirely stand alone. Additionally we might be less willing to 
merge a big "high risk" PR the closer we get to April (or any subsequent 
time-based release date).

OTOH the feature branch approach has the advantage that we can work on 
the PRs without worrying about release dates etc, or ensuring that 
everything is fully stand alone. We can have "half finished" features in 
a feature branch. On the downside we are still learning how to manage 
feature branches - we haven't done them before. Such a feature branch 
would need to be regularly rebased (probably by a committer) - and we're 
not too clear on what the rules are for doing that or how it will work. 
There is a certain "overhead" in having a feature branch.

I'd personally prefer the stand alone approach if it can be arranged - 
just because it is simpler.

Matt


> I'm assuming the former, but
> would appreciate confirmation that that's feasible. (E.g.
> the 1st "server" PR would have to omit lots of test code
> that exists and works today, but that wouldn't work if the
> client code is temporarily omitted.)
> 
> Thanks,
> S.
> 
> 
> [1] https://github.com/openssl/openssl/pull/22938
>