On Wednesday, November 2, 2011 8:32:56 PM UTC+3, Carlos Córdoba wrote: > > 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 am afraid this comparison is not scientific. =) A good place to start would be to copy this page - http://scons.org/wiki/DVCSMigration/HostingSites - over to Python Wiki. > 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. > To me the reason IPython receives good contributions, is IPython itself. I'd really like to see some objective stats to see how contribution increase rate differed after new IPython releases before and after move to GitHub. AFAIK IPython used Launchpad before, and Google Code is not a Launchpad. As for scientific projects I use only PyPy and it is hosted on BitBucket. BTW, it would be nice to see if we can run Spyder on PyPy and use Spyder for PyPy development. I'm sure everybody will appreciate non-web-based JitViewer plugin http://morepypy.blogspot.com/2011/08/visualization-of-jitted-code.html > 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. > There is a http://code.google.com/p/rietveld/wiki/CodeReviewHelp - feel free to propose your edits if explanations are too bloated or not to the point. I feel like Rietveld needs a separate GettingStarted page with simple example. I think that it may even worth to record a screencast for that. > 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. > Thankfully, docs URL is not the top priority: http://code.google.com/p/spyderlib/issues/list?can=2&q=&sort=-stars&colspec=ID%20Cat%20Type%20Status%20Priority%20Stars%20Milestone%20Owner%20Summary > > 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. > Wow. Good to know. That's something I didn't expect from the project written on ruby on rails. =) However, as the generated docs should be in a separate repository for this to work, this adds hassle of updating two repositories when working with the code. http://ipython.org/ipython-doc/dev/development/doc_guide.html#building-and-uploading > 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. > Execute migration to convert repository is not hard. The amount of work to fix things you have no idea about is several times greater. For SCons we have a problem with too big repository size, because of committed binaries. And too much branches/tags. And we are not yet at the point to see how much code in development scripts we need to rewrite. > You're right about 2., and we don't want to loose you as a contributor, so > we're +2 and -1. > > I am certainly not ready yet, but as I am not contributing much to Spyder core, I wouldn't call myself a 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/-/yRTbrDl5NDkJ. 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.
