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
<mailto: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 <mailto: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.
