[Box Backup] Future development plan

[Martin Ebourne]

On Thu, 2005-08-18 at 11:25 +0100, Ben Summers wrote:
> I propose:
> 
> * Set up SVN repository. Import 0.09 + my minor modifications
> 
> * Add in the following code in branches:
>      - Win32 port (Nick)
>      - Solaris port (Martin)
>      - Autoconf, 64 bit stuff, etc (LinuxOnPower) (Martin)
>      - Optimised diffing (Jonathan)
>      - (anything I've forgotten?)
> trying to keep different changes in different branches.

I would be happy to make my branch (and maybe a separate one for the
autoconf stuff) and import the patches myself.

> * In each of the branches, check
>      - Code quality
>      - Code style
>      - Functionality / tests passing
> 
> * Merge into the main branch

When we get to this point we should all take a look at the branches and
have a discussion as to order of merging to try and make life easier.

> * Release to users for testing
> 
> * Release 0.10
> 
> * Agree procedure for design changes and coding amongst developers
> 
> * Write up design documents for new version
> 
> * Get coding!

Sounds like a top plan.


> Questions we need to answer:
> 
> * Are all the contributors happy with this plan?

Ack.

> * Has everyone got enough time to get this done?

I can find enough time to merge all my stuff in and support bug fixing
etc. As to ongoing development it'll depend on how much I want a feature
vs. the work I'm doing on other projects. I don't even need to say I've
got limited time, because so has everyone else. ;)

> * Will people put up with my insistence on the style of the code  
> being consistent?

Yes, and would encourage you to be moderately pedantic on that one. I've
tried quite hard with mine to match your formatting style at least.

The only thing I would like to add here is I think that experience has
shown that with projects worked on by multiple people using tabs in
source code causes endless trouble, especially if not set to the default
8 spaces. It would be worth considering expanding all the tabs to spaces
at whatever tab-stop you like and not accepting tabs from then on. But
only after we've merged all the current streams of course!

> * Where should the SVN repository live? (Sourceforge don't provide  
> one, but there are a few "free" providers listed. I might set up a  
> repository on one of my servers, however.)

You'd probably be ok with a repository on one of your servers. SVN
itself is very low maintenance (with the now default fsfs backend), but
you do need to run apache to get webdav, which is preferred.  Unlike
CVS, SVN keeps local copies of the untouched files in the working copy
and hence makes a lot less roundtrips to the server. The server is
mainly used for updating so is low traffic.

I have a SVN server with box already in it, and I don't mind opening
that up to general access if it helps. It's backed up off site (using
box of course). Having said that, in the long run you'd probably be
better with your own.

> * What do we do about the license, and who holds the copyright?

Well you know I prefer GPL, mainly to prevent you/us getting ripped off
by some company closing the source, which has happened with a number of
open source projects.

Having said that, I've got nothing against BSD either, and am happy to
submit my changes under the BSD licence as before. The only thing I
would prefer is the 3-clause BSD licence as discussed previously, but
purely from the practical point of being more compatible with other
licences - eg. allowing shipping of binaries linked with readline, which
is otherwise an issue.

> I use the various libraries to build other private projects, and I'd  
> quite like to be able to bring changes into my own code. I have a  
> preference for the BSD license, because BSD licensed projects have  
> been so helpful to me in the past. But apart from that, I have no  
> strong feelings either way.

Me neither. If you stick with the current licence with your name on it
then that's fine by me, I think you deserve credit after all. :)

If you were to change the licence for box then I also don't mind giving
dual licence on any of the relevant code so you can continue to use that
for other projects.

Cheers,

Martin.