On Wed, Aug 27, 2014 at 5:50 PM, Frank Millman <fr...@chagford.com> wrote: > > This is quite a timely message for me. I am inching closer to releasing a > version of my accounting software, and a lot of the above comments apply to > me as well. At present I am the only developer, and my project is not hosted > anywhere, so I have to decide how to make it available, and I am open to > suggestions. > > I have had two attempts at running an hg repository locally, and I am afraid > that I am not keeping it up to date. I do have a master copy, but I have > made so many changes in my clone that a merge will not make any sense, so I > will have to start afresh. I think that making it public will be the only > way that I can force myself to update it regularly.
Then you need to develop a new style of working, which plays more nicely with source control. Instead of hacking on whatever you feel like doing and then committing to source control later, make each change and immediately commit it. Get into the habit of putting useful commit messages onto your changes. As you say, making it public will help you force yourself to keep that up-to-date. > I could stick to hg (or git) but I have recently come across fossil, and it > seems ideal for my needs. Has anyone used it? It seems to have everything it > needs (a wiki and a ticketing system) for self-hosting, and I have my own > domain that I have not activated yet, so maybe I should just use fossil and > host it myself. Any comments? I haven't used fossil personally, but I'm not really a fan of all-in-one systems; they're somewhat inflexible. If you don't like the wiki, you're stuck with it. I'd rather work with all the parts separately - change one and it doesn't affect anything else. But if all fossil's parts suit you, then by all means, use it! > Documentation is a mess. I did start using Sphinx a while ago, so there is a > sprinkling of rest-format docstrings, but they have not been kept > up-to-date, and in some cases are out of date. There are plenty of other > comments in the code, mostly reminders to myself about various issues. I > don't know open-source etiquette. Should I spend the time to sort this out > before going public, or is it acceptable to leave it as is for now? Go public first, and watch what people get confused at - then document those parts. If you try to document everything first, you'll spend heaps of time and effort on it, and maybe won't even be happy with the result. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
