kicad-developers team mailing list archive

[Henner Zeller <h.zeller@xxxxxxx>]

On 4 February 2014 18:36, Blair Bonnett <blair.bonnett@xxxxxxxxx> wrote:
>
> On 5 February 2014 15:03, Henner Zeller <h.zeller@xxxxxxx> 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