El 02/11/11 12:08, anatoly techtonik escribió:
On Wednesday, November 2, 2011 6:26:22 PM UTC+3, Carlos Córdoba wrote:
Now that we have 2.1 out of the door (thanks all for your hard
work!) I
think we could discuss an issue I've been thinking for quite some
time:
a move to Github. (It's not possible to move to Bitbucket, because
its
Issues API issues is too limited and won't let us import our issues)
Considering GitHub issue tracker:
1. I don't like issue tracker from GitHub either
2. BB has an API for creating issues, so it's not true that it won't let
http://confluence.atlassian.com/display/BITBUCKET/Issues
3. You need to find a way to auto-fill issue field when reporting them
from Spyder menu like it currently works for Google Code
About 1.: it has improved a lot in the last few months. I'd say now it's
similar to the googlecode one.
I knew about 2. but BB API won't let us import the issue comments, and
that's a big drawback for us. You're right about 3. though.
If you start with features of Google Code that are better than GitHub
and BitBucket, you will have a full picture of the trade-offs. I can
say from my experience that premature move may do more harm than good
and moving to GitHub or BitBucket doesn't necessarily increase
contributions.
I mentioned new contributors from what I've seen from ipython, which has
received good contributions from the community. As I said, most python
scientific projects are in github, so probably most people interested in
their development are in github too.
First, let me say it loudly: I *don't* like git. I find mercurial
easier
and more intuitive than git. But, on the other hand, Github has quite
some good features compared to googlecode:
I don't like Git either, and I must say that for me it is not a
sufficient reason to move to GitHub. I am using it for PySide and
submitted occasional pull requests for different projects, and must
say that even with GitHub it is still not perfect. Git is much harder
to start than Mercurial, and its command names are not as intuitive as
Mercurial.
Totally agree!!
1. It's pull request system. Now that there are three or four of us
working regularly on Spyder, I think it would be better that everyone
could check the changes others made, before committing to the main
tree.
This would improve code quality and we could also discuss
implementation
issues more deeply and work on them in personal branches instead of
adding partial of half baked things to the tree.
This is a matter of proper code review culture. I use
http://codereview.appspot.com which has a lot more potential than
GitHub review system, not only just because it is open source, but
also because it is not Git specific. In Rietveld, which powers
codereview.appspot.com we require that all, even the most simple
commits should be reviewed before commit. The same tool is used for
Chromium code reviews, and it would be nice to see this integrated
into Spyder.
I'd like to see some examples of working workflow with deep
discussions and the stuff that improves code quality at GitHub first.
I've heard about Rietveld but didn't know how to integrate it with our
workflow. It could be good to investigate it then.
2. Github pages. Github lets its users to upload static web pages as
special repo branches. This would give us the possibility to create a
pretty good looking website for Spyder based on Sphinx, that
anyone in
the project could improve and update at will.
Google Code serves static web pages directly from repository. For example:
http://liten.googlecode.com/hg/docs/liten_documentation.html
I know, but in Github the page can be accessed more easily, as if it
were hosted in the old geocities or something.
If you want to base website on Sphinx, GitHub won't regenerate static
pages for you automatically, so it won't be as convenient for anyone
in the project to improve and update it at will as it is currently
with the wiki. I think that Spyder's usage of Google Code wiki is awesome.
Github *do* regenerate the pages automatically after you push. I know it
for a fact because I'm hosting some notes in there.
3. Most python scientific projects are now on Github (IPython,
matplotlib, numpy, scipy, enthought), so this could improve cross
collaboration and probably it could attract more contributors.
I would say otherwise - probably is won't attract more contributors.
If you like to improve a project - you just need an easy way to make
your contribution, get review and improve it - although trendy sites
like GitHub help with that - you need to know exactly - where can they
help you and if it really worth sacrificing things you already have.
Those are my main points. What do you think?
1. Migrations are bad. At SCons the development is halted for I
believe more than two months already, because nobody has the time to
complete (or learn how to complete) the migration
2. I am more from development camp than from scientific, so prefer to
work on my own development tools for features like code reviews and
source control than to use services like GitHub that force me into
using tools I don't like
About 1., we could migrate in the background and make the switch when
everything is ready. if it's too hard, we could simply abandon it.
You're right about 2., and we don't want to loose you as a contributor,
so we're +2 and -1.
--
You received this message because you are subscribed to the Google
Groups "spyder" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/spyderlib/-/CGHDWW0nqGcJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/spyderlib?hl=en.
--
You received this message because you are subscribed to the Google Groups
"spyder" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/spyderlib?hl=en.
