[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] More efficient treatment of experimental protocol extensions



Wouter et al,

On 14 Apr 2016, at 17:16, Alex Bligh <alex@...872...> wrote:

> On 14 Apr 2016, at 16:38, Wouter Verhelst <w@...112...> wrote:
> 
>>> 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,
> 
> I propose I come up with a patch to move the current experimental
> stuff out to a branch then.
> 
> As Erik currently is performing open heart surgery on NBD_OPT_INFO
> I'll leave it until the patient is in recovery before doing that one.
> 
> Structured replies is (famous last words) already in that state.
> 
> I haven't paid much attention to WRITE_ZEROES but I think that's
> relatively stable too. I'm guessing if we had a server side implementation
> of that we could promote it.

I've moved out WRITE_ZEROES on my own github account (so
we can all see what this looks like).

Branch 'separate-extensions' is what would end up in master,
and proto.md looks like this:
   https://github.com/abligh/nbd/blob/extension-write-zeroes/doc/proto.md

As you can see there is no mention of anything to do with WRITE_ZEROES
apart from reserving the bits with a link to the branch with the extension.
The link doesn't work as it's not on the official github server yet
(obviously).

Branch 'extension-write-zeroes' carries the extension, which is currently
a single patch putting the documentation in, plus my code patch for
a trivial implementation. I would push this to the *branch* on
the main repo. It obviously isn't yet ready for merge (as I haven't
tested the code even once), and this would be a precondition of
merging it to the main repo's master.

You can see the proto.md here:
   https://github.com/abligh/nbd/blob/extension-write-zeroes/doc/proto.md

As you can see WRITE_ZEREOS appears in it as a normal command etc
(not an option).

I've given HTTP links rather than a patch as the patch really isn't
very informative, but obviously I can send that if helpful.

I'm interested in confirmation that this approach works for people.
If so, I'll do the other two (hopefully merging Eric's existing
work on NBD_OPT_INFO first).

--
Alex Bligh




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Reply to: