A new home for Europa
Michael J Iatauro
to GitHub, and I'd like to get as much input as I can before I start committing to it
(version control puns!). The big motivation is something I'm actually not supposed to
know, but it has a lot of benefits, as far as I can see:
* All the goodness of git. (All the badness, too.)
* Better CI capabilities (Javier's had a ticket in for Google Code for years about
continuous integration. There are already at least two sites that I know of that offer
free CI for GitHub.)
* Code review tools
* There's an existing NASA organization on GitHub, so Europa will get listed alongside
other NASA open source projects, including ones that can use Europa, like OpenSPIFe.
* Real markdown wiki rather than Google Code's "special" wiki format.
So, please comment away! Is this a good idea? Is there somewhere else you think would be
better?
~MJI
--
------------------
Michael J. Iatauro
Software Engineer
QTS, Inc.
NASA Ames Research Center
Office: 650-604-0662
Mail stop: 269-2
P.O. Box 1
Moffett Field, CA 94035-0001
Conor McGann
--
You received this message because you are subscribed to the Google Groups "europa-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to europa-users+unsubscribe@googlegroups.com.
To post to this group, send email to europa...@googlegroups.com.
Visit this group at http://groups.google.com/group/europa-users.
For more options, visit https://groups.google.com/d/optout.
Javier Barreiro
--
You received this message because you are subscribed to the Google Groups "europa-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to europa-dev+unsubscribe@googlegroups.com.
To post to this group, send email to europ...@googlegroups.com.
Visit this group at http://groups.google.com/group/europa-dev.
Simon Spero
BLUF:
🐙🐱🐙
(Octocat happy dance).
Github is much better than Google code. The primary thing missing are mailing lists; several projects I work on I use still use old source forge mailing lists, or Google groups (hmm...)
If there's already a substantial NASA presence on github, then that is a good reason for going with it. I've found it painful to try and find which NASA planners are available and in active development.
Before committing to the choice, you should also take a look at bitbucket, which offers comparable features but has different strengths and weaknesses.
1. Github has a wider user base, so the web interface is more familiar. There are quirks but they may already have been hit. Bitbucket adds a small learning curve for github users (I made my first pull request backwards).
2. Github only supports git; bitbucket supports git and mercurial. There are minor tradeoffs between the two - atlassian had two advocacy blog posts:
http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/
http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/
3. Github issue tracking is not very feature rich but is relatively easy to use for what it can do.
Bitbucket has a native issue tracker that is a bit more sophisticated, but still simplified
Bitbucket and Github can connect to JIRA (and other issue trackers). Since bitbucket is owned by atlassian, JIRA support can be a bit better for bitbucket.
4. Github has more plugin services for CI available. Travis is github only, is really nicely integrated and easy to set up. Drone works with both systems.
It's easy to set things up on both systems to use local build systems instead of waiting for the cloud.
5. Both systems offer static web site hosting. This can be on a per project as well as per account basis.
6. Bitbucket has better built in visualizations, but both systems can be integrated with more powerful reporting systems.
This can be very useful information to give to funding agencies.
Bitbucket allows for issues to be voted for, making it easier to prioritize fixes and new features (but external agile tools for both can do more).
7. Both systems have a glaring weakness in how repositories are organized, and lack good discovery tools.
It is possible to build static catalogs by adding metadata to projects, and writing code to generate pages using this; however this requires creating an external service, and suffers from the big disadvantage of static pages, which is that they are, well , static.
Unless all project metadata is transferred to the client, and all search processing, faceting, and subsumption is done in Javascript, the sort of discovery that is possible is very restricted.
The PDF NASA software catalog is not readily usable, and <http://code.nasa.gov> is partial (and is also static.
Simon
--
You received this message because you are subscribed to the Google Groups "europa-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to europa-users+unsubscribe@googlegroups.com.
To post to this group, send email to europa...@googlegroups.com.
Visit this group at http://groups.google.com/group/europa-users.