I think Andrew is just wrong about what people should be developing against. If you develop
against -next, then your changes won't be acceptable for inclusion in -next if there are
conflicts, because of the way -next is generated. If, for example, after you start working,
some series that was already in -next gets revised, your tree will now generate a slew of
conflicts in code you've never looked at, because you'll have Stephen merge all of that
particular old -next plus your series with the current -next when he pulls, and do it as if
the two -next versions were developed independently.
What would be more useful is to develop based on what -next bases on, but test the merge of
your code and -next, and make that merge available. That gets the development history clean
and clear, checks that integration with the rest of -next works, tests that the rest of -next
works for you, and also should allow git to get information on the proper merge with various
-next versions so that the integration is smoother.