Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-28 Thread Frank Millman

Chris Angelico ros...@gmail.com wrote in message 
news:captjjmp_jfxth_l6us30gbotmbyhw_imu-pjdglevgj2nut...@mail.gmail.com...
 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.


[...]


 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.


I *think* I have created a project on GitHub and uploaded my software there. 
It is called AccInABox.

This name probably needs a bit of explanation. Acc is an accountant. Box 
is the computer. You can set the system up with various rules and 
parameters, and then leave your staff to operate it without supervision. The 
program acts as your accountant, and will control what the staff can and 
cannot do.

At the last count, there are about 10 million things I still have to do 
before it is a working product. But the structure feels quite stable now, 
and you can do a few simple things with it, so I am ready for people to have 
a look and offer feedback.

I don't know GitHub at all, and I don't know what other information you 
need, so please let me know whether it works.

Frank



-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-28 Thread Chris Angelico
On Thu, Aug 28, 2014 at 11:44 PM, Frank Millman fr...@chagford.com wrote:
 I *think* I have created a project on GitHub and uploaded my software there.
 It is called AccInABox.

https://github.com/FrankMillman/AccInABox

Seems to be all there!

You seem to have a default README.md as well as your README that has
real content in it. If you delete README.md, the other one should
become visible on the main project page. I'll shoot through a PR for
that.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-27 Thread Frank Millman

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.

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?

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?

Any other comments?

Frank Millman



-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-27 Thread Chris Angelico
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


Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-27 Thread Ned Batchelder

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


Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-27 Thread Rustom Mody
On Wednesday, August 27, 2014 5:24:40 PM UTC+5:30, Ned Batchelder wrote:
 On 8/27/14 3:50 AM, Frank Millman wrote:
  Ian Kelly  wrote in message
  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.)

Some plainspeak -- Nice!

In modern society we are part users, part masters.  It may be 99% user
1% master if one is super-intelligent versatile etc -- renaissance men.

For us more ordinary folk it is more like 99.99% vs 0.01%
Eg I dont know how to repair the car I drive, build the roads they run on,
a frigging clue about the intenals of the utilities (electricity/water...)
I consume etc.  Heck this is even true of computers -- the SMPS? the Disk?

Likewise versioning systems.
We need to use them. We dont need to master all the details and possibilities.

Git has won the battle -- maybe because of the mystique around the
name 'Torvalds', maybe for sound technical reasons. It doesn't matter.
If you have better things in your life than becoming a phd in versioning,
I'd say flow with the tide and switch to git
-- 
https://mail.python.org/mailman/listinfo/python-list


hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]

2014-08-27 Thread Ethan Furman

On 08/27/2014 10:29 AM, Rustom Mody wrote:


Git has won the battle


Good thing there's room for more than one technology.

I use hg because 1) python-dev uses hg; and 2) I understand the simple hg commands.  I find git confusing, and my main 
uses are commit, pull, update, an occasional merge, and a rare rollback -- not complicated stuff.


--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list


Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]

2014-08-27 Thread Ethan Furman

On 08/27/2014 11:51 AM, Skip Montanaro wrote:


 Thank God for StackOverflow. :-)


+1 QotW
--
https://mail.python.org/mailman/listinfo/python-list


Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]

2014-08-27 Thread Skip Montanaro
On Wed, Aug 27, 2014 at 1:26 PM, Ethan Furman et...@stoneleaf.us wrote:

 I use hg because 1) python-dev uses hg; and 2) I understand the simple hg
 commands.  I find git confusing, and my main uses are commit, pull, update,
 an occasional merge, and a rare rollback -- not complicated stuff.


The simple hg commands are generally not all that different (in my
limited experience) than the simple git commands, for some definition of
simple. Stuff like clone, init, push, pull, commit, the small number of
commands you use day in, day out. When you get beyond that simple core,
both are confusing to me. I think it all boils down to what you use most
often. At work they settled on git awhile ago, so I'm now comfortable with
the basics there, though I recently had a rather unpleasant first
experience with git rebase. Both hg (almost all of it for me) and git
(the stuff I don't regularly use) are like Perl: I need to consult the
documentation every step of the way. Thank God for StackOverflow. :-)

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-27 Thread Christian Gollwitzer

Am 27.08.14 09:50, schrieb Frank Millman:

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 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 indeed an impressive piece. It comes from Richard Hipp, the 
guy behind SQLite, and it's currently in use to manage the Tcl/Tk 
sources. If you want to do the hosting yourself, it can be a good choice.


I myself decided not to use it, but instead use git with github. The 
reasons:


- github offers much more than plain git; you can host a website in the 
repo, included is a (rudimentary) templating engine, which allows to 
write your docs in simple markdown [*]


- the github frontpage makes it easier to download a tarball of the 
project. In the fossil website it's quite hard to find


- github gives the server storage for free to open source projects

- there is a social network - anybody who wants to contribute, can 
send you pull requests via github


- For large projects, git is much faster than fossil to update the repo.

The good news: you can migrate from fossil to git; e.g. the tcl/tk repos 
are mirrored to github. For fossil, there is also public storage space 
e.g. on chiselapp.com as an alternative


Christian

[*] in case you are curious, this is the website of my repo:
http://auriocus.github.io/VecTcl/
The content is all done in markdown, including math and syntax 
highlighting, and the template was adopted from one of the designs 
offered from github

--
https://mail.python.org/mailman/listinfo/python-list


Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]

2014-08-27 Thread Chris Angelico
On Thu, Aug 28, 2014 at 4:51 AM, Skip Montanaro s...@pobox.com wrote:
 The simple hg commands are generally not all that different (in my limited
 experience) than the simple git commands, for some definition of simple.
 Stuff like clone, init, push, pull, commit, the small number of commands you
 use day in, day out. When you get beyond that simple core, both are
 confusing to me. I think it all boils down to what you use most often. At
 work they settled on git awhile ago, so I'm now comfortable with the basics
 there, though I recently had a rather unpleasant first experience with git
 rebase. Both hg (almost all of it for me) and git (the stuff I don't
 regularly use) are like Perl: I need to consult the documentation every step
 of the way. Thank God for StackOverflow. :-)

+1. And most importantly: Use source control even though you don't
understand all the ins and outs of the one you're using, because you
can always get help when something goes wrong. I got my family (mostly
non-technical people, or technical people from decades ago - my dad's
been in computing since before I was born, but he doesn't know most of
the modern tools) to use a git repo instead of a shared directory,
basically by giving them very clear and simple instructions: git pull
--rebase to see other people's changes, git add when you create a
new file, git commit -a to record your changes, git push to send
the changes to the central server. (Yes, I know git doesn't need a
central server. It's still much simpler to describe it all that way.)
If anything goes wrong, they call me for help. They don't need to
understand about the myriad ways to call on git log, they don't need
to worry about bisecting, they don't even need to branch/merge... and
git happily runs for them, every single day. The simple hg/git
commands will get you through a pretty huge amount of coding.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list