MUSHclient source repository

Is there going to be an official repository for the MUSHclient source code? It might be nice to have something publicly accessible for being to get the most recent version of the "official" source. This would also take some burden off of you, Nick, for having to package and release source packages (if you intended on doing that in the first place).

A typical structure for such a thing, as far as I can tell from the OSS projects I have seen, is to have a central repository with one or more gatekeepers: people who are basically responsible for reviewing code and patches submitted by others. The gatekeepers are the only ones who have commit rights.

I would strongly suggest the use of distributed version control systems. Unlike CVS, it is extremely easy to branch and merge the code, which makes it much easier for developers to branch off a version, make some changes, and submit the difference to the central repository as a suggested patch. And the central repository itself can have several branches; one setup could be to have a stable branch and a development branch. The stable branch is essentially the most current "Release" version, and the development branch is the most up-to-date version being tested and/or worked on.

I have looked into such systems recently, and the two that stand out the most to me are Bazaar (bazaar-vcs.org) and Mercurial (www.selenic.com/mercurial). I ended up choosing Bazaar for my own work and so far it has been quite nice. The storage system for branches is really quite intelligent.

For example, I can have the stable/testing/other branches on a server, only storing the "core files" once, each branch storing its diffs, unlike CVS which has to store the whole file once per occurrence.



Furthermore, these distributed VCS systems for the most part do not require a special server to be running. CVS requires a cvs-pserver if you do not want to give SSH access (which would be completely silly for a project like this). But Bazaar (and Mercurial and Darcs and a few others) let you "serve" the code as a simple HTTP address. So, if I want to get the code from you, the only thing you need to do is make the repository be www-accessible.



What are your thoughts on this Nick? I think there should be some kind of official MUSHclient repository if there is going to be active community development (which would of course be a very good thing). If you don't manage it yourself, it should be some kind of community effort, hopefully with your blessing. :-)

I have server space that can be volunteered towards a repository if need be.

I don't have a big problem with setting up a repository - that might make it easier to make changes in a controlled way.

I took a look at Bazaar, but can't see a reference there on how to set up the server. As far as I can see, the documetation describes the client end.

Can you point me in the right direction?

I might set up the repository on my web site, since that seems a logical place for it now - that is, if I can work out how to do it. :)

I've read a bit more, and it isn't clear what Bazaar is going to really achieve, apart from letting people get their own copies, which they already can do by downloading the .zip file.

To make updates, there is a "bzr push http://blah_blah" option, but the needs sftp access to the web server, which would mean giving out the password to my web site, which I don't plan to do.

An example for setting up server-side can be found here:
http://bazaar-vcs.org/SharedRepositoryTutorial

What I did was something like this:




The advantage that a DVCS provides over, say, CVS, isn't so much that people can push changes to you. (However, these VCSs also provide extremely nice patch-by-email type setups.) The reason it's so nice is that I can set up my own repository based on yours, regularly pull your changes, and serve it as my own -- and people can branch from mine and yours at the same time if they choose to do so. And if two people branch, it's very easy to make a third branch combining the two changes.

Even if the distributed nature isn't a selling point for you, there's also the fact that CVS as a technology is getting quite old and there are a number of issues with it. (Its branching support, in particular, is frankly quite awful.) I would suggest at the least something like Subversion, but Subversion inherits a lot of CVS's flaws by trying to be "just like CVS" in many aspects.



If the source in the zip file is going to remain static, as-is, then yes, there is no point in setting up a repository. (Even so, as I said previously, a repository where bug fixes are committed saves you the trouble of having to package and release the source.)

However, if there is going to be any kind of active community development, there really, really should be some kind of central repository, and also there should be clear leadership on the project. I guess my question is not only to you but to the community in general; if people seriously intend on further developing the program, there should be some thought into how to go about doing it and organizing the effort.

I certainly have no objection to a repository, and indeed couldn't stop you from doing it if I wanted to. ;)

Since you are used to using it perhaps it is a good idea for you (or members of the active MUSHclient community, by mutual agreement), to set up and maintain such a thing.

Already Zeno has identified some minor compiling issues with compiling under .NET, and a possible 200 or so warnings that could usefully be eliminated.

Maybe different people could modify different things, for example:

• Improved configuration screens
  
• More script functions
  
• Email editor (like Linda wanted)
  
• Thesaurus
  
• Improved spell checker interface
  
• Improved (colour) notepad
  
• Improved handling of global options (eg. remove from Registry)
  
• Database of MUDs

Most of these would be separate from each other, so different development branches could start up, which could be usefully merged back together with little clashing.

I suppose from my point of view doing all this myself would have been a lot of work. Splitting it up between enthusiastic developers in pieces could make it a more achievable target.

I could still give advice where requested. Sometimes my attitude has been "that's too much work for the return" - well if someone wants to put the work in I won't stop them.

I still think you should be conscious of not letting the client become too bloated, and also bear in mind the desire to keep it running reliably as far as possible.

I don't mind setting up and maintaining the repository. I'm not sure how much work I could put into actually writing code -- as you well know I am a little too busy with school for my current projects already. :-) However, maintaining a repository is quite simple.

What really needs to happen is that the community gets together and decides on some leadership for the new development. The nice thing regarding open source projects is that if people can't agree on a direction to pursue, they can always go their own ways.

Ideally, I think there should be one group that maintains a "cannon MUSHclient" -- something that is relatively close to the original in intent. Programs like Zeno's could fork off of this, taking patches from upstream where appropriate but having his own client code. (This is another area where distributed version control is Really Cool.) This group would be essentially the "official open source MUSHclient".

As I said, I would be happy to host a repository. I could also host an issue tracking system. I'm not sure how much code I could write myself -- just digesting the whole thing is quite a task unto itself -- but I've maintained several of these for myself so it would be quite easy to do another.