On Fri, Apr 30, 2010 at 8:53 AM, Brian Granger <ellisonbg....@gmail.com> wrote: > On Thu, Apr 29, 2010 at 2:45 PM, Ondrej Certik <ond...@certik.cz> wrote: >> Hi James! >> >> On Thu, Apr 29, 2010 at 2:02 PM, James Pearson <xiong.chiam...@gmail.com> >> wrote: >>> On Thu, Apr 29, 2010 at 1:32 PM, Ondrej Certik <ond...@certik.cz> wrote: >>>> >>>> Hi, >>>> >>>> I just found out this: >>>> >>>> http://github.com/certik/sympy/network >>>> >>>> it nicely shows patches from other people, one can nicely see which >>>> branches are not yet merged in, as well as to see some patch >>>> description by pointing the mouse to some dot. >>> >>> There is also the fork queue, which you can only view if you are the owner >>> or a collaborator on a project. It shows you unmerged changes from your >>> forks, and allows you to easily cherry-pick or ignore changesets into a >> >> It'd be also cool if anyone could do all the merging (without having >> to be a "collaborator") and then just send one pull request and >> someone from the "collaborator" list can just quickly merge it in. >> >>> branch of your choice. And, of course, pull requests, although this project >>> is close-knit enough that you probably have no need of it. >> >> Actually, we would need this. >> >>> >>> If you were not aware, you can also leave comments on commits (on specific >>> lines, even), which assists the code review process. >>> >>> Might I recommend an account for sympy (named sympy, naturally enough) that >>> has one repository that is a direct mirror of the canonical repo on >>> sympy.org? That way, we have a nice place to go to create forks (that >>> doesn't have developer's personal branches and whatnot), and if you feel >>> like using the networky features of github, you can pull into that repo and >>> push straight back into the canonical one. >> >> Yes, that'd be the best. What is the best way to do it? E.g. should we >> setup some kind of a cron job at our server that hosts git.sympy.org, >> or should this be in the post-update hook (but what if github is down >> at the moment...)? >> >>> >>> GitHub was built for collaboration, and the tools there really help if you >>> take advantage of them. >>> >>> BTW, the Patches Tutorial[0] is quite thorough (good job!), although there >>> are still quite a few hg-isms floating around in there (hey - I can fix >>> that!). I'd suggest providing a link to it in the README, perhaps? I've >> >> Yes to both! :) Just send us a patch to the docs making it better. >> Maybe you can also mention hg-git and just make the all docs use git >> as default, having a small section about mercurial for those who use >> it. >> >>> been noticing more and more projects asking contributors to make topic >>> branches[1] when they fork, and I think it really helps keep things cleaner >>> and simpler for whoever has to look over the code and approve it. >>> >>> Whew - sorry if any of this goes against what you've already got working (or >>> you're doing it already); I haven't really been paying much attention to the >>> sympy development process. >> >> We are still evolving it, e.g. we used just svn, then mercurial and >> now we use git, and the sympy-patches list for sending the patches in, >> but it sucks to apply them by hand (also many times the "git am" just >> fails), so I just encourage people to post branches in there, and so >> it makes sense to me to just use github and post the branches there >> and ask for a merge. (Problem with sympy-patches is that I easily >> loose track of what is ready for review or what still needs review). >> >> So if you have some more suggestions how we can improve our workflow, >> I am definitely interested. > > I think it would make the development workflow easier if we had a > "sympy" user on github that hosted the main repo. We could give all > the core devs write access to that repo. This would simplify the > workflow in a number of ways: > > * Trivial to fork sympy on github. > * No need for developers to manage multiple remotes if they are > hosting branches on github. > * Easy to submit pull requests to trigger code reviews.
How does this work? I tried to send the pull request to the sympy user (see below), but I don't see it anywhere. So I guess we should send pull request for real people (like I would send it to you for example), you'll get an email, look at the branch review it and integrate it in your own branch somehow and then push it into the sympy user? I can then I guess trivially synchronize it with git.sympy.org. > * Nice code review system on github. So in order that we don't need to repull/reclone all our git repositories at github, I created the user "sympy" and just cloned my own git repo and deleted all the other 70+ branches, here it is: http://github.com/sympy/ the network seems to be working fine: http://github.com/sympy/sympy/network Also I have added all people that I know a git account of as collaborators. > > We are moving in this direction with IPython. You are moving from bzr to git? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
