kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

I have already added Alexander's fork as a "remote" for my local clone of
kicad. When I'm back home, I can add yours. You have already forked from
Alexander - if you have a local branch based on Alexander's "backannotate"
which you want to publish for testing, just push it to your remote, i.e. to
your gitlab fork. Then I can see it and fetch, compile and test it, just
like I did for Alexander's backannotate. Jon told you what happens after
Alexander's is merged to the kicad master (I don't have experience to give
you advice about that).

I hope everyone - including the lead developers - follow this workflow when
they want their code tested: add a clearly named branch to their gitlab
fork of kicad. It can be found easily by following the "Fork" number link
from the official kicad repo and won't get lost in a mailing list or
something like that.

Merge requests are even easier to find. You can add "WIP:" to the name of a
merge request - it means "work in progress" and prevents merging before you
remove "WIP:" from the name, so you can work on your merge request and get
feedback before it's ready to be merged. But I suppose a WIP merge request
is recommended only for code which is actually expected to be actually
merged later, not for all experiments.

Eeli Kaikkonen


On Sat, Jan 4, 2020 at 7:00 PM Jon Evans <jon@xxxxxxxxxxxxx> wrote:

I see no problem directing people to your fork/testing branch to compile
and test on their own.

>
> On Sat, Jan 4, 2020 at 11:43 AM Brian Piccioni <
> brian@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> Hello
>>
>> I have been working on Geographical reannotation. It uses the code
>> Alexander Shuklin created for back annotation. I understand Alexander's
>> merge request has been pending (yes, I know it is holidays) but now I
>> don't know how to proceed because my code depends on his code.
>>
>> Any suggestions would be welcomed.
>>
>