Re: [Kicad-developers] Advice on merge request

[Brian Piccioni]

Eeli

I have to re-create my fork based on Alexander's Gitlab fork because 
mine is based on his Github fork, which is a generation behind his 
Gitlab fork (isn't migrations wonderful?).


Then I have to run it through a style checker. Once I do that (probably 
a few days, I'll push it out and let everybody know).


Thanks for the input

Brian

On 2020-01-04 4:48 p.m., Eeli Kaikkonen wrote:
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 > 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
mailto:br...@documenteddesigns.com>>
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.

___
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

Re: [Kicad-developers] Advice on merge request

[Eeli Kaikkonen]

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  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 <
> br...@documenteddesigns.com> 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.
>>
>
___
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

Re: [Kicad-developers] Advice on merge request

[Jon Evans]

Hi Brian,

For the first question, you could cherry-pick all the commits from
Alexander's merge request onto your own feature branch (rebasing your own
commits on top of his).
Once his MR is merged, you can just rebase your branch on top of latest
master, dropping the cherry-picked commits and just keeping your own.
Then, open your own merge request. Does that make sense?

I see no problem directing people to your fork/testing branch to compile
and test on their own.
Providing pre-compiled binaries of your branch is a bit more risky as it
could potentially result in people forgetting they have it installed, then
opening bug reports with version info that makes no sense.
My input here is only a suggestion, but my suggestion is to do as much
testing as possible with users who are also able to compile KiCad from
source, and then wait to collect wider feedback until your proposed changes
have been approved by the development team, merged, and are available in
nightly builds.  It's always possible for you to do follow-on merge
requests to make any additional changes you desire after your initial
feature has been merged.

Best,
-Jon

On Sat, Jan 4, 2020 at 11:43 AM Brian Piccioni 
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.
>
> Also, I have a user base of people who have been using my standalone
> RenumKicadPCB utility. I would like to direct them to my fork and/or
> pre-compiled Windows exes so they can help test it. It turns out there
> are lots of ways a project can be made with reference designation issues
> in the schematic and/or PCB so I would like to be sure I catch them all.
> I would, of course, flag that this is not an official Kicad release, etc..
>
> Any objections/suggestions?
>
> thanks
>
> Brian Piccioni
>
>
> ___
> 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
>
___
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

[Kicad-developers] Advice on merge request

[Brian Piccioni]

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.

Also, I have a user base of people who have been using my standalone 
RenumKicadPCB utility. I would like to direct them to my fork and/or 
pre-compiled Windows exes so they can help test it. It turns out there 
are lots of ways a project can be made with reference designation issues 
in the schematic and/or PCB so I would like to be sure I catch them all. 
I would, of course, flag that this is not an official Kicad release, etc..


Any objections/suggestions?

thanks

Brian Piccioni


___
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