On 04/30/2010 11:09 PM, Ondrej Certik wrote: > 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/ >
Should we now fork this repository and then push our private branches to the new fork? Sebastian -- 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.