Re: [Nbd] Starting over?

[Tuomas Räsänen <tuomasjjrasanen@...1261...>]

On Tue, May 05, 2015 at 10:03:44AM +0200, Wouter Verhelst wrote:
> Hi all,
> 

Hi

> The recent issues with nbd-server 3.10 (and something else that I still
> need to work on -- sorry Tuomas) 

No problem.

> have convinced me that perhaps the
> braindeadedness of nbd-server is too bad to continue as is, and that it
> is time to start over. I've always tried to avoid a reimplementation,
> because I wasn't convinced that it would improve the situation, but I
> can't ignore the existing issues anymore.
> 

Well, I agree, there have been and there still are issues. No doubt.

> Also, the lack of other people helping out with the source base have
> held me back in that area; but perhaps this lack of interest is mainly
> due to the fact that the code is so badly readable...?

Actually, the bad smell around the code was one of the reasons I got interested
in helping out about two years ago. Careful refactoring, step-by-step, is quite
satisfactory, am I the only village idiot getting kicks from fixing smelly
C-code (and wearing black leather programming gloves)?

> 
> There have been a few (abortive) attempts at modifying the internal
> architecture of nbd-server (the most recent of which is the
> io_transaction branch), but I realize now that these can't really do
> what is needed to get things back into a manageable state.

What would be a manageable state?

> 
> So, I think it's (well past) time to throw out the old code base and
> start anew.

I'm not sure if I see the situation that bad/hopeless. Yes, the code base is
still ugly and it makes it difficult to develop new features, but at the same
time, I think the code base is quite well battle-tested. And it is actually
quite small too, only ~3500 sloc.

You have done a great job in increasing the test coverage, which, in my opinion,
is one of the keys for achieving a manageable state.

I think backward-compatibility is the top priority in this kind of project, not
only regarding the protocol, but also the usage/invocation of the program.

As I see it, rewriting everything from scratch would require much more work than
fixing the current code incrementally. At least the rewrite work would need to
be done in "a big lump", outside the production line, and at the same time one
would need to maintain the production version, handle incoming patches, rework
those to match the new code base, etc. I just don't think we have enough
man-power for that.

> 
> Before I plunge myself in there, though, I'd like to know if anyone is
> interested in helping out with that. I do think I can get it done myself
> if needed, but it's always useful to at least have someone with a second
> opinion, so that I can be corrected when I'm about to make a mistake. If
> anything, the fact that the current codebase is... not so good, is
> probably because of the lack of that, currently.
> 
> Any takers?
> 

I'm willing to help, but I'm not sure if throwing out the current code base and
rewriting everything is the right way to go. We do not have any full-time
developers around. To me, fixing the current code base seems easier task,
because

 1) it has a clear focus: get rid of the smell, preserve the functionality

 2) it can be done in small incremental steps

 3) it probably makes it easier to take care of the backward compatibility

I hope others will join this conversation and share their thoughts too.

Currently, I think going with a incremental model would be better, but if we
decide to go for a rewrite, I'm willing to help in that endeavor too.

-- 
Tuomas