Hi, On Mon, Apr 28, 2014 at 1:05 PM, LRN <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28.04.2014 23:29, Matthew Brett wrote: >> On Mon, Apr 28, 2014 at 12:10 PM, Adrien Nader <[email protected]> wrote: >>> On Mon, Apr 28, 2014, LRN wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 28.04.2014 22:42, Adrien Nader wrote: >>>>> On Mon, Apr 28, 2014, Matthew Brett wrote: >>>>>> Hi, >>>>>> >>>>>> On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM >>>>>> <[email protected]> wrote: >>>>>>> On 4/28/2014 5:17 AM, JonY wrote: >>>>>>>> mingw-w64 may migrate from svn to git in the future, seeing >>>>>>>> that sf can now do multiple repos per project. >>>>>>> *snip* >>>>>>>> Discuss. >>>>>>> >>>>>>> I'm a bit surprised at the choice of Git -- in my experience, >>>>>>> Windows developers usually prefer Mercurial >>>>>>> (<http://mercurial.selenic.com/>) because on Windows it is more >>>>>>> lightweight and performant than Git. >>>>>>> >>>>>>> I also prefer Mercurial to Git because I find its syntax and >>>>>>> workflow more intuitive. This is of course personal taste. >>>>>>> >>>>>>> Mercurial repositories are also available in SourceForge. But if >>>>>>> the primary MinGW-w64 contributors are all more familiar with >>>>>>> Git then I suppose it shall be Git. >>>>>>> >>>>>>> My two cents. :) >>>>>> >>>>>>> From the sidelines - a big yes please for switching to git. In >>>>>>> my >>>>>> experience, the ease of git branching makes it far more >>>>>> comfortable making and proposing changes, even substantial >>>>>> changes. >>>>>> >>>>>> I hear the same is true of mercurial, but I know it much less >>>>>> well. >>>>>> >>>>>> I very much like the github pull-request system for code review - >>>>>> does sourceforge have something similar? I know bitbucket does. >>>>>> For the projects I'm involved in, pull requests make proposing >>>>>> changes very fluid, and they are good for recording discussion as >>>>>> well. >>>>> >>>>> I quite dislike github and its UI in particular. Uses flash on every >>>>> page (no idea what for) and lots of javascript which makes my laptop >>>>> heat and get noisy when displaying something as small as a 3-lines >>>>> diff. >>>>> >>>>> Anyway, is there an advantage github's pages over doing it on the >>>>> mailing-list like it is currently done? The amount of messages >>>>> which comes from that doesn't seem to be an issue. >>>> >>>> You can do pull-requests with mailing lists [1] >>>> >>>> [1] http://stackoverflow.com/questions/6235379 >>> >>> I'm aware of most of the things available to minimize contact with the >>> Web UIs of github; I find there's something telling about their >>> availability. ;p >> >> Yes, some people really don't like web UIs. These people are usually >> experienced developers who are not easily deterred from working out their >> own tools for doing stuff the way they want. I think the point of the >> github interface is lowering the barrier for people who are not (yet) in >> that camp, or who are in that camp but don't yet know how to automate >> their work with git in a satisfying way. >> >> Actually, I usually really don't like web UIs, with the single exception >> of the github pull request interface. For example, I usually use the >> 'hub' command line tool to interact with github [1]. I just found >> 'git-pulls' [2] which also looks useful. For commenting on large blocks >> of changes, I want the web interface. >> >> For example - maybe take a look at some of the 'how to contribute' pages >> for github projects. Here's an example from project I know well: >> >> http://sympy.org/en/development.html >> >> In there you'll see: >> >> "The github pull request is a preferred method, as that makes it easy for >> us to review and push the code in. That said, you can also clone the >> latest git repository (see the link on the right), prepare a branch with >> your code, upload it somewhere (for examplegithub) and send us a link to >> the sympy-patches mailinglist, or you can even send us raw patches --- but >> it will be more work for us to integrate it." >> > > For the record, i've had a nasty squabble with a hexchat developer, because > he wouldn't accept contributions in any format other than a git pull from > github. Since i wasn't about to create a fork of hexchat on github (because > github is not free, as in "free speech") to send pull requests from, i > couldn't accommodate that policy.
I can certainly see the argument that github is not open-source, and therefore implies some level of vendor lock-in. There are open-source alternatives, but I haven't used them for anything more than playing with. I also agree it should always be possible to submit changes without github. So if the author of the change prefers to email the patch, it seems silly to object. The key thing surely is to reduce the barrier for contribution as far as possible while keeping the barrier for maintainers at a reasonable level. Cheers, Matthew ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
