Public source code repository

[georg.viehoever]

I was wondering if you are interested in setting up a shared code repository for community developed modules and scripts. From my experience with GradientsMergeMosaic and CanonBandingReduction I would expect this to make collaboration much easier. Key points to consider:

-Would this be an interesting mode of operation for PI developers, or do you prefer to work in private?
-Which of the existing options (git, svn,...) would find most acceptance? I have had a lot of exposure to systems such as RCS, ClearCase, Perforce, ... . My impression is that git/github should work nicely for community type development, but I have no practical experience with it.
-How to organise source code (directory structure), branches (trunk, development, release, private variants), and permissions?

I would be willing to contribute "my" modules as a starting point.

Georg

[Nocturnal]

I have thought for a while that a source repository would make sense and not just for open code. Code for the debayer module wasn't open but I still had to collaborate with Juan on it. Later Zbynek volunteered to add more functionality.

The ideal repository would have configurable share levels. Some code can remain closed except for certain users, other code is publicly viewable.

I'd prefer SVN over git but either would be fine.

I think I brought this up with Juan a long time ago but maybe that was just in my mind.

[Juan Conejero]

Hi,

The next version 2.0 of PCL will be 100% open-source under PCL License 1.0. We plan on creating an online source code management system for PCL on endor.uv.es, or perhaps on a subdomain of pixinsight.com. Irrespective of where we'll be hosting this service, it will be a reality during the next Winter.

I think that both open-source and closed-source modules should be part of the same PCL source code repository. I am not sure about the best version control system to use. Centralized (SVN)? Distributed (GIT, Mercurial, ...)? Opinions?

[Nocturnal]

Sounds good Juan. I prefer SVN because it's more like 'classic' source control but maybe that just dates me. I tried Git at home for my projects and didn't find it very intuitive. Ultimately I don't really care and will use whatever.

[bitli]

This would be a good idea.

I use bitbucket.org for my projects, with Mercurial. 

• Bitbucket because it allows private projects (I personally prefer to have them private during an initial development and make them public when I want),. To my knowledge GitHub does not have that option (for free).
  
• Mercurial because I work mostly (but not uniquely) on Windows and Mercurial is IMHO more intuitive and simpler to use on Windows than Git.  Or at least was at the time I selected it. I am an old chap used to svn, perforce, etc... but I found Mercurial (and Git) much better, especially for community work.
  

However I am perfectly happy using whatever will be provided.

The 'community' tools (facilities to clone projects, look at sources with browser, etc...) may be very useful, so a site like GitHub or bitbucket would be preferable than a raw repository.

Naturally it is also possible that Juan write a new source control system integrated in PI - just kidding  (I hope).

-- bitli

[Nocturnal]

Naturally it is also possible that Juan write a new source control system integrated in PI - just kidding  (I hope).

Oh it'll happen.

[kwiechen]

yes, this will make contribution much easier.

Kai

[georg.viehoever]

I think it would be a good idea to use existing services like GitHub instead of setting up a repository managed by the PI team. Not only would it allow the PI team to focus on PI instead of managing a source code repository. Services such as GitHub provide additional features such as management of permissions, issue trackers, preconfigured toolsets, backup, ... . The danger of vendor lock-in is also limited, as several open source projects moving between BitBucket, GoogleCode, SVN, ... (in all directions) have demonstrated.

Having both a public and a private repository is possible with all service providers I know. So this is not a compelling reason for a service provided by the PI team.

I would like to have a repository that I can also use offline. The reason for this: I do most of the development work during vacations, and I tend to be in places without internet then...

But a thing i would really like to see from the PI team is a build-service that would build PCL modules for all PI supported platform. I think most of us dont have Windows+Linux+FreeBSD+MacOs available at home. So this would be something useful that only the PI team can provide.

Georg

[Nocturnal]

But a thing i would really like to see from the PI team is a build-service that would build PCL modules for all PI supported platform. I think most of us dont have Windows+Linux+FreeBSD+MacOs available at home. So this would be something useful that only the PI team can provide.

Yeah. I think I proposed that a while back along with the optional payment model that flew like a lead balloon :-)

The cross-platformness of PI is great but it makes it hard to contribute PCL code while maintaining control or IP.

[bitli]

Hi,
I opened my project https://bitbucket.org/bitli/varyparams as an example
of project on a public repository - it is on BitBucket and uses Mercurial
(it just happens to be so, other tools and provider works well too).

Regarding the common repository:
Finaly I do not think that we need a single central repository for the
scripts and other small contributions (for PCL this is another question).
We should stick with the distributed model and use some standard hosting.
This avoid central management and code is much easier to fork, especially orphan code.

Obviously it is simpler if most contributors use the same tools and service (
this limit the number of tools  to learn and service to have a account with).
Practically only git and mercurial compete as a tool.
There are plenty of tutorial on how to use them. If you just develop or update a projets (as
are most scripts), they are very simple to use - you can get by with about 5 commands.

May be the frequent contributors could state their preferences and the willing ones
will use the same repository?

The repository address should be mentionned in the script and the announcement in the forum.

Regarding the standard project layout:
On my projects I used the following structure:
 

Code: [Select]

  .../sources/             (under source code management)
   .../sources/main         (all the stuff used to build a release)
   .../sources/main/js
   .../sources/main/doc
   .../sources/test          (all the stuff used for testing)
   .../sources/test/js
   .../sources/test/project
   .../sources/tools/js     (tools, like a script to build a release)
   .../releases             (not under source code management - may be should be too)   
You can look at VaryParams to see if this suits you. This is more complex than
the 'one file at root' generally used, but I found quite a few benefits even for
relatively small projects:
   - The source files are split by functionality and are are easier to read and test
   - The test scripts can test non GUI functions automatically and do not clutter the final script
   - I have a test GUI driver that allows playing with the GUI without doing actions.
   - The data for the tests (including a small PI projects) are available and allow repeatable tests
   - The tools contains a small program that assemble the source files in a single
     file, so end users have just one file to install.

This may be an overkill for very small scripts, but it proved very useful if the scripts
is somewhat complex and you come back to it after a few months.
     
-- bitli