A possible move to Github?
Carlos Córdoba
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)
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:
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.
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.
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.
Those are my main points. What do you think?
Carlos
Pierre Raybaut
As I am mainly working on Windows, I tend to prefer Mercurial to git
also because the first one is very well integrated to the system
thanks to TortoiseHg (TortoiseGit seems far less clean/light and more
invasive). But, I'm quite seduced by git features regarding history
editing and pull requests.
So I think that it's a good idea anyway.
Let's do it! ;-)
-Pierre
> --
> You received this message because you are subscribed to the Google Groups "spyder" group.
> To post to this group, send email to spyd...@googlegroups.com.
> To unsubscribe from this group, send email to spyderlib+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
>
anatoly techtonik
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)
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
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.
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:
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.
I'd like to see some examples of working workflow with deep discussions and the stuff that improves code quality at GitHub first.
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.
http://liten.googlecode.com/hg/docs/liten_documentation.html
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.
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.
Those are my main points. What do you think?
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
anatoly techtonik
Carlos Córdoba
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
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.
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.
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.
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
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.
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
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.
anatoly techtonik
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.
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.
Pierre Raybaut
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 <tech...@gmail.com>:
> --
> 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.
Peter Alexander
Carlos Córdoba
Despite the big delay in answering this thread, I've been considering
the issue quite carefully. I explored Rietveld/codereview and these are
my main objections:
1. Commit messages are not attached to the code review, so you can't
tell in what order the modifications to the tree were made and the
developer reasons to do them. The solution to this will be to create a
review for every commit and attach the message as part of the review
description. However this would be more work for us.
2. Another way to work will be to create a googlecode clone for every
fix/feature we want others to review, so that commit messages are made
public. But this has two drawbacks: 1. googlecode orders commits by
date, so others can't tell for sure what commits are the ones to be
reviewed (this happened to me in Issue 812); 2. You have to make a local
copy of the googlecode clone to add changes to it, which takes time and
bandwidth.
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.
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.
Cheers,
Carlos
El 03/11/11 04:42, Pierre Raybaut escribió:
Pierre Raybaut
2012/1/7 Carlos Córdoba <ccord...@gmail.com>:
> 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
Pierre Raybaut
and I also think that:
1. it will require some work: migrating issues and website
2. it will also cost some efforts: I personnally do only contribute/
develop/work with Mercurial repositories for now, so I'll have to
adapt to git (on Linux, this is not a problem but on Windows, this
means installing both TortoiseHg and TortoiseGit -- that is a problem
when working on some enterprise networks) and change some automation
script that I use for synchronizing things
3. we will loose some of GoogleCode advantages. One more login... I
like to use my Google account to log in once and for all... (yes, I'm
a lazy person :)) From a general point of view, I really like Google
websites: simple, efficient and fast. GoogleCode is following this
philosophy. On the contrary, I find github website very fuzzy/unclear:
there are dozen of links at each page, a real mess (at least this was
my impression when I first discovered this website a while ago).
Cheers,
-Pierre
Jed Ludlow
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.
I created a personal server-side clone of the default repository here:
http://code.google.com/r/jedludlow-spyderlib/
From there I created an example commit (added a sarcastic comment only, no real code changes, humor intended) and pushed it to my clone:
http://code.google.com/r/jedludlow-spyderlib/source/detail?r=2f5b59b6ced8020fbbf2f0cf555e2a32b25fc41a
and initiated a code review *within* Google Code itself. You have to enable this on your personal clone under the Adminster tab. It's actually quite nice. You can add line by line comments to the diff:
https://code.google.com/r/jedludlow-spyderlib/source/diff?spec=svn2f5b59b6ced8020fbbf2f0cf555e2a32b25fc41a&r=2f5b59b6ced8020fbbf2f0cf555e2a32b25fc41a&format=side&path=/bootstrap.py
The review can even be opened to non-project members if you enable this under the Administer tab. While they aren't specifically called "pull requests" in Google Code, a pull request is created by creating a new Issue and using the "Code Review" template. Here's the issue I created to match:
https://code.google.com/p/spyderlib/issues/detail?id=904
This should trigger a review and evaluation. If the change were accepted, someone with commit rights to the default repository would simply pull changes from this clone and merge them into the default repo.
Today, it looks like the majority of development is done directly in the default repo. A minor modification in the workflow would I think produce the result we are looking for without all the overhead of switching hosting and all the associated loss of history that would occur. If *all* developers were working from personal clones (and you really need only one because you can branch inside it and keep your clone trunk in sync with the default repo trunk) that had code review enabled, it would allow for all changes to be reviewed right in Google Code *before* being pushed to the default repo. There isn't any bandwidth hit because you don't need local copies of all the clones. Instead, those with default repo commit access simply point to whichever clone *on the server* that you need to pull from when you need to update the default repo.
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.
todd rme
> A minor modification in the workflow would I think produce the
> result we are looking for without all the overhead of switching hosting and
> all the associated loss of history that would occur.
Just to be clear, there is no reason there should be any loss of
history. There are tools to export mercurial repositories to git with
the full history maintained. See fast-export:
http://repo.or.cz/w/fast-export.git This tool is even recommened by
googlecode for converting googlecode mercural repos to googlecode git
repos.
It is also possible to use googlecode with git, but I don't know how
that compares to github.
-Todd
anatoly techtonik
Just to be clear, there is no reason there should be any loss of
history. There are tools to export mercurial repositories to git with
the full history maintained.
It is also possible to use googlecode with git, but I don't know how
that compares to github.
anatoly techtonik
Though, the thing that has kept me back from digging into the sources is the fact that mercurial is the VCS system. I try to stick with git as much I possibly can because of its power and its mostly ubiquitous. I know that hg is used more in the python community, but after having hurdled over the git learning curve I can't see my interest in anything else.
I'd love to be a participant developer for Spyder and making the switch you are contemplating would most certainly make it much more enticing. Spyder is, so far, a great IDE.. one that was greatly needed, especially for those of us who also dislike java products.
Jed Ludlow
Today, it looks like the majority of development is done directly in the default repo. A minor modification in the workflow would I think produce the result we are looking for without all the overhead of switching hosting and all the associated loss of history that would occur. If *all* developers were working from personal clones (and you really need only one because you can branch inside it and keep your clone trunk in sync with the default repo trunk) that had code review enabled, it would allow for all changes to be reviewed right in Google Code *before* being pushed to the default repo. There isn't any bandwidth hit because you don't need local copies of all the clones. Instead, those with default repo commit access simply point to whichever clone *on the server* that you need to pull from when you need to update the default repo.
Jed Ludlow
Today, it looks like the majority of development is done directly in the default repo. A minor modification in the workflow would I think produce the result we are looking for without all the overhead of switching hosting and all the associated loss of history that would occur. If *all* developers were working from personal clones (and you really need only one because you can branch inside it and keep your clone trunk in sync with the default repo trunk) that had code review enabled, it would allow for all changes to be reviewed right in Google Code *before* being pushed to the default repo. There isn't any bandwidth hit because you don't need local copies of all the clones. Instead, those with default repo commit access simply point to whichever clone *on the server* that you need to pull from when you need to update the default repo.A less radical modification to the current workflow would be to use named feature branches within the default repo for any major development that might require review. Then those with commit access could work the change together on the branch in the default repo and request code review before merging back to the default branch. Anyone without commit access can still pursue the personal clone approach then request review and pull by creating an Issue in the tracker. That lowers the admin overhead for the main contributors while providing a good, clean way for new contributors to provide code in a reviewable way.
After stewing on this some more, this latter branching approach might be preferable since it would tie the majority of the code reviews to commits in the *default project repository* as opposed to placing it in the personal clones, which can be deleted by the individual user at any time. Perhaps reviews in the clones would be a way to get a preliminary acceptance. If accepted, the changes could be pulled to a branch in the default repo where the complete review and refinement would take place, tied to the central project repository, prior to merge.
Carlos Córdoba
Thanks a lot for contributing to the discussion with a fresh approach and sorry for my big delay in answering. We should certainly agree on the best workflow for Spyder now that the development team is growing.
The main problem with using branches in mercurial (be them in personal clones or in the main repo) is that they become a permanent part of the repo history. So if we start to use them, in few months we could have dozens of branches in our history and they would certainly clutter the log, both using the googlecode web interface or tortoisehg. As you pointed out to Steve, I also think branches are used to maintain two different development trees (maintenance and next-release) inside the same repo, and probably for nothing else.
That's why mercurial devs invented a new kind of branching called "bookmarks" (which by the way are the real equivalent of git branches). Bookmarks are like branches but don't get recorded on history and can be easily deleted. Unfortunately, googlecode doesn't support them, at least to the best of my knowledge. I searched the support pages in vain and waited several months to see if they were to appear in the interface. That's why I finally suggested the move to github.
I really don't think googlecode or mercurial are "bad". It's just that they don't have a such polished interface to do reviewing as github. Believe me, if github were based on mercurial I would be really happy. But it's more important to acknowledge that reviewing would be very beneficial to the project. It could help to discuss changes and approaches between us without the fear to screw things up. It could also let us learn from the experience and knowledge of the rest. I think none of us knows the codebase as well as Pierre but the ones who know some parts better could help the others and viceversa.
I think all of us are eager to improve Spyder because is such a neat IDE and it's also pretty well written but we need better communication tools, and github seems to be the best alternative around for the task.
Cheers,
Carlos
El 10/01/12 10:56, Jed Ludlow escribió:
Today, it looks like the majority of development is done directly in the default repo. A minor modification in the workflow would I think produce the result we are looking for without all the overhead of switching hosting and all the associated loss of history that would occur. If *all* developers were working from personal clones (and you really need only one because you can branch inside it and keep your clone trunk in sync with the default repo trunk) that had code review enabled, it would allow for all changes to be reviewed right in Google Code *before* being pushed to the default repo. There isn't any bandwidth hit because you don't need local copies of all the clones. Instead, those with default repo commit access simply point to whichever clone *on the server* that you need to pull from when you need to update the default repo.
A less radical modification to the current workflow would be to use named feature branches within the default repo for any major development that might require review. Then those with commit access could work the change together on the branch in the default repo and request code review before merging back to the default branch. Anyone without commit access can still pursue the personal clone approach then request review and pull by creating an Issue in the tracker. That lowers the admin overhead for the main contributors while providing a good, clean way for new contributors to provide code in a reviewable way.
After stewing on this some more, this latter branching approach might be preferable since it would tie the majority of the code reviews to commits in the *default project repository* as opposed to placing it in the personal clones, which can be deleted by the individual user at any time. Perhaps reviews in the clones would be a way to get a preliminary acceptance. If accepted, the changes could be pulled to a branch in the default repo where the complete review and refinement would take place, tied to the central project repository, prior to merge.
--
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/-/wowOMAPVADkJ.
Carlos Córdoba
El 08/01/12 05:40, todd rme escribió:
> On Sun, Jan 8, 2012 at 8:18 AM, Jed Ludlow<jed.l...@gmail.com> wrote:
>> A minor modification in the workflow would I think produce the
>> result we are looking for without all the overhead of switching hosting and
>> all the associated loss of history that would occur.
> Just to be clear, there is no reason there should be any loss of
> history. There are tools to export mercurial repositories to git with
> the full history maintained. See fast-export:
> http://repo.or.cz/w/fast-export.git This tool is even recommened by
> googlecode for converting googlecode mercural repos to googlecode git
> repos.
I didn't want to say that we were at risk to loose *commits* in the
conversion. What we would loose are all *references to previous commits*
which we have written in several commit messages. Surely git uses a
different algorithm to create commit id's and that's why we would have
this problem.
But the good news is that we have very few commits which reference other
commits (around 40), so we wouldn't loose too much info. And of course
it would be better the sooner we do the switch.
> It is also possible to use googlecode with git, but I don't know how
> that compares to github.
The main benefit in the move to github would be the possibility to use
its pull request system to review the work of other developers and also
users who have found a simple fix. It's not because git is better than
mercurial.
> -Todd
>
Carlos Córdoba
El 07/01/12 13:14, Pierre Raybaut escribió:
I think issues can be migrated with this script:
https://github.com/cfinke/googlecode2github/blob/master/issue-transfer.py
although I haven't had time to check it.
For the website, well, I'm designing my personal site with Sphinx and I
think I could use the same templates to create a real Spyder site (which
would certainly improve our current situation, as we discussed in Issue 903)
> 2. it will also cost some efforts: I personnally do only contribute/
> develop/work with Mercurial repositories for now, so I'll have to
> adapt to git (on Linux, this is not a problem but on Windows, this
> means installing both TortoiseHg and TortoiseGit -- that is a problem
> when working on some enterprise networks) and change some automation
> script that I use for synchronizing things
You can still use mercurial to push changes to github, using hg-git:
I used it with tortoise-hg and it works well.
> 3. we will loose some of GoogleCode advantages. One more login... I
> like to use my Google account to log in once and for all... (yes, I'm
> a lazy person :)) From a general point of view, I really like Google
> websites: simple, efficient and fast. GoogleCode is following this
> philosophy. On the contrary, I find github website very fuzzy/unclear:
> there are dozen of links at each page, a real mess (at least this was
> my impression when I first discovered this website a while ago).
The design has improved a bit the last couple of months but I have to
agree with you on this one. Unfortunately github doesn't use OpenID so
that's another drawback, not only for you but also for our googlecode
issue reporters.
I guess no change comes without a bit of pain and discomfort, as I think
Goethe said ;-)
> Cheers,
> -Pierre
>
Jed Ludlow
The main problem with using branches in mercurial (be them in personal clones or in the main repo) is that they become a permanent part of the repo history. So if we start to use them, in few months we could have dozens of branches in our history and they would certainly clutter the log, both using the googlecode web interface or tortoisehg. As you pointed out to Steve, I also think branches are used to maintain two different development trees (maintenance and next-release) inside the same repo, and probably for nothing else.
In reality, the main Spyder repo shows branching all over the place. It's just being done anonymously rather than with specific named branches. Any time two devs commit changes from local repos that reference the the same parent Hg automatically branches for you. You resolve this by quickly merging, and the branch goes away. Named branches are just as simple to merge. You can simply close them to hide their names from the list of open branches.
The issue about named branches seems to be largely a matter of religion :). For every article decrying their use there is another praising their virtues. Ironically, in one of the most referenced articles on Hg branching, the author suggests named feature branches as one of his *preferred* methods of keeping track of what commits applied to what major feature:
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-with-named-branches
I tend to agree with him. I guess the difference between "clutter" and "clarity" is in the eye of the beholder.
I created a couple of named branches in my personal clone for simplicity in pointing the reviewer to the right change sets (like bookmarking), but this was by no means an attempt to advocate that every small bug fix should get a named branch in the main repo. Whoever does the "pulling" to the main repo from a clone can decide to pull in the branch name or simply create a patch so as not to propagate the named branch. On the contrary, I would only suggest named branches in the main repo for major features where destabilization and lots of code review is foreseen.
I really don't think googlecode or mercurial are "bad". It's just that they don't have a such polished interface to do reviewing as github. Believe me, if github were based on mercurial I would be really happy. But it's more important to acknowledge that reviewing would be very beneficial to the project. It could help to discuss changes and approaches between us without the fear to screw things up. It could also let us learn from the experience and knowledge of the rest. I think none of us knows the codebase as well as Pierre but the ones who know some parts better could help the others and viceversa.
Hey, I'm a fairly minor contributor to the project, so please weigh that in the decision. I only jumped into the discussion after Pierre expressed second thoughts about making the jump. My goal was not to persuade as much as it was to illustrate that Google Code will facilitate a number of different workflows, including ones that will model github's, and that it's code review interface is quite powerful even if it doesn't look fancy. In the end, I'm sure that the primary devs will make the right call for the project. Once that call is made, a little addition to the project site the describes the preferred workflow would be helpful.
anatoly techtonik
The main benefit in the move to github would be the possibility to use its pull request system to review the work of other developers and also users who have found a simple fix. It's not because git is better than mercurial.
anatoly t.
Steve
instead of splitting into multiple repos?
On Feb 16, 1:01 am, anatoly techtonik <techto...@gmail.com> wrote:
> 2012/1/21 Carlos Córdoba <ccordob...@gmail.com>
> > The main benefit in the move to github would be the possibility to use
> > its pull request system to review the work of other developers and also
> > users who have found a simple fix. It's not because git is better than
> > mercurial.
>
> So the major argument for GitHub move are code reviews. I took a look and
> more effectively done in mailing lists, like Mercurial guys do. No fancy
> icons, but it works.
>
> The major problem is with commenting unified diffs that most of the time 3
> lines of context is not enough. Sometimes I comment on the line that's
> outside the context if there is no time to figure how some relevant piece
> the url is long). I often grep the same file to see references to the code
> in question or to refresh memories about some code. Quite often I have to
> checkout and grep the whole project, and given Spyder complexity it will be
> done most of the time.
>
> So, my conclusion that GitHub reviews are mostly useless even though the
> interface is more accessible. But as I said - nothing stop us from
mangecoeur
of use of the website and the community there. Github makes it very
easy for anyone to create a fork to work with, and for their changes
to be eventually merged into the main code. This encourages new
contributors because you can create a modified version of a piece of
software and make it easily available without having to go through the
processes of getting your code accepted first - that way people can
test your code and if it works it's trivial to merge the changes back
into the main project.
On Feb 16, 8:01 am, anatoly techtonik <techto...@gmail.com> wrote:
> 2012/1/21 Carlos Córdoba <ccordob...@gmail.com>
>
> > its pull request system to review the work of other developers and also
> > users who have found a simple fix. It's not because git is better than
> > mercurial.
>
> So the major argument for GitHub move are code reviews. I took a look and
> more effectively done in mailing lists, like Mercurial guys do. No fancy
> icons, but it works.
>
> The major problem is with commenting unified diffs that most of the time 3
> lines of context is not enough. Sometimes I comment on the line that's
> outside the context if there is no time to figure how some relevant piece
> the url is long). I often grep the same file to see references to the code
> in question or to refresh memories about some code. Quite often I have to
> checkout and grep the whole project, and given Spyder complexity it will be
> done most of the time.
>
> So, my conclusion that GitHub reviews are mostly useless even though the
> interface is more accessible. But as I said - nothing stop us from
Pierre Raybaut
As written in the hgbook: "In most instances, isolating branches in
repositories is the right approach. Its simplicity makes it easy to
understand; and so it's hard to make mistakes. There's a one-to-one
relationship between branches you're working in and directories on
your system. This lets you use normal (non-Mercurial-aware) tools to
work on files within a branch/repository."
This being said, if everyone is ok with working with named branches... why not?
-Pierre
2012/2/16, Steve <steve.f....@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "spyder" group.
Jed Ludlow
The main advantage of Mercurial is its simplicity.
As written in the hgbook: "In most instances, isolating branches in
repositories is the right approach. Its simplicity makes it easy to
understand; and so it's hard to make mistakes. There's a one-to-one
relationship between branches you're working in and directories on
your system. This lets you use normal (non-Mercurial-aware) tools to
work on files within a branch/repository."
This being said, if everyone is ok with working with named branches... why not?
This was discussed a bit in a previous thread:
https://groups.google.com/forum/?fromgroups#!topic/spyderlib/A-0O6krrYRA
Since (1) you are already on the release-branch-by-clone model, and (2) Hg allows you to pull changes among repositories as a basic feature I didn't see a compelling reason to change at that time.
If you are going to manage multiple releases in a single repo, a model like this is advisable:
http://ellislab.com/blog/comments/branchy_management_in_mercurial
It most certainly requires you to be very careful about your merges, making sure you know precisely what "direction" you are merging changes, otherwise you can end up merging all the unstable changes onto a release branch. It also requires you to think carefully about how to apply a change that will affect multiple branches (e.g., bug fix). You've got to start at the oldest supported branch and then move forward if you want the merge history to look right.
With separate repositories, it's pretty clear when you are pulling changes from one repo to another about which direction you are "merging."
Pierre Raybaut
mangecoeur
the DVCS itself, but about the website and community that are
available. Google code just isn't as good as github/bitbucket because
of its poor social and sharing features - the other two make it very
easy for people to fork and play with the code, making it easier for
new users to become contributors. So a move to github or bitbucket
wouldn't be about code admin procedure/convention - instead its about
making it easier to broaden the spyderlib community and encourage more
contributions.
-Jon
On Feb 21, 10:16 am, Pierre Raybaut <pierre.rayb...@gmail.com> wrote:
> The main advantage of Mercurial is its simplicity.
> As written in the hgbook: "In most instances, isolating branches in
> repositories is the right approach. Its simplicity makes it easy to
> understand; and so it's hard to make mistakes. There's a one-to-one
> relationship between branches you're working in and directories on
> your system. This lets you use normal (non-Mercurial-aware) tools to
> work on files within a branch/repository."
>
> This being said, if everyone is ok with working with named branches... why not?
>
> -Pierre
>
>
>
>
>
>
>
> > Is there any chance we can keep all the branches in a single repo
> > instead of splitting into multiple repos?
>
> > On Feb 16, 1:01 am, anatoly techtonik <techto...@gmail.com> wrote:
> >> 2012/1/21 Carlos Córdoba <ccordob...@gmail.com>
>
> >> > The main benefit in the move to github would be the possibility to use
> >> > its pull request system to review the work of other developers and also
> >> > users who have found a simple fix. It's not because git is better than
> >> > mercurial.
>
> >> So the major argument for GitHub move are code reviews. I took a look and
> >> must say I am disappointed. For
> >> to comment unified diff, but in most cases it is useless. Such reviews are
> >> more effectively done in mailing lists, like Mercurial guys do. No fancy
> >> icons, but it works.
>
> >> The major problem is with commenting unified diffs that most of the time 3
> >> lines of context is not enough. Sometimes I comment on the line that's
> >> outside the context if there is no time to figure how some relevant piece
> >> of code
> >> works.http://code.google.com/p/spyderlib/source/diff?spec=svn545b7ba70fbdd0...
> >> (yes,
> >> the url is long). I often grep the same file to see references to the code
> >> in question or to refresh memories about some code. Quite often I have to
> >> checkout and grep the whole project, and given Spyder complexity it will
> >> be
> >> done most of the time.
>
> >> So, my conclusion that GitHub reviews are mostly useless even though the
> >> interface is more accessible. But as I said - nothing stop us from
> >> maintaining a mirror on GitHub - here is a even plugin that can help
Carlos Córdoba
wouldn't let us move our issue tracker. But, as Anatoly suggested a
while ago, what about creating a mirror in github or bitbucket? We could
let people who prefer those sites work there, ask for a pull request and
on our side we could integrate their changes with the main repos in
googlecode.
Pierre, what do you say?
El 28/02/12 05:10, mangecoeur escribió: