Since no objections have been raised, we'll start implementing QUIC with these. The design docs, GitHub project, branches will be announced later.
Although we haven't decided the official test framework, we are going to use TestBox for now because it doesn't require additional dependencies. This doesn't mean +1 on TestBox, and the tests will be migrated after we decide the official one. Thanks, Masakazu On Wed, May 24, 2017 at 5:42 AM, Masakazu Kitajo <[email protected]> wrote: > 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 > >
