On 8/27/14 3:50 AM, Frank Millman wrote:
"Ian Kelly" <ian.g.ke...@gmail.com> wrote in message
news:calwzidkro_hryamwxbk0go-w1oj6ty6myb_c5vhxb6okgol...@mail.gmail.com...
Ugh. There seems to be no public repository, and the only source to be
found is from release-versioned tarballs, so there's apparently no
collaboration other than some forums for reporting bugs and requesting
features. All the work is done by one developer in his spare time, and
he is currently on hiatus since April. Meanwhile the most recent
release is February, so it's not like somebody could just pick it up
and start hacking and expect to merge.
That's only open-source under the most literal of definitions.
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.
You don't need a "local hg repo", you just need a working tree. I
recommend choosing either hg or git, and then using BitBucket or Github,
and being done with it.
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?
Fossil is one of those technologies that is very attractive in and of
itself, but is so under-adopted that it will itself be a barrier to
collaboration. (Frankly, hg is getting to that category also.)
There is no test suite (shock, horror). I have not got my head around that
yet. The things that I could write tests for are so trivial that they don't
seem worth the effort, and the things that cause me problems are so complex,
because they depend on exactly what features have been activated, that the
permutations are endless and I don't know where to start. However, once it
is public, if someone is prepared to do a bit of mentoring, I will start to
fill the gap.
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. People might look at your repo and say, "ugh, this is
a mess, I'm not going to help here," but the alternative is them saying,
"there is no public repo, and therefore no project, ..."
Any other comments?
Frank Millman
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
