On Sun, 30 Jun 2013 13:15:55 -0400 Ian McMahon <imcma...@prototechnical.com> wrote:
> however it shakes out, there needs to be some clear direction on the > best practices for managing development on branches and forks, how > pull requests and merges should be done, who can and will review and > merge them, etc. I agree with you completely. > I'm heavily in favor of using a service like github or bitbucket > because I think their web tools make these practices obvious and easy > to manage. In my day job, we use bitbucket for everything, and the > pull request model and the web merge gui has been the single easiest > way to get more eyes on code. People even review their OWN commits > this way, and I've been amazed at how much more efficient it has made > our work. This is, IMHO, _the_ argument FOR using github/bitbucket. My desire would be to replicate this functionality AND achieve similar results (efficiency, large number of reviewers, etc) within our current infrastructure at linuxcnc.org. If this proves impossible, we should find a way to use github/bitbucket on terms acceptable to the skeptics like me, cradek, seb, et al who look askance at using any facility that's not obtained under the traditional fee-for-service model. I think most of our skepticism could be ameliorated if we were a paid client of one of these services. Github for example has fee-for-service arrangements like these: https://github.com/plans ($7-$200/month, various options) https://enterprise.github.com/pricing ($250/developer/year - a little pricy for us :) Once we pay for it, it's no different than buying a web server like we do now. The other issue is that jepler is never going to agree to use a service that doesn't have a command line interface as an option, and I agree with him. I will say that having a GUI/Web style interface is a big plus because it helps reduce the slope of the learning curve to get started contributing to the project. > That said, I don't have any strong opposition to continuing to use > the existing repository, but there needs to be a document written up > that clearly explains for the less savvy folks exactly how to use > command line git to work with our repositories in the way that we > want them to (how to branch, fork, submit PRs, etc). I'd even > suggest having instructions on how to do the more "advanced" things > (like merge), even though the immediate audience may not be doing > those things, because today's newbies may be tomorrow's release > managers, and I think it's healthy to encourage an environment where > people want to be more involved and get more responsibility. OK, I want to start making a "HOWTO Contribute To The Project" wiki page. Linked to that page will be this page that's at least the beginnings of what you want: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Git Once I get the "HOWTO Contribute To The Project" page going, I'll see about getting the experts (jepler & seb probably) to address any shortcomings you can identify on the "Git" page. Can you review this for me and point out where the "Git" page needs improving/expanding? > I'm not saying we don't have that already, and Michael was quick to > help me get set up to start contributing, but I think overall we > might get more contributors if the process were more transparent. > Nobody wants to be the guy to say "I use git every day but I have no > idea how to work with branches", but I suspect more people are in > that boat than you might imagine :) I'm terrible with Git. At the CNC Workshop in Ann Arbor in 2011 (I think) Seb spent thousands of calories trying to educate me on Git and its ways and uses. It did some good, but I'm a long way from competency. It is however, _the tool_ for this type of work, and I (and everyone else who needs it) will have to make the intellectual investment required. I do feel your pain :) Thanks, Matt ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
