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. 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.
