On 1/8/14 15:54 , David Bagby wrote: > I remembered that the doc you referenced mentions the LCNC repo on git hub. > That made me think that using git hub may save reinventing the wheel here... > > I'm thinking that "fork then pull request" is favorable over "push patch". > Instead of developing patches against the repo in linuxcnc.org, we might > want to encourage people to fork the git hub repo.
I think the Contributing document is correct as currently written. I don't think anyone's reinventing any wheels (at least i hope not). You raised two issues here: which git repo people base their work on, and how they share it back to the project. 1. Which repo? The main git repo for the LinuxCNC project is at git.linuxcnc.org. We do not in any way want to discourage people from using that as the basis of their work. In addition to that main repo, Jeff maintains a mirror on github, and people are perfectly welcome to use it as the basis of their work too. As long as the mirror is kept up to date with the main repo at git.linuxcnc.org, it doesn't much matter which repo people base their work on. Github has some great features (their bugtracker, conversations around individual commits and around pull requests, etc), i totally agree with that. I use github myself for other projects and i enjoy it. But the linuxcnc project is not hosted there, and that's ok too. 2. How do contributors share their changes back? I assume that by "push patch" you mean "email a patch to the mailing list". If that's the case, then i disagree that we should discourage that in favor of any particular other method. For casual contributors, this is probably the easiest method - they don't need to make a github account (or any other kind of account anywhere). This is a method of contributing that we want to enable. A more serious and persistent contributor will probably benefit from having a publicly accessible git repo (on github or anywhere else), and that's a method of contributing that we want to enable too. Just not in preference over the simple "email a patch" method. IMO. > Anyone can fork the github repo and then make a pull request. > Then people contributing changes can make a pull request on github to > get the change back into the LCNC github repo. > This flow avoids some issues around who has push access etc to the repo > on linuxcnc. This is an idea i've heard before, but I don't understand it. What push-access issues does this workflow or infrastructure avoid? > Pull requests also get logged (so no need to invent patch submission > tracking procedures), and a pull request invokes a code review process. Yeah, that part is pretty cool. > Doing "fork/pull request" vs "generating a patch against the Linuxcnc > repo" lets us leverage the workflow tools git hub already provides - > thus no need to invent new one off processes to track patches, comment > about patches etc. I don't think anyone's talking about inventing new infrastructure. I just think the infrastructure we have (ie, the dev mailing list) is totally adequate and appropriate for having discussions about patches and branches. > When the patch is accepted into the git hub repo, a release manger can > easily merge github back into the repo on LinuxCNC.org. No way. There has to be one true repo that's the central place to which new changes come to be part of the main line. Developer repos are fine, and even shared developer repos are fine. We already have that, and it works. If we're going to make github part of our workflow in this way, then we should just move our project there. I am opposed to moving our main project hosting to github at this time. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
