On 4 February 2014 18:36, Blair Bonnett <blair.bonn...@gmail.com> wrote: > > On 5 February 2014 15:03, Henner Zeller <h.zel...@acm.org> wrote: >> >> ...snip... >> >> This sounds excellent. I think I am going to base my pending work on >> your mirror until the official kicad-source-mirror is fixed to be >> up-to-date. >> >> We need to make sure though that the reverse path back into the KiCad >> source works as well: pull requests. >> The first part is much simpler than with bzr: It will be simple to >> code-review pull requests with comments and all amenities of of the >> github process. Kicad developers (with a link to the pull request on >> the mirror) can comment on the patch which is a simpler and faster >> process than sending a patch via email and discussing it over that >> medium. >> >> Once the patch is reviewed and optimized, some KiCad main developer >> can get the patch and apply it to the main bzr (and then delete the >> original pull request on git). >> >> So one question: Blair would you be happy if you see pull requests on >> your mirror ? > > > It wouldn't bother me. But I am nowhere near being a core developer, and am > very unfamiliar with the code (hoping to find the time to implement a couple > of features in the medium term, but that is another story), so I cannot > review or apply patches. You'd have to find a workflow which works for the > developers -- they may prefer to keep reviews on the mailing list. > > To quote an earlier message from Cirilo Bernardo, who has recently submitted > several patches for IDF export support: > >> If it's a small patch I post it to the list, if it's an enormous patch I >> push it to my patch >> repository on github and make an announcement on the list. > > Another option could be to use the GitHub comparison feature (click the > green button above the file list of a GitHub repository) to post changes to > the list. For example, the last few commits from my mirror: > > https://github.com/blairbonnett-mirrors/kicad/compare/582ca1519a...0b379a5382 > > To get a diff file, just add .diff to the URL: > > https://github.com/blairbonnett-mirrors/kicad/compare/582ca1519a...0b379a5382.diff
Sounds good. So a good workflow for a git-aware developer would be: - create a fork based on your mirror (and update that in a timely fashion). That would be the master branch. - create local branches one per feature/fix. - send the 'compare' link to the list along with the diff-button for developers to review and download, potentially comment. That way, we keep your mirror free from pull requests, but still have a nice workflow for everyone involved, including KiCad main developers. -h > > Regards, > Blair > > >> >> KiCad developers: what can we do to have the official >> https://github.com/KiCad/kicad-source-mirror mirror up-to-date all the >> time, so that we can adopt such a workflow ? Can Blair get access to >> the main KiCad github to run his script to update that ? >> >> I do see some long-term developers roll their eyes. But, as author and >> contributor to many open source projects, I can tell you that not >> putting unnecessary hurdles in the way of potential contributors is as >> well an important aspect of an open source project. >> >> -h _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp