On Thu, Apr 14, 2016 at 01:46:35PM +0100, Alex Bligh wrote: > I have a proposal for the more efficient treatment of experimental > protocol extensions. This primarily concerns doc/proto.md, but > potentially affects code too. > > At present the experimental protocol extensions are described in > 'experimental extensions' at the bottom of the document in master. > This causes some issues: > > * The document is longer for those that don't want to read about > protocol extensions. > > * The document is more volatile than it might be, as each change > to an experimental extension requires a change to proto.md > and these carry a high risk of conflict. > > * The body of the document inevitably ends up referring to > the experimental extensions, which is a pain, as you only > should need to know about the experimental extensions if you > implement them. > > * Worst of all, after all the careful wordsmithing of experimental > extensions, they then need to be promoted into the main document, > (when they cease to be experimental) which requires more wordsmithing. Yeah, I realize that now. > My proposal is as follows: > > * Experimental extensions do not appear in proto.md in master at all > EXCEPT for reservation of codes (e.g. "NBD_OPT_FOOBAR (42) - reserved > for experimental FOOBAR extension"). > > * Experimental extensions themselves live in a git branch. This carries > the wording of the extension as it would be if it were incorporated > in to the main document. Part of the change set removes the > above text and says "NBD_OPT_FOOBAR (42) - see FOOBAR" or descibes > it in place). > > * The text re NBD_OPT_FOOBAR above has a link in proto.md (in master) > to the relevant branch's proto.md, so you can simply click through > to find it. > > * Merging (and thus promoting to non-experimental) an extension is > as simple as merging the branches. > > * The extension branches could then also contain code to implement > the extension on nbd-server.c and nbd-client.c as appropriate. > > * This means the documentation for an experimental feature and the > code to implement it can be kept together, and can be merged easily. > This should reduce proposed changes to master's proto.md, and > it means resolving conflicts is the job of those writing the > extension (i.e. they need to effectively rebase their patches > on master). This sounds like a viable approach, except that currently I'm still the only person able to merge patches, which means I get to be a bottleneck all the time. Not ideal. Maybe I should fix that. Alex: according to github, you've made the second-highest number of commits to nbd. That, plus your actions on this mailinglist mean you've been annoying me enough to be punished for it. Consider yourself a committer ;-) (I'll also add you to the sourceforge project if you have an account there and tell me what it is...) -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Attachment:
signature.asc
Description: PGP signature