Hi, 2012/1/7 Carlos Córdoba <[email protected]>: > Compare this to the Github way of doing things: > > 1. Commit messages can be seen as part of a pull request, others can add > inline comments/suggestions to each commit diff, and the pull request > author can add more commits in the same pull request to improve his/her > contribution because of the review. > > 2. Every developer or potential contributor only needs to do *one* clone > of the project's repo. Then he only needs to create branches in his > local copy and push them to Github to ask for a pull request. > > Even if the move to Github doesn't attract more contributors, I think it > will really improve our code quality and testing because we will be more > aware of what other devs are trying to do and maybe we could easily > avoid things like Issues 740, 863 or 880, which required more testing > and communication between us.
This will be a great improvement indeed. Furthermore, if I remember correctly, github also allows to setup a real website without any imposed frame. > During these vacations I reserved the 'spyder-ide' organization in > Github, and converted our hg repo to git without problems (unfortunately > revision references will be lost). The only thing left to do is to move > our issues, which I haven't had time to even try. Maybe there is a way to convert a Mercurial repository to a git repository with an automatic replacement of revision numbers in commit messages? (from a programming point of view, it seems pretty much doable) Anyway, I agree with your conclusion and I would gladly move to git even if I prefer Mercurial for other reasons as I mentioned earlier in this thread. Thanks for looking at this. -Pierre > Cheers, > Carlos > > El 03/11/11 04:42, Pierre Raybaut escribió: >> Anatoly, Carlos, >> >> In this matter, I'm quite neutral. >> After reading carefully your last emails, I think that the best would >> be to investigate the "Rietveld" reviewing system (although I do not >> quite understand exactly what it is yet: I did not take the time to >> dig further) before even thinking of moving from GoogleCode to GitHub >> (I'm not convinced that it would increase contributions anyway). >> >> Thanks for this interesting discussion. >> -Pierre >> >> 2011/11/3 anatoly techtonik<[email protected]>: >>> 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. >>> > > -- > 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. > -- 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.
