Re: QUIC - Our schedule and scope

[Willy Tarreau <[e-mail]>]

On Fri, Oct 27, 2017 at 11:13:42AM -0400, Patrick McManus wrote:
> A shot
> clock process fix isn't going to get a high quality result - we need an
> attitude fix :)

I agree. It's also important to keep in mind that there are periods in the
year where people are more busy by their work than other periods and this
can give the impression that everything stalls, but participating less does
not necessarily imply not thinking to come back later with clearer views or
more willingness to accept others' proposals.

> I think a better path would be for the chairs to more aggressively declare
> rough consensus at an earlier stage of discussion than is typically done.
> I'm not suggesting a different threshold of consensus, just less indulgence
> in letting issues play all the way out in hopes of convergence. Perhaps
> also an appeal to all WG members to consider the implications of expressing
> an opinion on a topic .

That's exactly what I was thinking as well. I'm fine with delaying a release
for a very good reason, but in general very good reasons more easily achieve
a rough consensus. It's the same with accepting not to delay because the
reason is not very good. If all WG members keep in mind that they take a
responsibility for delaying stuff by opening issues, it can get better.

> I have no objection to updating the milestone delivery date to something
> more reasonable, but I do think elevating schedule to be a higher order
> concern than consensus on the RFC content is wrong.

Agreed as well, we all know a few minor design mistakes that ended up in
H2 and HPACK for the sole reason that we stubbornly refused to play with
a few bits at the end. It makes none of us suffer, but it makes
implementations slightly more painful to write and the protocol slightly
less efficient. I tend to consider that important design must be defined
first and that small variations must be considered at the end. But we must
just accept the fact that a deployed beta version doesn't count as a good
reason for not fixing the last bits at the end, otherwise everyone will
still bikeshed to ensure the small bits that matter to them are committed
first to prevent the H2 process from happening again.

> I think your second suggestion, scoping around HTTP for v1, is more likely
> to get us to a successful finish. As we get later in this process, it will
> be more important.

I think it's reasonable as well, it's hard to try to design for everything
at once, especially in such a very new area.

> > * Discussion of anything else (including issues, drafts, proposals) that
> > doesn't address the needs of HTTP-over-QUIC will be postponed until after
> > V1 has shipped.

In fact we should start to speak about QUICv1 (Q1?) and not QUIC to make
this clear for everyone.

Just my two cents,
Willy