Hi all,
In the last summit, we discussed about how we implement QUIC. Masaori and I
proposed 4 things below, and as my understanding, there's no -1 so far. I'd
like to propose them again on this list to make it official.
Background:
We are about to start implementing QUIC. Since we faced many HTTP/2 issues
in both development and operating, to make QUIC implementation better than
one for HTTP/2 and keep it stable, we should learn from HTTP/2.
1) Make shared design docs on our wiki
We haven't had shared design for HTTP/2, and I think it led unorganized
messy code. Having shared high-level design docs will help understanding
the overview and will keep people on the same page, and it will prevent
introducing code (especially flags) which is understood *correctly* only by
the author.
2) Make ToDo List on GitHub with issues and project
I thought we've already had all features of HTTP/2 but we had not. It's not
healthy that only few people *know* what we have to do. Making feature list
will help people joining development, and it will be useful to track what
is / isn't going on.
3) Make QUIC branches
One huge patch won't be reviewed. We couldn't find super easy mistakes.
Adding features one by one on branches will keep changes small and
reviewable. Also, we will need to maintain at least two branches for QUIC.
One for development and one for interop. The branch names will be "quic"
and "quic-draft{draft number}".
4) TDD (Write test first)
HTTP/2 implementation was broken several times. It didn't work well on 7.0.
Because we don't have enough tests for HTTP/2, we didn't notice breakage
even if some fix actually affect HTTP/2. Although we haven't decided how we
introduce TDD, I'd like to propose that people try to write tests first. I
understand that it's difficult in some area, so it won't be acceptance
criteria, but we should try. It will clarify the responsibility of the
class or component, and make it solid.
Any comments and suggestions are welcome.
Thanks,
Masakazu
