Re: [Kicad-developers] Git transition

[Mark Roszko]

gitconfig is not loaded by git for security unless you explicitly tell it to.

i.e. a user still has to run

git config --local include.path ../.gitconfig

___
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] Git transition

[Simon Wells]

After having messed up my first emailed patch due to missing this
email, would it not be better to add a .gitconfig to the project tree
which includes this helper script by default?

On Fri, Aug 12, 2016 at 9:36 PM, Maciej Sumiński
 wrote:
> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
> [snip]
>> I'll see if I can figure out how to do this and if it works we can use
>> it instead of adding the bug report url to the commit message.  I wonder
>> if we can link a commit to a bug report?  That could be an issue if we
>> cannot.  I don't want to have to always create a separate branch, push
>> it to my personal repo, and then merge it into the product branch for
>> simple bug fixes.
>
> I already link commits to corresponding bug reports, see an example [1].
>
> To make life even easier, I have just pushed an additional git config
> file (rev 7022). To enable it:
>
>   git config --add include.path "$(pwd)/helpers/git/fixes_alias"
>
> And afterwards:
>
>   
>   git commit -a -m "Fixed a memleak"
>   git fixes 123456
>   git push
>
> In the current form it is a mix of what Wayne and Chris have suggested,
> so in the end you will get:
>
> orson@pcbe15262 ~/workspace/kicad % git log -n1
> commit 4ea4dcd67d89ce612aa1826dc845cc1137040fbf
> Author: Maciej Suminski 
> Date:   Fri Aug 12 11:34:06 2016 +0200
>
> Fixed a memleak
>
> Fixes: lp:123456
> * https://bugs.launchpad.net/kicad/+bug/123456
>
> Regards,
> Orson
>
> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1612107
>
>
> ___
> 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

Re: [Kicad-developers] Git transition

[Nick Østergaard]

I think the mirror should be working again now, we will see when
something is pushed to lp.

2016-08-25 7:40 GMT+02:00 Nick Østergaard :
> I will try to make the mirror be synced from launchpad, at latest on friday.
>
> 2016-08-24 5:39 GMT+02:00 kinichiro inoguchi :
>> Hi,
>>
>> I hope mirror on GitHub keeps refreshing from new git repo on Launchpad.
>> https://github.com/KiCad/kicad-source-mirror
>>
>> For GUI translators task,
>> we need to download source code tarball to obtain strings in the GUI.
>>
>> On GitHub, we could download every committed rev as tarball by one click.
>> On Launchpad, it seems that only tagged rev can be downloaded.
>>
>> If POT file for GUI is provided for every commits, maybe, GUI translators do
>> not need to access mirror, though.
>>
>> Best regards
>>
>>
>> ___
>> 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

Re: [Kicad-developers] Git transition

[Nick Østergaard]

I will try to make the mirror be synced from launchpad, at latest on friday.

2016-08-24 5:39 GMT+02:00 kinichiro inoguchi :
> Hi,
>
> I hope mirror on GitHub keeps refreshing from new git repo on Launchpad.
> https://github.com/KiCad/kicad-source-mirror
>
> For GUI translators task,
> we need to download source code tarball to obtain strings in the GUI.
>
> On GitHub, we could download every committed rev as tarball by one click.
> On Launchpad, it seems that only tagged rev can be downloaded.
>
> If POT file for GUI is provided for every commits, maybe, GUI translators do
> not need to access mirror, though.
>
> Best regards
>
>
> ___
> 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

Re: [Kicad-developers] Git transition

[Chris Pavlina]

Having discussed this a bit more on IRC I must take back this
suggestion. Presumably 5.0 will be based on master rather than on 4.0,
so things will get messy if we do that...

On Wed, Aug 24, 2016 at 08:03:24PM -0400, Chris Pavlina wrote:
> I really think the branch should just be named 'stable', things like
> "4.0" should be tags inside it.
> 
> However I have pushed an additional 4.0 branch to avoid breaking things
> that may have been depending on that name, if there are any.
> 
> On Wed, Aug 24, 2016 at 07:56:05PM -0400, Wayne Stambaugh wrote:
> > Nick,
> > 
> > Is this what you were looking for or are you also expecting the branch
> > to be named 4.0 instead of stable-4?
> > 
> > On 8/24/2016 7:31 PM, Chris Pavlina wrote:
> > > Should be good now.
> > > 
> > > On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
> > >> Thanks.
> > >>
> > >> On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> > >>> I'll fix it.
> > >>>
> > >>> On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
> >  Are saying that Niki's branch is different?  When I was asking about a
> >  git version of the stable branch, why didn't you say something?  I
> >  didn't even see that there was another branch in the mirror on github.
> >  I agree that it should match the mirror assuming the mirror is up to
> >  date with the bzr stable 4 branch.  What do I need to fix this?  If
> >  someone else wants to step up to the plate and fix this, I'm fine with
> >  that.  I'm busy trying to get my own work done and my patience with the
> >  git transition is wearing thin.
> > 
> >  On 8/24/2016 4:35 PM, Nick Østergaard wrote:
> > > I don't like that your "stable-4" branch don't match the 4.0 branch in
> > > the kicad-source mirror.
> > > See:
> > > https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
> > > https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
> > >
> > > I think it would be better off if we could use the 4.0 branch from the
> > > kicad-source-mirror to base it on, and name the branch 4.0 as it was
> > > named before and everywhere else.
> > >
> > > Why did you suddenly start to name the banch "stable-"
> > >
> > > 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
> > >> Thanks everyone for taking a look at this.  I just pushed the 
> > >> stable-4
> > >> branch to lp:kicad so we should be synced up.  I'll tag the bzr 
> > >> stable 4
> > >> repo as obsolete when I get a chance.
> > >>
> > >> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
> >  Can someone please take a look at it you get a chance and make 
> >  sure I
> >  didn't make a mess of things before I push this to the main repo.
> > >>>
> > >>> Hi,
> > >>>
> > >>> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
> > >>>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
> > >>>   https://code.launchpad.net/~stambaughw/kicad/4.0
> > >>>
> > >>> 1. empty directory packaging/linux/ is missing
> > >>>
> > >>>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
> > >>>   Is this directory needed ?
> > >>>
> > >>> 2. difference of commit logs
> > >>>
> > >>>   On lp_kicad_4, lines of logs are 6308.
> > >>>   $ bzr log --line | wc -l
> > >>>   6308
> > >>>
> > >>>   On git_stable4, 8181 logs exists.
> > >>>   $ git log --oneline | wc -l
> > >>>   8181
> > >>>
> > >>>   To see diffs, I created the log texts by these commands.
> > >>>
> > >>>   On lp_kicad_4,
> > >>>   $ bzr log --line | sed 's/^[0-9]*: .*
> > >>> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> > >>> | sed 's/^{.*} //' > ../bzr.txt
> > >>>
> > >>>   On git_stable4,
> > >>>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
> > >>>
> > >>>   Then look at the diffs,
> > >>>   $ diff -y bzr.txt git.txt | less
> > >>>
> > >>>   For example, diffs are like this.
> > >>>   
> > >>> 
> > >>>   ...
> > >>>   Pcbnew: fix potential issue (crash) when loading board files
> > >>> Pcbnew: fix
> > >>>   [merge] OSX: back port touchpad support from development bran | 
> > >>> OSX: back po
> > >>> > 
> > >>> Fix 3d-viewe
> > >>> > 
> > >>> Fix touchpad
> > >>> > 
> > >>> Add support
> > >>>   OSX: legacy canvas rendering speed improvements.
> > >>> OSX: legacy
> > >>>   ...
> > >>>   
> > >>> =

Re: [Kicad-developers] Git transition

[Chris Pavlina]

I really think the branch should just be named 'stable', things like
"4.0" should be tags inside it.

However I have pushed an additional 4.0 branch to avoid breaking things
that may have been depending on that name, if there are any.

On Wed, Aug 24, 2016 at 07:56:05PM -0400, Wayne Stambaugh wrote:
> Nick,
> 
> Is this what you were looking for or are you also expecting the branch
> to be named 4.0 instead of stable-4?
> 
> On 8/24/2016 7:31 PM, Chris Pavlina wrote:
> > Should be good now.
> > 
> > On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
> >> Thanks.
> >>
> >> On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> >>> I'll fix it.
> >>>
> >>> On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
>  Are saying that Niki's branch is different?  When I was asking about a
>  git version of the stable branch, why didn't you say something?  I
>  didn't even see that there was another branch in the mirror on github.
>  I agree that it should match the mirror assuming the mirror is up to
>  date with the bzr stable 4 branch.  What do I need to fix this?  If
>  someone else wants to step up to the plate and fix this, I'm fine with
>  that.  I'm busy trying to get my own work done and my patience with the
>  git transition is wearing thin.
> 
>  On 8/24/2016 4:35 PM, Nick Østergaard wrote:
> > I don't like that your "stable-4" branch don't match the 4.0 branch in
> > the kicad-source mirror.
> > See:
> > https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
> > https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
> >
> > I think it would be better off if we could use the 4.0 branch from the
> > kicad-source-mirror to base it on, and name the branch 4.0 as it was
> > named before and everywhere else.
> >
> > Why did you suddenly start to name the banch "stable-"
> >
> > 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
> >> Thanks everyone for taking a look at this.  I just pushed the stable-4
> >> branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 
> >> 4
> >> repo as obsolete when I get a chance.
> >>
> >> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
>  Can someone please take a look at it you get a chance and make sure I
>  didn't make a mess of things before I push this to the main repo.
> >>>
> >>> Hi,
> >>>
> >>> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
> >>>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
> >>>   https://code.launchpad.net/~stambaughw/kicad/4.0
> >>>
> >>> 1. empty directory packaging/linux/ is missing
> >>>
> >>>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
> >>>   Is this directory needed ?
> >>>
> >>> 2. difference of commit logs
> >>>
> >>>   On lp_kicad_4, lines of logs are 6308.
> >>>   $ bzr log --line | wc -l
> >>>   6308
> >>>
> >>>   On git_stable4, 8181 logs exists.
> >>>   $ git log --oneline | wc -l
> >>>   8181
> >>>
> >>>   To see diffs, I created the log texts by these commands.
> >>>
> >>>   On lp_kicad_4,
> >>>   $ bzr log --line | sed 's/^[0-9]*: .*
> >>> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> >>> | sed 's/^{.*} //' > ../bzr.txt
> >>>
> >>>   On git_stable4,
> >>>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
> >>>
> >>>   Then look at the diffs,
> >>>   $ diff -y bzr.txt git.txt | less
> >>>
> >>>   For example, diffs are like this.
> >>>   
> >>> 
> >>>   ...
> >>>   Pcbnew: fix potential issue (crash) when loading board files
> >>> Pcbnew: fix
> >>>   [merge] OSX: back port touchpad support from development bran | 
> >>> OSX: back po
> >>> > Fix 
> >>> 3d-viewe
> >>> > Fix 
> >>> touchpad
> >>> > Add 
> >>> support
> >>>   OSX: legacy canvas rendering speed improvements.
> >>> OSX: legacy
> >>>   ...
> >>>   
> >>> 
> >>>
> >>>   This diff referes to revno 6291.
> >>>   It seems that git displays all the commit logs in 1 merge of bzr.
> >>>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
> >>>
> >>>   I think these diffs of commit logs are not problem.
> >>>
> >>>
> >>> After all, I think new git stable4 branch is right.
> >>> And, thanks for all of your hard works.
> >>>
> 

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

Nick,

Is this what you were looking for or are you also expecting the branch
to be named 4.0 instead of stable-4?

On 8/24/2016 7:31 PM, Chris Pavlina wrote:
> Should be good now.
> 
> On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
>> Thanks.
>>
>> On 8/24/2016 7:16 PM, Chris Pavlina wrote:
>>> I'll fix it.
>>>
>>> On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
 Are saying that Niki's branch is different?  When I was asking about a
 git version of the stable branch, why didn't you say something?  I
 didn't even see that there was another branch in the mirror on github.
 I agree that it should match the mirror assuming the mirror is up to
 date with the bzr stable 4 branch.  What do I need to fix this?  If
 someone else wants to step up to the plate and fix this, I'm fine with
 that.  I'm busy trying to get my own work done and my patience with the
 git transition is wearing thin.

 On 8/24/2016 4:35 PM, Nick Østergaard wrote:
> I don't like that your "stable-4" branch don't match the 4.0 branch in
> the kicad-source mirror.
> See:
> https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
> https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
>
> I think it would be better off if we could use the 4.0 branch from the
> kicad-source-mirror to base it on, and name the branch 4.0 as it was
> named before and everywhere else.
>
> Why did you suddenly start to name the banch "stable-"
>
> 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
>> Thanks everyone for taking a look at this.  I just pushed the stable-4
>> branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
>> repo as obsolete when I get a chance.
>>
>> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
 Can someone please take a look at it you get a chance and make sure I
 didn't make a mess of things before I push this to the main repo.
>>>
>>> Hi,
>>>
>>> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
>>>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
>>>   https://code.launchpad.net/~stambaughw/kicad/4.0
>>>
>>> 1. empty directory packaging/linux/ is missing
>>>
>>>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
>>>   Is this directory needed ?
>>>
>>> 2. difference of commit logs
>>>
>>>   On lp_kicad_4, lines of logs are 6308.
>>>   $ bzr log --line | wc -l
>>>   6308
>>>
>>>   On git_stable4, 8181 logs exists.
>>>   $ git log --oneline | wc -l
>>>   8181
>>>
>>>   To see diffs, I created the log texts by these commands.
>>>
>>>   On lp_kicad_4,
>>>   $ bzr log --line | sed 's/^[0-9]*: .*
>>> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
>>> | sed 's/^{.*} //' > ../bzr.txt
>>>
>>>   On git_stable4,
>>>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
>>>
>>>   Then look at the diffs,
>>>   $ diff -y bzr.txt git.txt | less
>>>
>>>   For example, diffs are like this.
>>>   
>>> 
>>>   ...
>>>   Pcbnew: fix potential issue (crash) when loading board files
>>> Pcbnew: fix
>>>   [merge] OSX: back port touchpad support from development bran | OSX: 
>>> back po
>>> > Fix 
>>> 3d-viewe
>>> > Fix 
>>> touchpad
>>> > Add 
>>> support
>>>   OSX: legacy canvas rendering speed improvements.OSX: 
>>> legacy
>>>   ...
>>>   
>>> 
>>>
>>>   This diff referes to revno 6291.
>>>   It seems that git displays all the commit logs in 1 merge of bzr.
>>>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
>>>
>>>   I think these diffs of commit logs are not problem.
>>>
>>>
>>> After all, I think new git stable4 branch is right.
>>> And, thanks for all of your hard works.
>>>
>>> ___
>>> 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/~kic

Re: [Kicad-developers] Git transition

[Chris Pavlina]

A note to everyone, you may have to run "git fetch --tags" in order for
your tags to be updated locally.

On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
> Thanks.
> 
> On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> > I'll fix it.
> > 
> > On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
> >> Are saying that Niki's branch is different?  When I was asking about a
> >> git version of the stable branch, why didn't you say something?  I
> >> didn't even see that there was another branch in the mirror on github.
> >> I agree that it should match the mirror assuming the mirror is up to
> >> date with the bzr stable 4 branch.  What do I need to fix this?  If
> >> someone else wants to step up to the plate and fix this, I'm fine with
> >> that.  I'm busy trying to get my own work done and my patience with the
> >> git transition is wearing thin.
> >>
> >> On 8/24/2016 4:35 PM, Nick Østergaard wrote:
> >>> I don't like that your "stable-4" branch don't match the 4.0 branch in
> >>> the kicad-source mirror.
> >>> See:
> >>> https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
> >>> https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
> >>>
> >>> I think it would be better off if we could use the 4.0 branch from the
> >>> kicad-source-mirror to base it on, and name the branch 4.0 as it was
> >>> named before and everywhere else.
> >>>
> >>> Why did you suddenly start to name the banch "stable-"
> >>>
> >>> 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
>  Thanks everyone for taking a look at this.  I just pushed the stable-4
>  branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
>  repo as obsolete when I get a chance.
> 
>  On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
> >> Can someone please take a look at it you get a chance and make sure I
> >> didn't make a mess of things before I push this to the main repo.
> >
> > Hi,
> >
> > I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
> >   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
> >   https://code.launchpad.net/~stambaughw/kicad/4.0
> >
> > 1. empty directory packaging/linux/ is missing
> >
> >   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
> >   Is this directory needed ?
> >
> > 2. difference of commit logs
> >
> >   On lp_kicad_4, lines of logs are 6308.
> >   $ bzr log --line | wc -l
> >   6308
> >
> >   On git_stable4, 8181 logs exists.
> >   $ git log --oneline | wc -l
> >   8181
> >
> >   To see diffs, I created the log texts by these commands.
> >
> >   On lp_kicad_4,
> >   $ bzr log --line | sed 's/^[0-9]*: .*
> > [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> > | sed 's/^{.*} //' > ../bzr.txt
> >
> >   On git_stable4,
> >   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
> >
> >   Then look at the diffs,
> >   $ diff -y bzr.txt git.txt | less
> >
> >   For example, diffs are like this.
> >   
> > 
> >   ...
> >   Pcbnew: fix potential issue (crash) when loading board files
> > Pcbnew: fix
> >   [merge] OSX: back port touchpad support from development bran | OSX: 
> > back po
> > > Fix 
> > 3d-viewe
> > > Fix 
> > touchpad
> > > Add 
> > support
> >   OSX: legacy canvas rendering speed improvements.OSX: 
> > legacy
> >   ...
> >   
> > 
> >
> >   This diff referes to revno 6291.
> >   It seems that git displays all the commit logs in 1 merge of bzr.
> >   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
> >
> >   I think these diffs of commit logs are not problem.
> >
> >
> > After all, I think new git stable4 branch is right.
> > And, thanks for all of your hard works.
> >
> > ___
> > 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
> >>
> >>

Re: [Kicad-developers] Git transition

[Chris Pavlina]

Should be good now.

On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
> Thanks.
> 
> On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> > I'll fix it.
> > 
> > On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
> >> Are saying that Niki's branch is different?  When I was asking about a
> >> git version of the stable branch, why didn't you say something?  I
> >> didn't even see that there was another branch in the mirror on github.
> >> I agree that it should match the mirror assuming the mirror is up to
> >> date with the bzr stable 4 branch.  What do I need to fix this?  If
> >> someone else wants to step up to the plate and fix this, I'm fine with
> >> that.  I'm busy trying to get my own work done and my patience with the
> >> git transition is wearing thin.
> >>
> >> On 8/24/2016 4:35 PM, Nick Østergaard wrote:
> >>> I don't like that your "stable-4" branch don't match the 4.0 branch in
> >>> the kicad-source mirror.
> >>> See:
> >>> https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
> >>> https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
> >>>
> >>> I think it would be better off if we could use the 4.0 branch from the
> >>> kicad-source-mirror to base it on, and name the branch 4.0 as it was
> >>> named before and everywhere else.
> >>>
> >>> Why did you suddenly start to name the banch "stable-"
> >>>
> >>> 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
>  Thanks everyone for taking a look at this.  I just pushed the stable-4
>  branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
>  repo as obsolete when I get a chance.
> 
>  On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
> >> Can someone please take a look at it you get a chance and make sure I
> >> didn't make a mess of things before I push this to the main repo.
> >
> > Hi,
> >
> > I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
> >   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
> >   https://code.launchpad.net/~stambaughw/kicad/4.0
> >
> > 1. empty directory packaging/linux/ is missing
> >
> >   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
> >   Is this directory needed ?
> >
> > 2. difference of commit logs
> >
> >   On lp_kicad_4, lines of logs are 6308.
> >   $ bzr log --line | wc -l
> >   6308
> >
> >   On git_stable4, 8181 logs exists.
> >   $ git log --oneline | wc -l
> >   8181
> >
> >   To see diffs, I created the log texts by these commands.
> >
> >   On lp_kicad_4,
> >   $ bzr log --line | sed 's/^[0-9]*: .*
> > [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> > | sed 's/^{.*} //' > ../bzr.txt
> >
> >   On git_stable4,
> >   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
> >
> >   Then look at the diffs,
> >   $ diff -y bzr.txt git.txt | less
> >
> >   For example, diffs are like this.
> >   
> > 
> >   ...
> >   Pcbnew: fix potential issue (crash) when loading board files
> > Pcbnew: fix
> >   [merge] OSX: back port touchpad support from development bran | OSX: 
> > back po
> > > Fix 
> > 3d-viewe
> > > Fix 
> > touchpad
> > > Add 
> > support
> >   OSX: legacy canvas rendering speed improvements.OSX: 
> > legacy
> >   ...
> >   
> > 
> >
> >   This diff referes to revno 6291.
> >   It seems that git displays all the commit logs in 1 merge of bzr.
> >   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
> >
> >   I think these diffs of commit logs are not problem.
> >
> >
> > After all, I think new git stable4 branch is right.
> > And, thanks for all of your hard works.
> >
> > ___
> > 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
> >>
> >>
> >> ___
> >> Mailing list: https://launc

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

Thanks.

On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> I'll fix it.
> 
> On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
>> Are saying that Niki's branch is different?  When I was asking about a
>> git version of the stable branch, why didn't you say something?  I
>> didn't even see that there was another branch in the mirror on github.
>> I agree that it should match the mirror assuming the mirror is up to
>> date with the bzr stable 4 branch.  What do I need to fix this?  If
>> someone else wants to step up to the plate and fix this, I'm fine with
>> that.  I'm busy trying to get my own work done and my patience with the
>> git transition is wearing thin.
>>
>> On 8/24/2016 4:35 PM, Nick Østergaard wrote:
>>> I don't like that your "stable-4" branch don't match the 4.0 branch in
>>> the kicad-source mirror.
>>> See:
>>> https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
>>> https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
>>>
>>> I think it would be better off if we could use the 4.0 branch from the
>>> kicad-source-mirror to base it on, and name the branch 4.0 as it was
>>> named before and everywhere else.
>>>
>>> Why did you suddenly start to name the banch "stable-"
>>>
>>> 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
 Thanks everyone for taking a look at this.  I just pushed the stable-4
 branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
 repo as obsolete when I get a chance.

 On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
>> Can someone please take a look at it you get a chance and make sure I
>> didn't make a mess of things before I push this to the main repo.
>
> Hi,
>
> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
>   https://code.launchpad.net/~stambaughw/kicad/4.0
>
> 1. empty directory packaging/linux/ is missing
>
>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
>   Is this directory needed ?
>
> 2. difference of commit logs
>
>   On lp_kicad_4, lines of logs are 6308.
>   $ bzr log --line | wc -l
>   6308
>
>   On git_stable4, 8181 logs exists.
>   $ git log --oneline | wc -l
>   8181
>
>   To see diffs, I created the log texts by these commands.
>
>   On lp_kicad_4,
>   $ bzr log --line | sed 's/^[0-9]*: .*
> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> | sed 's/^{.*} //' > ../bzr.txt
>
>   On git_stable4,
>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
>
>   Then look at the diffs,
>   $ diff -y bzr.txt git.txt | less
>
>   For example, diffs are like this.
>   
> 
>   ...
>   Pcbnew: fix potential issue (crash) when loading board filesPcbnew: 
> fix
>   [merge] OSX: back port touchpad support from development bran | OSX: 
> back po
> > Fix 
> 3d-viewe
> > Fix 
> touchpad
> > Add 
> support
>   OSX: legacy canvas rendering speed improvements.OSX: 
> legacy
>   ...
>   
> 
>
>   This diff referes to revno 6291.
>   It seems that git displays all the commit logs in 1 merge of bzr.
>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
>
>   I think these diffs of commit logs are not problem.
>
>
> After all, I think new git stable4 branch is right.
> And, thanks for all of your hard works.
>
> ___
> 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
>>
>>
>> ___
>> 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-devel

Re: [Kicad-developers] Git transition

[Chris Pavlina]

I'll fix it.

On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
> Are saying that Niki's branch is different?  When I was asking about a
> git version of the stable branch, why didn't you say something?  I
> didn't even see that there was another branch in the mirror on github.
> I agree that it should match the mirror assuming the mirror is up to
> date with the bzr stable 4 branch.  What do I need to fix this?  If
> someone else wants to step up to the plate and fix this, I'm fine with
> that.  I'm busy trying to get my own work done and my patience with the
> git transition is wearing thin.
> 
> On 8/24/2016 4:35 PM, Nick Østergaard wrote:
> > I don't like that your "stable-4" branch don't match the 4.0 branch in
> > the kicad-source mirror.
> > See:
> > https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
> > https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
> > 
> > I think it would be better off if we could use the 4.0 branch from the
> > kicad-source-mirror to base it on, and name the branch 4.0 as it was
> > named before and everywhere else.
> > 
> > Why did you suddenly start to name the banch "stable-"
> > 
> > 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
> >> Thanks everyone for taking a look at this.  I just pushed the stable-4
> >> branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
> >> repo as obsolete when I get a chance.
> >>
> >> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
>  Can someone please take a look at it you get a chance and make sure I
>  didn't make a mess of things before I push this to the main repo.
> >>>
> >>> Hi,
> >>>
> >>> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
> >>>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
> >>>   https://code.launchpad.net/~stambaughw/kicad/4.0
> >>>
> >>> 1. empty directory packaging/linux/ is missing
> >>>
> >>>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
> >>>   Is this directory needed ?
> >>>
> >>> 2. difference of commit logs
> >>>
> >>>   On lp_kicad_4, lines of logs are 6308.
> >>>   $ bzr log --line | wc -l
> >>>   6308
> >>>
> >>>   On git_stable4, 8181 logs exists.
> >>>   $ git log --oneline | wc -l
> >>>   8181
> >>>
> >>>   To see diffs, I created the log texts by these commands.
> >>>
> >>>   On lp_kicad_4,
> >>>   $ bzr log --line | sed 's/^[0-9]*: .*
> >>> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> >>> | sed 's/^{.*} //' > ../bzr.txt
> >>>
> >>>   On git_stable4,
> >>>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
> >>>
> >>>   Then look at the diffs,
> >>>   $ diff -y bzr.txt git.txt | less
> >>>
> >>>   For example, diffs are like this.
> >>>   
> >>> 
> >>>   ...
> >>>   Pcbnew: fix potential issue (crash) when loading board filesPcbnew: 
> >>> fix
> >>>   [merge] OSX: back port touchpad support from development bran | OSX: 
> >>> back po
> >>> > Fix 
> >>> 3d-viewe
> >>> > Fix 
> >>> touchpad
> >>> > Add 
> >>> support
> >>>   OSX: legacy canvas rendering speed improvements.OSX: 
> >>> legacy
> >>>   ...
> >>>   
> >>> 
> >>>
> >>>   This diff referes to revno 6291.
> >>>   It seems that git displays all the commit logs in 1 merge of bzr.
> >>>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
> >>>
> >>>   I think these diffs of commit logs are not problem.
> >>>
> >>>
> >>> After all, I think new git stable4 branch is right.
> >>> And, thanks for all of your hard works.
> >>>
> >>> ___
> >>> 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
> 
> 
> ___
> 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-d

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

Are saying that Niki's branch is different?  When I was asking about a
git version of the stable branch, why didn't you say something?  I
didn't even see that there was another branch in the mirror on github.
I agree that it should match the mirror assuming the mirror is up to
date with the bzr stable 4 branch.  What do I need to fix this?  If
someone else wants to step up to the plate and fix this, I'm fine with
that.  I'm busy trying to get my own work done and my patience with the
git transition is wearing thin.

On 8/24/2016 4:35 PM, Nick Østergaard wrote:
> I don't like that your "stable-4" branch don't match the 4.0 branch in
> the kicad-source mirror.
> See:
> https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
> https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059
> 
> I think it would be better off if we could use the 4.0 branch from the
> kicad-source-mirror to base it on, and name the branch 4.0 as it was
> named before and everywhere else.
> 
> Why did you suddenly start to name the banch "stable-"
> 
> 2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
>> Thanks everyone for taking a look at this.  I just pushed the stable-4
>> branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
>> repo as obsolete when I get a chance.
>>
>> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
 Can someone please take a look at it you get a chance and make sure I
 didn't make a mess of things before I push this to the main repo.
>>>
>>> Hi,
>>>
>>> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
>>>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
>>>   https://code.launchpad.net/~stambaughw/kicad/4.0
>>>
>>> 1. empty directory packaging/linux/ is missing
>>>
>>>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
>>>   Is this directory needed ?
>>>
>>> 2. difference of commit logs
>>>
>>>   On lp_kicad_4, lines of logs are 6308.
>>>   $ bzr log --line | wc -l
>>>   6308
>>>
>>>   On git_stable4, 8181 logs exists.
>>>   $ git log --oneline | wc -l
>>>   8181
>>>
>>>   To see diffs, I created the log texts by these commands.
>>>
>>>   On lp_kicad_4,
>>>   $ bzr log --line | sed 's/^[0-9]*: .*
>>> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
>>> | sed 's/^{.*} //' > ../bzr.txt
>>>
>>>   On git_stable4,
>>>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
>>>
>>>   Then look at the diffs,
>>>   $ diff -y bzr.txt git.txt | less
>>>
>>>   For example, diffs are like this.
>>>   
>>> 
>>>   ...
>>>   Pcbnew: fix potential issue (crash) when loading board filesPcbnew: 
>>> fix
>>>   [merge] OSX: back port touchpad support from development bran | OSX: back 
>>> po
>>> > Fix 
>>> 3d-viewe
>>> > Fix 
>>> touchpad
>>> > Add 
>>> support
>>>   OSX: legacy canvas rendering speed improvements.OSX: 
>>> legacy
>>>   ...
>>>   
>>> 
>>>
>>>   This diff referes to revno 6291.
>>>   It seems that git displays all the commit logs in 1 merge of bzr.
>>>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
>>>
>>>   I think these diffs of commit logs are not problem.
>>>
>>>
>>> After all, I think new git stable4 branch is right.
>>> And, thanks for all of your hard works.
>>>
>>> ___
>>> 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


___
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] Git transition

[Niki Guldbrand]

Hi Wayne.

I have had a little chat with Nick about github 4.0 and my 4.0.x
branch, and now that 4.0 has been updated to the latest, I would
suggest using the 4.0 branch from the KiCAD github mirror instead, as
my branch branches of from master at an much earlier point than 4.0, so
4.0 shares more common commits with master than my branch does.

If you want to keep it in the launchpad stable-4 branch, you have to do
a forced update by doing somthing like:

git push  +:

The important part is the "+" in the refspec, which will tell git to
force the update, so when I have done a rebase on one of my branches,
my develop branch in this example, I run the following to force the
update of my develop branch in my repo:

git push github +develop:develop

If you rename the branch to you can delete the unused branch in
launchpad via git push, see the -d option.


On tir, 2016-08-23 at 13:39 -0400, Wayne Stambaugh wrote:
> Thanks everyone for taking a look at this.  I just pushed the stable-
> 4
> branch to lp:kicad so we should be synced up.  I'll tag the bzr
> stable 4
> repo as obsolete when I get a chance.
> 
> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
> > 
> > > 
> > > Can someone please take a look at it you get a chance and make
> > > sure I
> > > didn't make a mess of things before I push this to the main repo.
> > 
> > Hi,
> > 
> > I compared the new git stable-4 repository and old bzr
> > lp:kicad/4.0.
> >   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
> >   https://code.launchpad.net/~stambaughw/kicad/4.0
> > 
> > 1. empty directory packaging/linux/ is missing
> > 
> >   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
> >   Is this directory needed ?
> > 
> > 2. difference of commit logs
> > 
> >   On lp_kicad_4, lines of logs are 6308.
> >   $ bzr log --line | wc -l
> >   6308
> > 
> >   On git_stable4, 8181 logs exists.
> >   $ git log --oneline | wc -l
> >   8181
> > 
> >   To see diffs, I created the log texts by these commands.
> > 
> >   On lp_kicad_4,
> >   $ bzr log --line | sed 's/^[0-9]*: .*
> > [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> > | sed 's/^{.*} //' > ../bzr.txt
> > 
> >   On git_stable4,
> >   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
> > 
> >   Then look at the diffs,
> >   $ diff -y bzr.txt git.txt | less
> > 
> >   For example, diffs are like this.
> >  
> > ===
> > =
> >   ...
> >   Pcbnew: fix potential issue (crash) when loading board
> > filesPcbnew: fix
> >   [merge] OSX: back port touchpad support from development bran |
> > OSX: back po
> > >
> > Fix 3d-viewe
> > >
> > Fix touchpad
> > >
> > Add support
> >   OSX: legacy canvas rendering speed
> > improvements.OSX: legacy
> >   ...
> >  
> > ===
> > =
> > 
> >   This diff referes to revno 6291.
> >   It seems that git displays all the commit logs in 1 merge of bzr.
> >   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
> > 
> >   I think these diffs of commit logs are not problem.
> > 
> > 
> > After all, I think new git stable4 branch is right.
> > And, thanks for all of your hard works.
> > 
> > ___
> > 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


___
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] Git transition

[Nick Østergaard]

I don't like that your "stable-4" branch don't match the 4.0 branch in
the kicad-source mirror.
See:
https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059

I think it would be better off if we could use the 4.0 branch from the
kicad-source-mirror to base it on, and name the branch 4.0 as it was
named before and everywhere else.

Why did you suddenly start to name the banch "stable-"

2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
> Thanks everyone for taking a look at this.  I just pushed the stable-4
> branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
> repo as obsolete when I get a chance.
>
> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
>>> Can someone please take a look at it you get a chance and make sure I
>>> didn't make a mess of things before I push this to the main repo.
>>
>> Hi,
>>
>> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
>>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
>>   https://code.launchpad.net/~stambaughw/kicad/4.0
>>
>> 1. empty directory packaging/linux/ is missing
>>
>>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
>>   Is this directory needed ?
>>
>> 2. difference of commit logs
>>
>>   On lp_kicad_4, lines of logs are 6308.
>>   $ bzr log --line | wc -l
>>   6308
>>
>>   On git_stable4, 8181 logs exists.
>>   $ git log --oneline | wc -l
>>   8181
>>
>>   To see diffs, I created the log texts by these commands.
>>
>>   On lp_kicad_4,
>>   $ bzr log --line | sed 's/^[0-9]*: .*
>> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
>> | sed 's/^{.*} //' > ../bzr.txt
>>
>>   On git_stable4,
>>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
>>
>>   Then look at the diffs,
>>   $ diff -y bzr.txt git.txt | less
>>
>>   For example, diffs are like this.
>>   
>> 
>>   ...
>>   Pcbnew: fix potential issue (crash) when loading board filesPcbnew: fix
>>   [merge] OSX: back port touchpad support from development bran | OSX: back 
>> po
>> > Fix 
>> 3d-viewe
>> > Fix 
>> touchpad
>> > Add support
>>   OSX: legacy canvas rendering speed improvements.OSX: legacy
>>   ...
>>   
>> 
>>
>>   This diff referes to revno 6291.
>>   It seems that git displays all the commit logs in 1 merge of bzr.
>>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
>>
>>   I think these diffs of commit logs are not problem.
>>
>>
>> After all, I think new git stable4 branch is right.
>> And, thanks for all of your hard works.
>>
>> ___
>> 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

___
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] Git transition

[Eldar Khayrullin]

Form like now:
lp:id
not supported with the terminal. It will be usefull to use form like 
"LP: #id".


В Среда, 24 авг. 2016 в 8:08 , Eldar Khayrullin 
 написал:

Launchpad supports link messages to bugs like this:
LP: #id
P.S. and in the terminal in Ubuntu this msg is the link too.

В Пятница, 12 авг. 2016 в 10:34 , Wayne Stambaugh 
 написал:

On 8/11/2016 11:28 AM, Chris Pavlina wrote:
 I stand by my recommendation to use a "Fixes: lp:n" on a line 
by
 itself. This is _established convention_ in git commit messages. A 
quick
 example from the Linux kernel tree has Reported-by, Requested-by, 
Cc,

 Signed-off-by all formatted in this way.

 Come on... it's established convention already, use it. We don't 
have to

 be different for the sake of it.


It's an established convention for the linux kernel develpers not 
kicad
developers.  I'm all for adding this information to the commit 
message.
I looked at Orson's web hook and this is all we need for it to link 
the

bug reports to the commit.  Let's go with "Fixes: lp:###" as a
separate line in the commit message and see how it goes.  If we have
issues, we can adjust accordingly.



 lp: without "Fixes" may not be obvious at first glance to 
people

 unfamiliar with our conventions.

 On Thu, Aug 11, 2016 at 04:09:11PM +0200, Nick Østergaard wrote:
 Den 11/08/2016 11.18 skrev "Maciej Sumiński" 
:


 On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:

 On 8/10/2016 5:02 AM, Maciej Sumiński wrote:

 On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
 The last time I looked, notifications of repo commits still 
were not
 implemented.  This is a show stopper for me.  I don't want to 
have to
 constantly grep the git commit log to see what changed.  If 
change
 notifications are working correctly, then I'm OK with moving 
forward

 on
 this if you can get the bug fix linking working.  We 
definitely should

 do some testing before we go live with this.


 I see there is an option to set notifications, in the same way 
as for
 the bazaar branches ("Edit your subscriptions" on the right 
side pane).
 I could not verify it, as likely I cannot receive 
notifications for the
 changes I introduce. Even if it does not work, I can implement 
it in my

 webhook.


 I spent some time yesterday creating my own git clone of kicad 
on LP and
 I noticed that the subscriptions that I need appear to be 
available for
 git repos so we shouldn't need any webhooks in for that unless 
they do

 not work.


 If they do not work, let me know and I will fix it in the hook.



 The webhook has reached beta stage. I have created a dummy 
project for
 testing purposes, where you can see a bug report [1] and a 
commit [2]
 with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" 
regex

 match.
 When it is detected, it automatically adds a message, changes 
the bug
 status and assignee. One thing that is not possible right now 
is

 linking
 with git branches, as apparently launchpad does not handle 
this at the
 moment (or I could not find the right format to specify a 
branch).


 Bug report linking is very important to me since I am 
responsible for
 the stable branch.  If there is no support for this yet, I'm OK 
with
 adding the bug report number to the first line of the commit 
message and
 the URL somewhere in the commit message body.  If I give the OK 
to use
 git, I will expect all developers that have commit privileges 
to the
 product repo to follow this without exception.  The commit 
message for

 bug report fixes must have this format:

 Description of bug report fix. (fixes lp:)

 * https://bugs.launchpad.net/kicad/+bug/

 If this is not acceptable, then the git transition will have to 
wait
 until Canonical gets git bug report linking implemented or 
Orson beats

 them to it.


 I spoke with a Launchpad developer and they have it already in 
their
 todo list. There is a plan to migrate Launchpad itself to git, 
so I

 believe they will do it well.

 From what I heard, currently it is possible to link git merge 
requests

 to bug reports, so it may temporarily solve the problem.

 All we need to do is to set a webhook pointing to my script 
[3]. If it
 is accepted, then I am going to create a separate lp account 
for the

 automated changes.

 Currently the webhook works on my home server which has a high 
uptime,
 but still it is not as reliable as dedicated servers. If there 
is
 someone willing to host it on a better machine, I will be 
pleased to

 help.


 If you are curious about the source code, then I can put it in 
the

 KiCad
 github (once I get a repository there) or just post it 
somewhere.


 I can create a repo on github or you can create a repo on 
launchpad.
 Either way is fine by me.  If you want to use github, let me 
know what
 name you want for the repo and your github user name and I will 
set up

 the repo and give you admin rights.


 I have just pushed the code to Launchpad [1] and consider it 
ready to
 go. There is also a 

Re: [Kicad-developers] Git transition

[kinichiro inoguchi]

Hi,

I hope mirror on GitHub keeps refreshing from new git repo on Launchpad.
https://github.com/KiCad/kicad-source-mirror

For GUI translators task,
we need to download source code tarball to obtain strings in the GUI.

On GitHub, we could download every committed rev as tarball by one click.
On Launchpad, it seems that only tagged rev can be downloaded.

If POT file for GUI is provided for every commits, maybe, GUI translators
do not need to access mirror, though.

Best regards
___
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] Git transition

[Wayne Stambaugh]

Thanks everyone for taking a look at this.  I just pushed the stable-4
branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
repo as obsolete when I get a chance.

On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
>> Can someone please take a look at it you get a chance and make sure I
>> didn't make a mess of things before I push this to the main repo.
> 
> Hi,
> 
> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
>   https://code.launchpad.net/~stambaughw/kicad/4.0
> 
> 1. empty directory packaging/linux/ is missing
> 
>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
>   Is this directory needed ?
> 
> 2. difference of commit logs
> 
>   On lp_kicad_4, lines of logs are 6308.
>   $ bzr log --line | wc -l
>   6308
> 
>   On git_stable4, 8181 logs exists.
>   $ git log --oneline | wc -l
>   8181
> 
>   To see diffs, I created the log texts by these commands.
> 
>   On lp_kicad_4,
>   $ bzr log --line | sed 's/^[0-9]*: .*
> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
> | sed 's/^{.*} //' > ../bzr.txt
> 
>   On git_stable4,
>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
> 
>   Then look at the diffs,
>   $ diff -y bzr.txt git.txt | less
> 
>   For example, diffs are like this.
>   
>   ...
>   Pcbnew: fix potential issue (crash) when loading board filesPcbnew: fix
>   [merge] OSX: back port touchpad support from development bran | OSX: back po
> > Fix 3d-viewe
> > Fix touchpad
> > Add support
>   OSX: legacy canvas rendering speed improvements.OSX: legacy
>   ...
>   
> 
>   This diff referes to revno 6291.
>   It seems that git displays all the commit logs in 1 merge of bzr.
>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
> 
>   I think these diffs of commit logs are not problem.
> 
> 
> After all, I think new git stable4 branch is right.
> And, thanks for all of your hard works.
> 
> ___
> 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

Re: [Kicad-developers] Git transition

[kinichiro inoguchi]

> Can someone please take a look at it you get a chance and make sure I
> didn't make a mess of things before I push this to the main repo.

Hi,

I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
  https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
  https://code.launchpad.net/~stambaughw/kicad/4.0

1. empty directory packaging/linux/ is missing

  I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
  Is this directory needed ?

2. difference of commit logs

  On lp_kicad_4, lines of logs are 6308.
  $ bzr log --line | wc -l
  6308

  On git_stable4, 8181 logs exists.
  $ git log --oneline | wc -l
  8181

  To see diffs, I created the log texts by these commands.

  On lp_kicad_4,
  $ bzr log --line | sed 's/^[0-9]*: .*
[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
| sed 's/^{.*} //' > ../bzr.txt

  On git_stable4,
  $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt

  Then look at the diffs,
  $ diff -y bzr.txt git.txt | less

  For example, diffs are like this.
  
  ...
  Pcbnew: fix potential issue (crash) when loading board filesPcbnew: fix
  [merge] OSX: back port touchpad support from development bran | OSX: back po
> Fix 3d-viewe
> Fix touchpad
> Add support
  OSX: legacy canvas rendering speed improvements.OSX: legacy
  ...
  

  This diff referes to revno 6291.
  It seems that git displays all the commit logs in 1 merge of bzr.
  http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291

  I think these diffs of commit logs are not problem.


After all, I think new git stable4 branch is right.
And, thanks for all of your hard works.

___
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] Git transition

[Chris Pavlina]

Looks good to me.

On Tue, Aug 23, 2016 at 11:15:39AM -0400, Wayne Stambaugh wrote:
> OK.  That was easy.  I pushed the changes to my personal repo on lp at
> 
> https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
> 
> Can someone please take a look at it you get a chance and make sure I
> didn't make a mess of things before I push this to the main repo.
> 
> Thanks everyone for the help.
> 
> Cheers,
> 
> Wayne
> 
> On 8/23/2016 10:45 AM, Niki Guldbrand wrote:
> > After you have create your local copy, you just push it to launchpad,
> > and then delete your local copy of my branch, then people will pull 4.0
> > from launchpad, then, i'm basically out of the picture, and I'll use
> > lauchpad as the source for stable as everybody else.
> > 
> > On tir, 2016-08-23 at 10:34 -0400, Wayne Stambaugh wrote:
> >> I don't think tracking you 4.0.x branch is what we want.  We want the
> >> main repo to be the source not someone's personal repo or am I not
> >> understanding how git works?
> >>
> >> On 8/23/2016 10:14 AM, Niki Guldbrand wrote:
> >>>
> >>> Hi Wayne.
> >>>
> >>> Just do run the following:
> >>>
> >>> git remote remove nikis-github-repo
> >>> git remote add --fetch --tags nikis-github-repo https://github.com/
> >>> nikgul/kicad-source-mirror.git
> >>> git checkout -b stable-4 nikis-github-repo/4.0.x
> >>>
> >>> And now you have a local branch named stable-4 that tracks my
> >>> remote
> >>> 4.0.x branch.
> >>>
> >>> On tir, 2016-08-23 at 09:00 -0400, Wayne Stambaugh wrote:
> 
>  Thanks Niki and Chris.  Now my ignorance of git will become
>  obvious.  I
>  just ran the following commands:
> 
>  git remote add nikis-github-repo
>  https://github.com/nikgul/kicad-source-mirror.git
> 
>  git checkout -b stable-4
> 
>  git pull nikis-github-repo 4.0.x
> 
>  and I'm getting conflicts on dozens files.  This can't be
>  right.  WTF
>  am
>  I doing wrong?  I just want to pull Niki's 4.0.x branch (which I
>  want
>  to
>  rename stable-4) into my local repo and push it to lp:kicad.
> 
>  On 8/22/2016 10:40 PM, Chris Pavlina wrote:
> >
> >
> > Looks good to me. Wayne, I'd probably just pull from this if I
> > were
> > you.
> >
> > On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:
> >>
> >>
> >> Hi Wayne.
> >>
> >> I have pushed an updated 4.0.x branch to github, please have
> >> a
> >> look and
> >> see if you can use it as is, or ... ?
> >>
> >>
> >> On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
> >>>
> >>>
> >>> I only need a snapshot of the current 4 stable branch r6308
> >>> tag
> >>> 4.0.4.
> >>> I'm the only one with commit access so I can guarantee it
> >>> wont
> >>> change.
> >>> If you update your stable 4 branch, I'll pull this into my
> >>> repo
> >>> and
> >>> then
> >>> push it to the kicad repo as the stable 4 branch and then
> >>> make
> >>> the
> >>> bzr
> >>> stable 4 repo read only.  The help would be greatly
> >>> appreciated.
> >>>
> >>> Thanks,
> >>>
> >>> Wayne
> >>>
> >>> On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
> 
> 
> 
>  Hi All.
> 
>  I Have a copy of 4.0.x in my git repo at github [1],
>  although
>  I
>  havent
>  updated it in som time, but the setup is still there, I
>  just
>  need
>  to
>  install the git bzr plugin again, and I can keep it
>  updated
>  for
>  some
>  time if you wish ?
> 
>  I also have an suggestion, that you might want to adopt
>  the
>  git
>  flow
>  development model, the github repo i [1] is setup for
>  that,
>  with
>  the
>  develop, and feature branches.
>  It currently contains 2 feature branches I was
>  considering
>  sending
>  patches in for.
> 
>  [1] https://github.com/nikgul/kicad-source-mirror
> >>
> >> -- 
> >> Niki Guldbrand 
> >>
> >> ___
> >> 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

OK.  That was easy.  I pushed the changes to my personal repo on lp at

https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev

Can someone please take a look at it you get a chance and make sure I
didn't make a mess of things before I push this to the main repo.

Thanks everyone for the help.

Cheers,

Wayne

On 8/23/2016 10:45 AM, Niki Guldbrand wrote:
> After you have create your local copy, you just push it to launchpad,
> and then delete your local copy of my branch, then people will pull 4.0
> from launchpad, then, i'm basically out of the picture, and I'll use
> lauchpad as the source for stable as everybody else.
> 
> On tir, 2016-08-23 at 10:34 -0400, Wayne Stambaugh wrote:
>> I don't think tracking you 4.0.x branch is what we want.  We want the
>> main repo to be the source not someone's personal repo or am I not
>> understanding how git works?
>>
>> On 8/23/2016 10:14 AM, Niki Guldbrand wrote:
>>>
>>> Hi Wayne.
>>>
>>> Just do run the following:
>>>
>>> git remote remove nikis-github-repo
>>> git remote add --fetch --tags nikis-github-repo https://github.com/
>>> nikgul/kicad-source-mirror.git
>>> git checkout -b stable-4 nikis-github-repo/4.0.x
>>>
>>> And now you have a local branch named stable-4 that tracks my
>>> remote
>>> 4.0.x branch.
>>>
>>> On tir, 2016-08-23 at 09:00 -0400, Wayne Stambaugh wrote:

 Thanks Niki and Chris.  Now my ignorance of git will become
 obvious.  I
 just ran the following commands:

 git remote add nikis-github-repo
 https://github.com/nikgul/kicad-source-mirror.git

 git checkout -b stable-4

 git pull nikis-github-repo 4.0.x

 and I'm getting conflicts on dozens files.  This can't be
 right.  WTF
 am
 I doing wrong?  I just want to pull Niki's 4.0.x branch (which I
 want
 to
 rename stable-4) into my local repo and push it to lp:kicad.

 On 8/22/2016 10:40 PM, Chris Pavlina wrote:
>
>
> Looks good to me. Wayne, I'd probably just pull from this if I
> were
> you.
>
> On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:
>>
>>
>> Hi Wayne.
>>
>> I have pushed an updated 4.0.x branch to github, please have
>> a
>> look and
>> see if you can use it as is, or ... ?
>>
>>
>> On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
>>>
>>>
>>> I only need a snapshot of the current 4 stable branch r6308
>>> tag
>>> 4.0.4.
>>> I'm the only one with commit access so I can guarantee it
>>> wont
>>> change.
>>> If you update your stable 4 branch, I'll pull this into my
>>> repo
>>> and
>>> then
>>> push it to the kicad repo as the stable 4 branch and then
>>> make
>>> the
>>> bzr
>>> stable 4 repo read only.  The help would be greatly
>>> appreciated.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 8/22/2016 2:12 PM, Niki Guldbrand wrote:



 Hi All.

 I Have a copy of 4.0.x in my git repo at github [1],
 although
 I
 havent
 updated it in som time, but the setup is still there, I
 just
 need
 to
 install the git bzr plugin again, and I can keep it
 updated
 for
 some
 time if you wish ?

 I also have an suggestion, that you might want to adopt
 the
 git
 flow
 development model, the github repo i [1] is setup for
 that,
 with
 the
 develop, and feature branches.
 It currently contains 2 feature branches I was
 considering
 sending
 patches in for.

 [1] https://github.com/nikgul/kicad-source-mirror
>>
>> -- 
>> Niki Guldbrand 
>>
>> ___
>> 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

I don't think tracking you 4.0.x branch is what we want.  We want the
main repo to be the source not someone's personal repo or am I not
understanding how git works?

On 8/23/2016 10:14 AM, Niki Guldbrand wrote:
> Hi Wayne.
> 
> Just do run the following:
> 
> git remote remove nikis-github-repo
> git remote add --fetch --tags nikis-github-repo 
> https://github.com/nikgul/kicad-source-mirror.git
> git checkout -b stable-4 nikis-github-repo/4.0.x
> 
> And now you have a local branch named stable-4 that tracks my remote
> 4.0.x branch.
> 
> On tir, 2016-08-23 at 09:00 -0400, Wayne Stambaugh wrote:
>> Thanks Niki and Chris.  Now my ignorance of git will become
>> obvious.  I
>> just ran the following commands:
>>
>> git remote add nikis-github-repo
>> https://github.com/nikgul/kicad-source-mirror.git
>>
>> git checkout -b stable-4
>>
>> git pull nikis-github-repo 4.0.x
>>
>> and I'm getting conflicts on dozens files.  This can't be right.  WTF
>> am
>> I doing wrong?  I just want to pull Niki's 4.0.x branch (which I want
>> to
>> rename stable-4) into my local repo and push it to lp:kicad.
>>
>> On 8/22/2016 10:40 PM, Chris Pavlina wrote:
>>>
>>> Looks good to me. Wayne, I'd probably just pull from this if I were
>>> you.
>>>
>>> On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:

 Hi Wayne.

 I have pushed an updated 4.0.x branch to github, please have a
 look and
 see if you can use it as is, or ... ?


 On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
>
> I only need a snapshot of the current 4 stable branch r6308 tag
> 4.0.4.
> I'm the only one with commit access so I can guarantee it wont
> change.
> If you update your stable 4 branch, I'll pull this into my repo
> and
> then
> push it to the kicad repo as the stable 4 branch and then make
> the
> bzr
> stable 4 repo read only.  The help would be greatly
> appreciated.
>
> Thanks,
>
> Wayne
>
> On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
>>
>>
>> Hi All.
>>
>> I Have a copy of 4.0.x in my git repo at github [1], although
>> I
>> havent
>> updated it in som time, but the setup is still there, I just
>> need
>> to
>> install the git bzr plugin again, and I can keep it updated
>> for
>> some
>> time if you wish ?
>>
>> I also have an suggestion, that you might want to adopt the
>> git
>> flow
>> development model, the github repo i [1] is setup for that,
>> with
>> the
>> develop, and feature branches.
>> It currently contains 2 feature branches I was considering
>> sending
>> patches in for.
>>
>> [1] https://github.com/nikgul/kicad-source-mirror

 -- 
 Niki Guldbrand 

 ___
 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

Re: [Kicad-developers] Git transition

[Niki Guldbrand]

It was the kicad github mirror I used, and I'm regularely pulling from
it, and rebasing against it. And when I added the launchpad remote
about 30 min ago, git didn't fetch anything new.

The 4.0.x branch was made with the git-remote-bzr addon, which found an
common anchestor in the git tree and create 4.0.x from that.

On tir, 2016-08-23 at 10:29 -0400, Wayne Stambaugh wrote:
> What was your original clone source?  I cloned the mirror on github
> to
> create the new repo so if you cloned from that, there should be no
> difference unless you have manually updating them.
> 
> On 8/23/2016 10:23 AM, Niki Guldbrand wrote:
> > 
> > Hi Wayne.
> > 
> > My git repo contains all the tags from bzr all ready.


___
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] Git transition

[Niki Guldbrand]

After you have create your local copy, you just push it to launchpad,
and then delete your local copy of my branch, then people will pull 4.0
from launchpad, then, i'm basically out of the picture, and I'll use
lauchpad as the source for stable as everybody else.

On tir, 2016-08-23 at 10:34 -0400, Wayne Stambaugh wrote:
> I don't think tracking you 4.0.x branch is what we want.  We want the
> main repo to be the source not someone's personal repo or am I not
> understanding how git works?
> 
> On 8/23/2016 10:14 AM, Niki Guldbrand wrote:
> > 
> > Hi Wayne.
> > 
> > Just do run the following:
> > 
> > git remote remove nikis-github-repo
> > git remote add --fetch --tags nikis-github-repo https://github.com/
> > nikgul/kicad-source-mirror.git
> > git checkout -b stable-4 nikis-github-repo/4.0.x
> > 
> > And now you have a local branch named stable-4 that tracks my
> > remote
> > 4.0.x branch.
> > 
> > On tir, 2016-08-23 at 09:00 -0400, Wayne Stambaugh wrote:
> > > 
> > > Thanks Niki and Chris.  Now my ignorance of git will become
> > > obvious.  I
> > > just ran the following commands:
> > > 
> > > git remote add nikis-github-repo
> > > https://github.com/nikgul/kicad-source-mirror.git
> > > 
> > > git checkout -b stable-4
> > > 
> > > git pull nikis-github-repo 4.0.x
> > > 
> > > and I'm getting conflicts on dozens files.  This can't be
> > > right.  WTF
> > > am
> > > I doing wrong?  I just want to pull Niki's 4.0.x branch (which I
> > > want
> > > to
> > > rename stable-4) into my local repo and push it to lp:kicad.
> > > 
> > > On 8/22/2016 10:40 PM, Chris Pavlina wrote:
> > > > 
> > > > 
> > > > Looks good to me. Wayne, I'd probably just pull from this if I
> > > > were
> > > > you.
> > > > 
> > > > On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:
> > > > > 
> > > > > 
> > > > > Hi Wayne.
> > > > > 
> > > > > I have pushed an updated 4.0.x branch to github, please have
> > > > > a
> > > > > look and
> > > > > see if you can use it as is, or ... ?
> > > > > 
> > > > > 
> > > > > On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
> > > > > > 
> > > > > > 
> > > > > > I only need a snapshot of the current 4 stable branch r6308
> > > > > > tag
> > > > > > 4.0.4.
> > > > > > I'm the only one with commit access so I can guarantee it
> > > > > > wont
> > > > > > change.
> > > > > > If you update your stable 4 branch, I'll pull this into my
> > > > > > repo
> > > > > > and
> > > > > > then
> > > > > > push it to the kicad repo as the stable 4 branch and then
> > > > > > make
> > > > > > the
> > > > > > bzr
> > > > > > stable 4 repo read only.  The help would be greatly
> > > > > > appreciated.
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Wayne
> > > > > > 
> > > > > > On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Hi All.
> > > > > > > 
> > > > > > > I Have a copy of 4.0.x in my git repo at github [1],
> > > > > > > although
> > > > > > > I
> > > > > > > havent
> > > > > > > updated it in som time, but the setup is still there, I
> > > > > > > just
> > > > > > > need
> > > > > > > to
> > > > > > > install the git bzr plugin again, and I can keep it
> > > > > > > updated
> > > > > > > for
> > > > > > > some
> > > > > > > time if you wish ?
> > > > > > > 
> > > > > > > I also have an suggestion, that you might want to adopt
> > > > > > > the
> > > > > > > git
> > > > > > > flow
> > > > > > > development model, the github repo i [1] is setup for
> > > > > > > that,
> > > > > > > with
> > > > > > > the
> > > > > > > develop, and feature branches.
> > > > > > > It currently contains 2 feature branches I was
> > > > > > > considering
> > > > > > > sending
> > > > > > > patches in for.
> > > > > > > 
> > > > > > > [1] https://github.com/nikgul/kicad-source-mirror
> > > > > 
> > > > > -- 
> > > > > Niki Guldbrand 
> > > > > 
> > > > > ___
> > > > > 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

Re: [Kicad-developers] Git transition

[Niki Guldbrand]

Hi Wayne.

Just do run the following:

git remote remove nikis-github-repo
git remote add --fetch --tags nikis-github-repo 
https://github.com/nikgul/kicad-source-mirror.git
git checkout -b stable-4 nikis-github-repo/4.0.x

And now you have a local branch named stable-4 that tracks my remote
4.0.x branch.

On tir, 2016-08-23 at 09:00 -0400, Wayne Stambaugh wrote:
> Thanks Niki and Chris.  Now my ignorance of git will become
> obvious.  I
> just ran the following commands:
> 
> git remote add nikis-github-repo
> https://github.com/nikgul/kicad-source-mirror.git
> 
> git checkout -b stable-4
> 
> git pull nikis-github-repo 4.0.x
> 
> and I'm getting conflicts on dozens files.  This can't be right.  WTF
> am
> I doing wrong?  I just want to pull Niki's 4.0.x branch (which I want
> to
> rename stable-4) into my local repo and push it to lp:kicad.
> 
> On 8/22/2016 10:40 PM, Chris Pavlina wrote:
> > 
> > Looks good to me. Wayne, I'd probably just pull from this if I were
> > you.
> > 
> > On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:
> > > 
> > > Hi Wayne.
> > > 
> > > I have pushed an updated 4.0.x branch to github, please have a
> > > look and
> > > see if you can use it as is, or ... ?
> > > 
> > > 
> > > On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
> > > > 
> > > > I only need a snapshot of the current 4 stable branch r6308 tag
> > > > 4.0.4.
> > > > I'm the only one with commit access so I can guarantee it wont
> > > > change.
> > > > If you update your stable 4 branch, I'll pull this into my repo
> > > > and
> > > > then
> > > > push it to the kicad repo as the stable 4 branch and then make
> > > > the
> > > > bzr
> > > > stable 4 repo read only.  The help would be greatly
> > > > appreciated.
> > > > 
> > > > Thanks,
> > > > 
> > > > Wayne
> > > > 
> > > > On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
> > > > > 
> > > > > 
> > > > > Hi All.
> > > > > 
> > > > > I Have a copy of 4.0.x in my git repo at github [1], although
> > > > > I
> > > > > havent
> > > > > updated it in som time, but the setup is still there, I just
> > > > > need
> > > > > to
> > > > > install the git bzr plugin again, and I can keep it updated
> > > > > for
> > > > > some
> > > > > time if you wish ?
> > > > > 
> > > > > I also have an suggestion, that you might want to adopt the
> > > > > git
> > > > > flow
> > > > > development model, the github repo i [1] is setup for that,
> > > > > with
> > > > > the
> > > > > develop, and feature branches.
> > > > > It currently contains 2 feature branches I was considering
> > > > > sending
> > > > > patches in for.
> > > > > 
> > > > > [1] https://github.com/nikgul/kicad-source-mirror
> > > 
> > > -- 
> > > Niki Guldbrand 
> > > 
> > > ___
> > > 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

What was your original clone source?  I cloned the mirror on github to
create the new repo so if you cloned from that, there should be no
difference unless you have manually updating them.

On 8/23/2016 10:23 AM, Niki Guldbrand wrote:
> Hi Wayne.
> 
> My git repo contains all the tags from bzr all ready.
> 
> On tir, 2016-08-23 at 10:16 -0400, Wayne Stambaugh wrote:
>> It should.  Anyone on the kicad-product-committers team has write
>> access
>> to lp:kicad.  Since I need to figure out how to do this, I'll give it
>> one more try before I throw in the towel.  I just ran `git tag` and
>> there are no tags in our git repo.  I thought the bzr tags got
>> translated to git tags by the github mirror.  Apparently this is not
>> the
>> case which means that I will have to manually find the point where we
>> branched from bzr 4.0.0-rc1 in the git repo and create a branch from
>> that point.  From there, I should be able to pull Niki's 4.0.x branch
>> cleanly.  This is already becoming way more work than it needs to be.
>>
>> On 8/23/2016 10:06 AM, Chris Pavlina wrote:
>>>
>>> How about I just do this? I think it'll let me push new branches...
>>>
>>>
>>> On Aug 23, 2016 09:58, "Shane Burrell" >> > wrote:
>>>
>>> If you really trust the branch and aren't concerned about
>>> history
>>> (prolly messy anyways), just create a stable branch in your
>>> repo,
>>> and checkout a clean from the remote to overlay your stable
>>> branch
>>> and push that.  More of a replace than a merge.  That's likely
>>> the
>>> cleanest way to do it.  It would be good to create standard
>>> branches
>>> of develop, release etc as defined in the link sent earlier.  
>>>
>>> On Tue, Aug 23, 2016 at 9:42 AM, Mark Roszko >> .com
>>> > wrote:
>>>
>>> I forgot to add, if you trust the divergent branch (because
>>> I
>>> imagine
>>> its cherry-picked commits etc from master).
>>>
>>> Then just do a git checkout and specify niki's branch from
>>> the
>>> remote
>>> and a local branch name in the command line. Then push that
>>> branch.
>>> This will combine the two.
>>>
>>> ___
>>> 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
>>> 
>>>
>>>
>>>
>>> ___
>>> 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
> 

___
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] Git transition

[Niki Guldbrand]

Hi Wayne.

My git repo contains all the tags from bzr all ready.

On tir, 2016-08-23 at 10:16 -0400, Wayne Stambaugh wrote:
> It should.  Anyone on the kicad-product-committers team has write
> access
> to lp:kicad.  Since I need to figure out how to do this, I'll give it
> one more try before I throw in the towel.  I just ran `git tag` and
> there are no tags in our git repo.  I thought the bzr tags got
> translated to git tags by the github mirror.  Apparently this is not
> the
> case which means that I will have to manually find the point where we
> branched from bzr 4.0.0-rc1 in the git repo and create a branch from
> that point.  From there, I should be able to pull Niki's 4.0.x branch
> cleanly.  This is already becoming way more work than it needs to be.
> 
> On 8/23/2016 10:06 AM, Chris Pavlina wrote:
> > 
> > How about I just do this? I think it'll let me push new branches...
> > 
> > 
> > On Aug 23, 2016 09:58, "Shane Burrell"  > > wrote:
> > 
> > If you really trust the branch and aren't concerned about
> > history
> > (prolly messy anyways), just create a stable branch in your
> > repo,
> > and checkout a clean from the remote to overlay your stable
> > branch
> > and push that.  More of a replace than a merge.  That's likely
> > the
> > cleanest way to do it.  It would be good to create standard
> > branches
> > of develop, release etc as defined in the link sent earlier.  
> > 
> > On Tue, Aug 23, 2016 at 9:42 AM, Mark Roszko  > .com
> > > wrote:
> > 
> > I forgot to add, if you trust the divergent branch (because
> > I
> > imagine
> > its cherry-picked commits etc from master).
> > 
> > Then just do a git checkout and specify niki's branch from
> > the
> > remote
> > and a local branch name in the command line. Then push that
> > branch.
> > This will combine the two.
> > 
> > ___
> > 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
> > 
> > 
> > 
> > 
> > ___
> > 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


___
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] Git transition

[Wayne Stambaugh]

It should.  Anyone on the kicad-product-committers team has write access
to lp:kicad.  Since I need to figure out how to do this, I'll give it
one more try before I throw in the towel.  I just ran `git tag` and
there are no tags in our git repo.  I thought the bzr tags got
translated to git tags by the github mirror.  Apparently this is not the
case which means that I will have to manually find the point where we
branched from bzr 4.0.0-rc1 in the git repo and create a branch from
that point.  From there, I should be able to pull Niki's 4.0.x branch
cleanly.  This is already becoming way more work than it needs to be.

On 8/23/2016 10:06 AM, Chris Pavlina wrote:
> How about I just do this? I think it'll let me push new branches...
> 
> 
> On Aug 23, 2016 09:58, "Shane Burrell"  > wrote:
> 
> If you really trust the branch and aren't concerned about history
> (prolly messy anyways), just create a stable branch in your repo,
> and checkout a clean from the remote to overlay your stable branch
> and push that.  More of a replace than a merge.  That's likely the
> cleanest way to do it.  It would be good to create standard branches
> of develop, release etc as defined in the link sent earlier.  
> 
> On Tue, Aug 23, 2016 at 9:42 AM, Mark Roszko  > wrote:
> 
> I forgot to add, if you trust the divergent branch (because I
> imagine
> its cherry-picked commits etc from master).
> 
> Then just do a git checkout and specify niki's branch from the
> remote
> and a local branch name in the command line. Then push that branch.
> This will combine the two.
> 
> ___
> 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
> 
> 
> 
> 
> ___
> 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

Re: [Kicad-developers] Git transition

[Chris Pavlina]

How about I just do this? I think it'll let me push new branches...

On Aug 23, 2016 09:58, "Shane Burrell"  wrote:

> If you really trust the branch and aren't concerned about history (prolly
> messy anyways), just create a stable branch in your repo, and checkout a
> clean from the remote to overlay your stable branch and push that.  More of
> a replace than a merge.  That's likely the cleanest way to do it.  It would
> be good to create standard branches of develop, release etc as defined in
> the link sent earlier.
>
> On Tue, Aug 23, 2016 at 9:42 AM, Mark Roszko 
> wrote:
>
>> I forgot to add, if you trust the divergent branch (because I imagine
>> its cherry-picked commits etc from master).
>>
>> Then just do a git checkout and specify niki's branch from the remote
>> and a local branch name in the command line. Then push that branch.
>> This will combine the two.
>>
>> ___
>> 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
>
>
___
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] Git transition

[Shane Burrell]

If you really trust the branch and aren't concerned about history (prolly
messy anyways), just create a stable branch in your repo, and checkout a
clean from the remote to overlay your stable branch and push that.  More of
a replace than a merge.  That's likely the cleanest way to do it.  It would
be good to create standard branches of develop, release etc as defined in
the link sent earlier.

On Tue, Aug 23, 2016 at 9:42 AM, Mark Roszko  wrote:

> I forgot to add, if you trust the divergent branch (because I imagine
> its cherry-picked commits etc from master).
>
> Then just do a git checkout and specify niki's branch from the remote
> and a local branch name in the command line. Then push that branch.
> This will combine the two.
>
> ___
> 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

Re: [Kicad-developers] Git transition

[Mark Roszko]

I forgot to add, if you trust the divergent branch (because I imagine
its cherry-picked commits etc from master).

Then just do a git checkout and specify niki's branch from the remote
and a local branch name in the command line. Then push that branch.
This will combine the two.

___
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] Git transition

[Mark Roszko]

Niki's branch is out of sync from the launchpad git tree and
kicad-source-mirror .

The hashes are different, thus the history is different and so a
pull (which does a merge) won't end well.

___
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] Git transition

[Wayne Stambaugh]

Thanks Niki and Chris.  Now my ignorance of git will become obvious.  I
just ran the following commands:

git remote add nikis-github-repo
https://github.com/nikgul/kicad-source-mirror.git

git checkout -b stable-4

git pull nikis-github-repo 4.0.x

and I'm getting conflicts on dozens files.  This can't be right.  WTF am
I doing wrong?  I just want to pull Niki's 4.0.x branch (which I want to
rename stable-4) into my local repo and push it to lp:kicad.

On 8/22/2016 10:40 PM, Chris Pavlina wrote:
> Looks good to me. Wayne, I'd probably just pull from this if I were you.
> 
> On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:
>> Hi Wayne.
>>
>> I have pushed an updated 4.0.x branch to github, please have a look and
>> see if you can use it as is, or ... ?
>>
>>
>> On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
>>> I only need a snapshot of the current 4 stable branch r6308 tag
>>> 4.0.4.
>>> I'm the only one with commit access so I can guarantee it wont
>>> change.
>>> If you update your stable 4 branch, I'll pull this into my repo and
>>> then
>>> push it to the kicad repo as the stable 4 branch and then make the
>>> bzr
>>> stable 4 repo read only.  The help would be greatly appreciated.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 8/22/2016 2:12 PM, Niki Guldbrand wrote:

 Hi All.

 I Have a copy of 4.0.x in my git repo at github [1], although I
 havent
 updated it in som time, but the setup is still there, I just need
 to
 install the git bzr plugin again, and I can keep it updated for
 some
 time if you wish ?

 I also have an suggestion, that you might want to adopt the git
 flow
 development model, the github repo i [1] is setup for that, with
 the
 develop, and feature branches.
 It currently contains 2 feature branches I was considering sending
 patches in for.

 [1] https://github.com/nikgul/kicad-source-mirror
>>
>> -- 
>> Niki Guldbrand 
>>
>> ___
>> 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

Re: [Kicad-developers] Git transition

[Chris Pavlina]

Looks good to me. Wayne, I'd probably just pull from this if I were you.

On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:
> Hi Wayne.
> 
> I have pushed an updated 4.0.x branch to github, please have a look and
> see if you can use it as is, or ... ?
> 
> 
> On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
> > I only need a snapshot of the current 4 stable branch r6308 tag
> > 4.0.4.
> > I'm the only one with commit access so I can guarantee it wont
> > change.
> > If you update your stable 4 branch, I'll pull this into my repo and
> > then
> > push it to the kicad repo as the stable 4 branch and then make the
> > bzr
> > stable 4 repo read only.  The help would be greatly appreciated.
> > 
> > Thanks,
> > 
> > Wayne
> > 
> > On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
> > > 
> > > Hi All.
> > > 
> > > I Have a copy of 4.0.x in my git repo at github [1], although I
> > > havent
> > > updated it in som time, but the setup is still there, I just need
> > > to
> > > install the git bzr plugin again, and I can keep it updated for
> > > some
> > > time if you wish ?
> > > 
> > > I also have an suggestion, that you might want to adopt the git
> > > flow
> > > development model, the github repo i [1] is setup for that, with
> > > the
> > > develop, and feature branches.
> > > It currently contains 2 feature branches I was considering sending
> > > patches in for.
> > > 
> > > [1] https://github.com/nikgul/kicad-source-mirror
> 
> -- 
> Niki Guldbrand 
> 
> ___
> 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

Re: [Kicad-developers] Git transition

[Niki Guldbrand]

Hi Wayne.

I have pushed an updated 4.0.x branch to github, please have a look and
see if you can use it as is, or ... ?


On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
> I only need a snapshot of the current 4 stable branch r6308 tag
> 4.0.4.
> I'm the only one with commit access so I can guarantee it wont
> change.
> If you update your stable 4 branch, I'll pull this into my repo and
> then
> push it to the kicad repo as the stable 4 branch and then make the
> bzr
> stable 4 repo read only.  The help would be greatly appreciated.
> 
> Thanks,
> 
> Wayne
> 
> On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
> > 
> > Hi All.
> > 
> > I Have a copy of 4.0.x in my git repo at github [1], although I
> > havent
> > updated it in som time, but the setup is still there, I just need
> > to
> > install the git bzr plugin again, and I can keep it updated for
> > some
> > time if you wish ?
> > 
> > I also have an suggestion, that you might want to adopt the git
> > flow
> > development model, the github repo i [1] is setup for that, with
> > the
> > develop, and feature branches.
> > It currently contains 2 feature branches I was considering sending
> > patches in for.
> > 
> > [1] https://github.com/nikgul/kicad-source-mirror

-- 
Niki Guldbrand 

___
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] Git transition

[Wayne Stambaugh]

I only need a snapshot of the current 4 stable branch r6308 tag 4.0.4.
I'm the only one with commit access so I can guarantee it wont change.
If you update your stable 4 branch, I'll pull this into my repo and then
push it to the kicad repo as the stable 4 branch and then make the bzr
stable 4 repo read only.  The help would be greatly appreciated.

Thanks,

Wayne

On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
> Hi All.
> 
> I Have a copy of 4.0.x in my git repo at github [1], although I havent
> updated it in som time, but the setup is still there, I just need to
> install the git bzr plugin again, and I can keep it updated for some
> time if you wish ?
> 
> I also have an suggestion, that you might want to adopt the git flow
> development model, the github repo i [1] is setup for that, with the
> develop, and feature branches.
> It currently contains 2 feature branches I was considering sending
> patches in for.
> 
> [1] https://github.com/nikgul/kicad-source-mirror
> 
> 
> 
> On man, 2016-08-22 at 17:22 +0200, Nick Østergaard wrote:
>> FYI the guy syncing bzr to the kicad-source-mirror managed to make it
>> work. Although it seems like he only pushed the 4.0 branch once.
>> There is a 4.0 branch in that. (Sorry I don't remember his name
>> exactly now)
>>
>> Den 22/08/2016 16.34 skrev "Chris Pavlina" :
>>> I'm used to git repo surgery enough to make the branch - if nobody
>>> else
>>> does it before I get out of work tonight, I'll do it then.
>>>
>>> As Shane says it should be very easy though, assuming there's
>>> nothing
>>> funny going on.
>>>
>>> On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
 It should be really easy.  Create a branch and overlay stable 4
>>> branch via
 manual or checkout the hash mark you need and commit to branch. 
>>> I
 typically do a develop branch (bleeding edge) and branch of
>>> stable without
 any issues and created stable in same fashion the first time.

 On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh >> il.com>
 wrote:

> On 8/22/2016 10:13 AM, Chris Pavlina wrote:
>> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh
>>> wrote:
>>> On 8/22/2016 9:53 AM, Clemens Koller wrote:
 Hi, Wayne!

 On 2016-08-22 14:09, Wayne Stambaugh wrote:
> I wasn't planning on migrating the stable 4 branch to
>>> git.  I'm hoping
> there wont be too many more 4 stable releases so I'm not
>>> sure it's
> worth
> the effort.

 Ok, I was wondering...
 I was missing the stable branch, too - as well as all the
>>> tags of the
> old
 releases, etc. I personally don't need them, but it could
>>> be useful
 and interesting to get all former references (r6994, rev
>>> 6994,
> 4.0.0-rc...)
 migrated over to the git side once.
>>>
>>> My one gripe about git is the commit hash tags.  They really
>>> are not
>>> very user friendly.  The tags you mention above are all in 4
>>> stable
>>> branch so if you continue to use bzr for the stable 4
>>> branch, you should
>>> not have any issues.  I will tag future stable versions in
>>> git when we
>>> get to that point so you will be able to use git tags in the
>>> same
>>> manner.  I'm not sure how maintaining a stable branch in git
>>> is going to
>>> work.  I'm guessing that it will be a completely separate
>>> repo like we
>>> do with bzr but I'm going to worry about that when the time
>>> comes.
>>
>> Personally I would do a stable branch as a literal branch in
>>> git rather
>> than a repository. This makes it much easier to move code
>>> between the
>> branches - when you want to pull a commit onto stable, just
>>> 'git
>> checkout stable' and 'git cherry-pick 1234567'. Makes it easy
>>> for
>> developers to switch between them, as well - I would very
>>> much
>> appreciate stable being a proper branch as it would make
>>> developing
>> fixes on stable and forward-porting them to devel, as you
>>> said we
>> should, much simpler.
>>
>> I suspect most developers familiar with git will be strongly
>>> in favor of
>> this - it's how branches are meant to work in git. Fairly
>>> standard
>> workflow.
>>
>> Then just use tags to mark releases in the stable branch.
>>
>> Easy as pie. :)
>
> For future stable releases, this is fine but I don't think
>>> there is any
> easy way to reassemble the separate bzr stable 4 branch into a
>>> git
> branch that we could commit to the main development repo.  If
>>> someone
> knows of an easy way to do this or better yet actually creates
>>> the
> branch, I would be more that happy to start using git to track
>>> the
> stable 4 branch.
>
>>
>>>

 Regards,

 Clemens
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to  

Re: [Kicad-developers] Git transition

[Marco Ciampa]

On Mon, Aug 22, 2016 at 01:06:37PM -0400, Wayne Stambaugh wrote:
> I fine with keeping the github mirror.  Someone will have to change the
> url from the obsolete bzr repo to the new git repo.

Many many thanks to all of you.

I am not (really) a dev but I think that this transition and all other
suggestions are just wonderful.

I couldn't resist.

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
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] Git transition

[Niki Guldbrand]

Hi Again.

Forgot to provide a link to a description of the model, so here it is:
http://nvie.com/posts/a-successful-git-branching-model/



On man, 2016-08-22 at 20:12 +0200, Niki Guldbrand wrote:
> Hi All.
> 
> I Have a copy of 4.0.x in my git repo at github [1], although I
> havent
> updated it in som time, but the setup is still there, I just need to
> install the git bzr plugin again, and I can keep it updated for some
> time if you wish ?
> 
> I also have an suggestion, that you might want to adopt the git flow
> development model, the github repo i [1] is setup for that, with the
> develop, and feature branches.
> It currently contains 2 feature branches I was considering sending
> patches in for.
> 
> [1] https://github.com/nikgul/kicad-source-mirror
> 
> 
> 
> On man, 2016-08-22 at 17:22 +0200, Nick Østergaard wrote:
> > 
> > FYI the guy syncing bzr to the kicad-source-mirror managed to make
> > it
> > work. Although it seems like he only pushed the 4.0 branch once.
> > There is a 4.0 branch in that. (Sorry I don't remember his name
> > exactly now)
> > 
> > Den 22/08/2016 16.34 skrev "Chris Pavlina"  > >:
> > > 
> > > I'm used to git repo surgery enough to make the branch - if
> > > nobody
> > > else
> > > does it before I get out of work tonight, I'll do it then.
> > > 
> > > As Shane says it should be very easy though, assuming there's
> > > nothing
> > > funny going on.
> > > 
> > > On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
> > > > 
> > > > It should be really easy.  Create a branch and overlay stable 4
> > > branch via
> > > > 
> > > > manual or checkout the hash mark you need and commit to
> > > > branch. 
> > > I
> > > > 
> > > > typically do a develop branch (bleeding edge) and branch of
> > > stable without
> > > > 
> > > > any issues and created stable in same fashion the first time.
> > > > 
> > > > On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh  > > > ma
> > > il.com>
> > > > 
> > > > wrote:
> > > > 
> > > > > 
> > > > > On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> > > > > > 
> > > > > > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh
> > > wrote:
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > > > > > > 
> > > > > > > > Hi, Wayne!
> > > > > > > > 
> > > > > > > > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > > > > > > > > 
> > > > > > > > > I wasn't planning on migrating the stable 4 branch to
> > > git.  I'm hoping
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > there wont be too many more 4 stable releases so I'm
> > > > > > > > > not
> > > sure it's
> > > > 
> > > > > 
> > > > > worth
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > the effort.
> > > > > > > > 
> > > > > > > > Ok, I was wondering...
> > > > > > > > I was missing the stable branch, too - as well as all
> > > > > > > > the
> > > tags of the
> > > > 
> > > > > 
> > > > > old
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > releases, etc. I personally don't need them, but it
> > > > > > > > could
> > > be useful
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > and interesting to get all former references (r6994,
> > > > > > > > rev
> > > 6994,
> > > > 
> > > > > 
> > > > > 4.0.0-rc...)
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > migrated over to the git side once.
> > > > > > > 
> > > > > > > My one gripe about git is the commit hash tags.  They
> > > > > > > really
> > > are not
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > very user friendly.  The tags you mention above are all
> > > > > > > in 4
> > > stable
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > branch so if you continue to use bzr for the stable 4
> > > branch, you should
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > not have any issues.  I will tag future stable versions
> > > > > > > in
> > > git when we
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > get to that point so you will be able to use git tags in
> > > > > > > the
> > > same
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > manner.  I'm not sure how maintaining a stable branch in
> > > > > > > git
> > > is going to
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > work.  I'm guessing that it will be a completely separate
> > > repo like we
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > do with bzr but I'm going to worry about that when the
> > > > > > > time
> > > comes.
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Personally I would do a stable branch as a literal branch
> > > > > > in
> > > git rather
> > > > 
> > > > > 
> > > > > > 
> > > > > > than a repository. This makes it much easier to move code
> > > between the
> > > > 
> > > > > 
> > > > > > 
> > > > > > branches - when you want to pull a commit onto stable, just
> > > 'git
> 

Re: [Kicad-developers] Git transition

[Niki Guldbrand]

Hi All.

I Have a copy of 4.0.x in my git repo at github [1], although I havent
updated it in som time, but the setup is still there, I just need to
install the git bzr plugin again, and I can keep it updated for some
time if you wish ?

I also have an suggestion, that you might want to adopt the git flow
development model, the github repo i [1] is setup for that, with the
develop, and feature branches.
It currently contains 2 feature branches I was considering sending
patches in for.

[1] https://github.com/nikgul/kicad-source-mirror



On man, 2016-08-22 at 17:22 +0200, Nick Østergaard wrote:
> FYI the guy syncing bzr to the kicad-source-mirror managed to make it
> work. Although it seems like he only pushed the 4.0 branch once.
> There is a 4.0 branch in that. (Sorry I don't remember his name
> exactly now)
> 
> Den 22/08/2016 16.34 skrev "Chris Pavlina" :
> > I'm used to git repo surgery enough to make the branch - if nobody
> > else
> > does it before I get out of work tonight, I'll do it then.
> > 
> > As Shane says it should be very easy though, assuming there's
> > nothing
> > funny going on.
> > 
> > On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
> > > It should be really easy.  Create a branch and overlay stable 4
> > branch via
> > > manual or checkout the hash mark you need and commit to branch. 
> > I
> > > typically do a develop branch (bleeding edge) and branch of
> > stable without
> > > any issues and created stable in same fashion the first time.
> > >
> > > On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh  > il.com>
> > > wrote:
> > >
> > > > On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> > > > > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh
> > wrote:
> > > > >> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > > >>> Hi, Wayne!
> > > > >>>
> > > > >>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > > >  I wasn't planning on migrating the stable 4 branch to
> > git.  I'm hoping
> > > >  there wont be too many more 4 stable releases so I'm not
> > sure it's
> > > > worth
> > > >  the effort.
> > > > >>>
> > > > >>> Ok, I was wondering...
> > > > >>> I was missing the stable branch, too - as well as all the
> > tags of the
> > > > old
> > > > >>> releases, etc. I personally don't need them, but it could
> > be useful
> > > > >>> and interesting to get all former references (r6994, rev
> > 6994,
> > > > 4.0.0-rc...)
> > > > >>> migrated over to the git side once.
> > > > >>
> > > > >> My one gripe about git is the commit hash tags.  They really
> > are not
> > > > >> very user friendly.  The tags you mention above are all in 4
> > stable
> > > > >> branch so if you continue to use bzr for the stable 4
> > branch, you should
> > > > >> not have any issues.  I will tag future stable versions in
> > git when we
> > > > >> get to that point so you will be able to use git tags in the
> > same
> > > > >> manner.  I'm not sure how maintaining a stable branch in git
> > is going to
> > > > >> work.  I'm guessing that it will be a completely separate
> > repo like we
> > > > >> do with bzr but I'm going to worry about that when the time
> > comes.
> > > > >
> > > > > Personally I would do a stable branch as a literal branch in
> > git rather
> > > > > than a repository. This makes it much easier to move code
> > between the
> > > > > branches - when you want to pull a commit onto stable, just
> > 'git
> > > > > checkout stable' and 'git cherry-pick 1234567'. Makes it easy
> > for
> > > > > developers to switch between them, as well - I would very
> > much
> > > > > appreciate stable being a proper branch as it would make
> > developing
> > > > > fixes on stable and forward-porting them to devel, as you
> > said we
> > > > > should, much simpler.
> > > > >
> > > > > I suspect most developers familiar with git will be strongly
> > in favor of
> > > > > this - it's how branches are meant to work in git. Fairly
> > standard
> > > > > workflow.
> > > > >
> > > > > Then just use tags to mark releases in the stable branch.
> > > > >
> > > > > Easy as pie. :)
> > > >
> > > > For future stable releases, this is fine but I don't think
> > there is any
> > > > easy way to reassemble the separate bzr stable 4 branch into a
> > git
> > > > branch that we could commit to the main development repo.  If
> > someone
> > > > knows of an easy way to do this or better yet actually creates
> > the
> > > > branch, I would be more that happy to start using git to track
> > the
> > > > stable 4 branch.
> > > >
> > > > >
> > > > >>
> > > > >>>
> > > > >>> Regards,
> > > > >>>
> > > > >>> Clemens

-- 
Niki Guldbrand 

___
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] Git transition

[Wayne Stambaugh]

I fine with keeping the github mirror.  Someone will have to change the
url from the obsolete bzr repo to the new git repo.

On 8/22/2016 11:59 AM, Mark Roszko wrote:
> The github mirror is useful to keep because its usually far faster
> than launchpad and easier to deal with for personal development.
> 
> The benefit is that after someone does all their work on github, one
> can simply push it back to launchpad with zero issues by just adding
> another remote.
> 
> Bzr on the other hand, just pushing a branch back to launchpad could
> make it explode, heh.
> 

___
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] Git transition

[Eldar Khayrullin]

And need update the Wiki 
https://github.com/KiCad/kicad-source-mirror/wiki


В Понедельник, 22 авг. 2016 в 7:16 , Eldar Khayrullin 
 написал:

But need to close posibilities to create ISSUE or PR.

В Понедельник, 22 авг. 2016 в 6:59 , Mark Roszko 
 написал:

The github mirror is useful to keep because its usually far faster
than launchpad and easier to deal with for personal development.

The benefit is that after someone does all their work on github, one
can simply push it back to launchpad with zero issues by just adding
another remote.

Bzr on the other hand, just pushing a branch back to launchpad could
make it explode, heh.

___
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

Re: [Kicad-developers] Git transition

[Eldar Khayrullin]

But need to close posibilities to create ISSUE or PR.

В Понедельник, 22 авг. 2016 в 6:59 , Mark Roszko 
 написал:

The github mirror is useful to keep because its usually far faster
than launchpad and easier to deal with for personal development.

The benefit is that after someone does all their work on github, one
can simply push it back to launchpad with zero issues by just adding
another remote.

Bzr on the other hand, just pushing a branch back to launchpad could
make it explode, heh.

___
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

Re: [Kicad-developers] Git transition

[Mark Roszko]

The github mirror is useful to keep because its usually far faster
than launchpad and easier to deal with for personal development.

The benefit is that after someone does all their work on github, one
can simply push it back to launchpad with zero issues by just adding
another remote.

Bzr on the other hand, just pushing a branch back to launchpad could
make it explode, heh.

___
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] Git transition

[Eldar Khayrullin]

In launchpad git bug tagged in commit message like :
bug #id
Launchpad give a link to.

В Понедельник, 22 авг. 2016 в 6:38 , Wayne Stambaugh 
 написал:

I just tagged 4.0.4 so technically you can start creating packages
against it.  I'm not sure of the status of the doc, lib, and 
translation
repos.  I will try to make the announcement before I go out of town 
for

the weekend but I cannot promise that it will happen.

On 8/22/2016 10:50 AM, Adam Wolf wrote:

 This package dev is fine with you waiting a few days for 4.0.4, but
 let's not stretch out much more than that.

 On Mon, Aug 22, 2016 at 9:21 AM, Chris Pavlina 

 > wrote:

 On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
 > On 8/22/2016 9:53 AM, Clemens Koller wrote:
 > > Hi, Wayne!
 > >
 > > On 2016-08-22 14:09, Wayne Stambaugh wrote:
 > >> I wasn't planning on migrating the stable 4 branch to git. 
 I'm hoping
 > >> there wont be too many more 4 stable releases so I'm not 
sure it's worth

 > >> the effort.
 > >
 > > Ok, I was wondering...
 > > I was missing the stable branch, too - as well as all the 
tags of the old
 > > releases, etc. I personally don't need them, but it could 
be useful
 > > and interesting to get all former references (r6994, rev 
6994, 4.0.0-rc...)

 > > migrated over to the git side once.
 >
 > My one gripe about git is the commit hash tags.  They really 
are not
 > very user friendly.  The tags you mention above are all in 4 
stable
 > branch so if you continue to use bzr for the stable 4 branch, 
you should
 > not have any issues.  I will tag future stable versions in 
git when we
 > get to that point so you will be able to use git tags in the 
same
 > manner.  I'm not sure how maintaining a stable branch in git 
is going to
 > work.  I'm guessing that it will be a completely separate 
repo like we
 > do with bzr but I'm going to worry about that when the time 
comes.


 As for the hashes not being user-friendly...well, that's what 
tags are
 for! Commits aren't really sequential anyway, since you can do 
all sorts
 of weird stuff with branching and merging, so bzr's sequential 
numbers
 do start to fall apart once you do that. When you have code you 
think is

 ready for public release, tag it!

 We could even do a 'testing' series, where we move commits from 
devel
 that are mostly okay, and tag a testing 'release' roughly 
weekly or so
 with a simple incrementing version number - this would be a 
nice middle
 ground between stable, which honestly starts to get a bit 
stale, and

 devel which occasionally breaks.

 This could even then be used as a staging ground for things to 
be
 brought into the stable branch, allowing a somewhat smoother 
release

 cadence.

 Pardon me, I'm just daydreaming a bit... :)

 >
 > >
 > > Regards,
 > >
 > > Clemens
 > >
 > > ___
 > > 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
 

 ___
 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
___
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] Git transition

[Nick Østergaard]

Feel free to procrastinate the announcement.

Since it seems we will reuse the 4.0.3 doc, lib and i18n but I they have
not been retagged yet, it is ok to delay it half a day.  Alternately you
could make the announcement a draft and I can publish it when ready.

Den 22/08/2016 17.46 skrev "Wayne Stambaugh" :

> I just tagged 4.0.4 so technically you can start creating packages
> against it.  I'm not sure of the status of the doc, lib, and translation
> repos.  I will try to make the announcement before I go out of town for
> the weekend but I cannot promise that it will happen.
>
> On 8/22/2016 10:50 AM, Adam Wolf wrote:
> > This package dev is fine with you waiting a few days for 4.0.4, but
> > let's not stretch out much more than that.
> >
> > On Mon, Aug 22, 2016 at 9:21 AM, Chris Pavlina  > > wrote:
> >
> > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > > Hi, Wayne!
> > > >
> > > > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > > >> I wasn't planning on migrating the stable 4 branch to git.  I'm
> hoping
> > > >> there wont be too many more 4 stable releases so I'm not sure
> it's worth
> > > >> the effort.
> > > >
> > > > Ok, I was wondering...
> > > > I was missing the stable branch, too - as well as all the tags
> of the old
> > > > releases, etc. I personally don't need them, but it could be
> useful
> > > > and interesting to get all former references (r6994, rev 6994,
> 4.0.0-rc...)
> > > > migrated over to the git side once.
> > >
> > > My one gripe about git is the commit hash tags.  They really are
> not
> > > very user friendly.  The tags you mention above are all in 4 stable
> > > branch so if you continue to use bzr for the stable 4 branch, you
> should
> > > not have any issues.  I will tag future stable versions in git
> when we
> > > get to that point so you will be able to use git tags in the same
> > > manner.  I'm not sure how maintaining a stable branch in git is
> going to
> > > work.  I'm guessing that it will be a completely separate repo
> like we
> > > do with bzr but I'm going to worry about that when the time comes.
> >
> > As for the hashes not being user-friendly...well, that's what tags
> are
> > for! Commits aren't really sequential anyway, since you can do all
> sorts
> > of weird stuff with branching and merging, so bzr's sequential
> numbers
> > do start to fall apart once you do that. When you have code you
> think is
> > ready for public release, tag it!
> >
> > We could even do a 'testing' series, where we move commits from devel
> > that are mostly okay, and tag a testing 'release' roughly weekly or
> so
> > with a simple incrementing version number - this would be a nice
> middle
> > ground between stable, which honestly starts to get a bit stale, and
> > devel which occasionally breaks.
> >
> > This could even then be used as a staging ground for things to be
> > brought into the stable branch, allowing a somewhat smoother release
> > cadence.
> >
> > Pardon me, I'm just daydreaming a bit... :)
> >
> > >
> > > >
> > > > Regards,
> > > >
> > > > Clemens
> > > >
> > > > ___
> > > > 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
> > 
> >
> > ___
> > 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

I just tagged 4.0.4 so technically you can start creating packages
against it.  I'm not sure of the status of the doc, lib, and translation
repos.  I will try to make the announcement before I go out of town for
the weekend but I cannot promise that it will happen.

On 8/22/2016 10:50 AM, Adam Wolf wrote:
> This package dev is fine with you waiting a few days for 4.0.4, but
> let's not stretch out much more than that.
> 
> On Mon, Aug 22, 2016 at 9:21 AM, Chris Pavlina  > wrote:
> 
> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > Hi, Wayne!
> > >
> > > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > >> I wasn't planning on migrating the stable 4 branch to git.  I'm 
> hoping
> > >> there wont be too many more 4 stable releases so I'm not sure it's 
> worth
> > >> the effort.
> > >
> > > Ok, I was wondering...
> > > I was missing the stable branch, too - as well as all the tags of the 
> old
> > > releases, etc. I personally don't need them, but it could be useful
> > > and interesting to get all former references (r6994, rev 6994, 
> 4.0.0-rc...)
> > > migrated over to the git side once.
> >
> > My one gripe about git is the commit hash tags.  They really are not
> > very user friendly.  The tags you mention above are all in 4 stable
> > branch so if you continue to use bzr for the stable 4 branch, you should
> > not have any issues.  I will tag future stable versions in git when we
> > get to that point so you will be able to use git tags in the same
> > manner.  I'm not sure how maintaining a stable branch in git is going to
> > work.  I'm guessing that it will be a completely separate repo like we
> > do with bzr but I'm going to worry about that when the time comes.
> 
> As for the hashes not being user-friendly...well, that's what tags are
> for! Commits aren't really sequential anyway, since you can do all sorts
> of weird stuff with branching and merging, so bzr's sequential numbers
> do start to fall apart once you do that. When you have code you think is
> ready for public release, tag it!
> 
> We could even do a 'testing' series, where we move commits from devel
> that are mostly okay, and tag a testing 'release' roughly weekly or so
> with a simple incrementing version number - this would be a nice middle
> ground between stable, which honestly starts to get a bit stale, and
> devel which occasionally breaks.
> 
> This could even then be used as a staging ground for things to be
> brought into the stable branch, allowing a somewhat smoother release
> cadence.
> 
> Pardon me, I'm just daydreaming a bit... :)
> 
> >
> > >
> > > Regards,
> > >
> > > Clemens
> > >
> > > ___
> > > 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
> 
> 
> ___
> 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

Re: [Kicad-developers] Git transition

[Eldar Khayrullin]

Hello.
I think need to rename .bzrignore to .gitignore and to remove 
.gitconfig.
P.S. I don't know but I have issue with this one when I use 
~/.gitignore_global.


В Понедельник, 22 авг. 2016 в 5:36 , Wayne Stambaugh 
 написал:

Let me tag 4.0.4 first since I'm hoping to roll out another stable
release soonish.  I'll do this right now.  I can push this release 
back

a few days until we get the 4 stable branch merged into the main kicad
git repo.  Thanks for the help.  Anyone else object to this?  I'm
thinking about my package devs here.


On 8/22/2016 10:33 AM, Chris Pavlina wrote:
 I'm used to git repo surgery enough to make the branch - if nobody 
else

 does it before I get out of work tonight, I'll do it then.

 As Shane says it should be very easy though, assuming there's 
nothing

 funny going on.

 On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
 It should be really easy.  Create a branch and overlay stable 4 
branch via

 manual or checkout the hash mark you need and commit to branch.  I
 typically do a develop branch (bleeding edge) and branch of stable 
without

 any issues and created stable in same fashion the first time.

 On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh 


 wrote:


 On 8/22/2016 10:13 AM, Chris Pavlina wrote:

 On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:

 On 8/22/2016 9:53 AM, Clemens Koller wrote:

 Hi, Wayne!

 On 2016-08-22 14:09, Wayne Stambaugh wrote:
 I wasn't planning on migrating the stable 4 branch to git.  
I'm hoping
 there wont be too many more 4 stable releases so I'm not sure 
it's

 worth

 the effort.


 Ok, I was wondering...
 I was missing the stable branch, too - as well as all the tags 
of the

 old
 releases, etc. I personally don't need them, but it could be 
useful

 and interesting to get all former references (r6994, rev 6994,

 4.0.0-rc...)

 migrated over to the git side once.


 My one gripe about git is the commit hash tags.  They really 
are not
 very user friendly.  The tags you mention above are all in 4 
stable
 branch so if you continue to use bzr for the stable 4 branch, 
you should
 not have any issues.  I will tag future stable versions in git 
when we
 get to that point so you will be able to use git tags in the 
same
 manner.  I'm not sure how maintaining a stable branch in git is 
going to
 work.  I'm guessing that it will be a completely separate repo 
like we
 do with bzr but I'm going to worry about that when the time 
comes.


 Personally I would do a stable branch as a literal branch in git 
rather
 than a repository. This makes it much easier to move code 
between the

 branches - when you want to pull a commit onto stable, just 'git
 checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
 developers to switch between them, as well - I would very much
 appreciate stable being a proper branch as it would make 
developing

 fixes on stable and forward-porting them to devel, as you said we
 should, much simpler.

 I suspect most developers familiar with git will be strongly in 
favor of
 this - it's how branches are meant to work in git. Fairly 
standard

 workflow.

 Then just use tags to mark releases in the stable branch.

 Easy as pie. :)


 For future stable releases, this is fine but I don't think there 
is any

 easy way to reassemble the separate bzr stable 4 branch into a git
 branch that we could commit to the main development repo.  If 
someone

 knows of an easy way to do this or better yet actually creates the
 branch, I would be more that happy to start using git to track the
 stable 4 branch.







 Regards,

 Clemens

 ___
 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


 ___
 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
___
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] Git transition

[Nick Østergaard]

FYI the guy syncing bzr to the kicad-source-mirror managed to make it work.
Although it seems like he only pushed the 4.0 branch once. There is a 4.0
branch in that. (Sorry I don't remember his name exactly now)

Den 22/08/2016 16.34 skrev "Chris Pavlina" :

> I'm used to git repo surgery enough to make the branch - if nobody else
> does it before I get out of work tonight, I'll do it then.
>
> As Shane says it should be very easy though, assuming there's nothing
> funny going on.
>
> On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
> > It should be really easy.  Create a branch and overlay stable 4 branch
> via
> > manual or checkout the hash mark you need and commit to branch.  I
> > typically do a develop branch (bleeding edge) and branch of stable
> without
> > any issues and created stable in same fashion the first time.
> >
> > On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh 
> > wrote:
> >
> > > On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> > > > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > > >> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > >>> Hi, Wayne!
> > > >>>
> > > >>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > >  I wasn't planning on migrating the stable 4 branch to git.  I'm
> hoping
> > >  there wont be too many more 4 stable releases so I'm not sure it's
> > > worth
> > >  the effort.
> > > >>>
> > > >>> Ok, I was wondering...
> > > >>> I was missing the stable branch, too - as well as all the tags of
> the
> > > old
> > > >>> releases, etc. I personally don't need them, but it could be useful
> > > >>> and interesting to get all former references (r6994, rev 6994,
> > > 4.0.0-rc...)
> > > >>> migrated over to the git side once.
> > > >>
> > > >> My one gripe about git is the commit hash tags.  They really are not
> > > >> very user friendly.  The tags you mention above are all in 4 stable
> > > >> branch so if you continue to use bzr for the stable 4 branch, you
> should
> > > >> not have any issues.  I will tag future stable versions in git when
> we
> > > >> get to that point so you will be able to use git tags in the same
> > > >> manner.  I'm not sure how maintaining a stable branch in git is
> going to
> > > >> work.  I'm guessing that it will be a completely separate repo like
> we
> > > >> do with bzr but I'm going to worry about that when the time comes.
> > > >
> > > > Personally I would do a stable branch as a literal branch in git
> rather
> > > > than a repository. This makes it much easier to move code between the
> > > > branches - when you want to pull a commit onto stable, just 'git
> > > > checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
> > > > developers to switch between them, as well - I would very much
> > > > appreciate stable being a proper branch as it would make developing
> > > > fixes on stable and forward-porting them to devel, as you said we
> > > > should, much simpler.
> > > >
> > > > I suspect most developers familiar with git will be strongly in
> favor of
> > > > this - it's how branches are meant to work in git. Fairly standard
> > > > workflow.
> > > >
> > > > Then just use tags to mark releases in the stable branch.
> > > >
> > > > Easy as pie. :)
> > >
> > > For future stable releases, this is fine but I don't think there is any
> > > easy way to reassemble the separate bzr stable 4 branch into a git
> > > branch that we could commit to the main development repo.  If someone
> > > knows of an easy way to do this or better yet actually creates the
> > > branch, I would be more that happy to start using git to track the
> > > stable 4 branch.
> > >
> > > >
> > > >>
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> Clemens
> > > >>>
> > > >>> ___
> > > >>> 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
> > >
> > > ___
> > > 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
>
___
Mailing list: https://l

Re: [Kicad-developers] Git transition

[Adam Wolf]

This package dev is fine with you waiting a few days for 4.0.4, but let's
not stretch out much more than that.

On Mon, Aug 22, 2016 at 9:21 AM, Chris Pavlina 
wrote:

> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > Hi, Wayne!
> > >
> > > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > >> I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
> > >> there wont be too many more 4 stable releases so I'm not sure it's
> worth
> > >> the effort.
> > >
> > > Ok, I was wondering...
> > > I was missing the stable branch, too - as well as all the tags of the
> old
> > > releases, etc. I personally don't need them, but it could be useful
> > > and interesting to get all former references (r6994, rev 6994,
> 4.0.0-rc...)
> > > migrated over to the git side once.
> >
> > My one gripe about git is the commit hash tags.  They really are not
> > very user friendly.  The tags you mention above are all in 4 stable
> > branch so if you continue to use bzr for the stable 4 branch, you should
> > not have any issues.  I will tag future stable versions in git when we
> > get to that point so you will be able to use git tags in the same
> > manner.  I'm not sure how maintaining a stable branch in git is going to
> > work.  I'm guessing that it will be a completely separate repo like we
> > do with bzr but I'm going to worry about that when the time comes.
>
> As for the hashes not being user-friendly...well, that's what tags are
> for! Commits aren't really sequential anyway, since you can do all sorts
> of weird stuff with branching and merging, so bzr's sequential numbers
> do start to fall apart once you do that. When you have code you think is
> ready for public release, tag it!
>
> We could even do a 'testing' series, where we move commits from devel
> that are mostly okay, and tag a testing 'release' roughly weekly or so
> with a simple incrementing version number - this would be a nice middle
> ground between stable, which honestly starts to get a bit stale, and
> devel which occasionally breaks.
>
> This could even then be used as a staging ground for things to be
> brought into the stable branch, allowing a somewhat smoother release
> cadence.
>
> Pardon me, I'm just daydreaming a bit... :)
>
> >
> > >
> > > Regards,
> > >
> > > Clemens
> > >
> > > ___
> > > 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
>
> ___
> 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

Let me tag 4.0.4 first since I'm hoping to roll out another stable
release soonish.  I'll do this right now.  I can push this release back
a few days until we get the 4 stable branch merged into the main kicad
git repo.  Thanks for the help.  Anyone else object to this?  I'm
thinking about my package devs here.


On 8/22/2016 10:33 AM, Chris Pavlina wrote:
> I'm used to git repo surgery enough to make the branch - if nobody else
> does it before I get out of work tonight, I'll do it then.
> 
> As Shane says it should be very easy though, assuming there's nothing
> funny going on.
> 
> On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
>> It should be really easy.  Create a branch and overlay stable 4 branch via
>> manual or checkout the hash mark you need and commit to branch.  I
>> typically do a develop branch (bleeding edge) and branch of stable without
>> any issues and created stable in same fashion the first time.
>>
>> On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh 
>> wrote:
>>
>>> On 8/22/2016 10:13 AM, Chris Pavlina wrote:
 On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> On 8/22/2016 9:53 AM, Clemens Koller wrote:
>> Hi, Wayne!
>>
>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
>>> I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
>>> there wont be too many more 4 stable releases so I'm not sure it's
>>> worth
>>> the effort.
>>
>> Ok, I was wondering...
>> I was missing the stable branch, too - as well as all the tags of the
>>> old
>> releases, etc. I personally don't need them, but it could be useful
>> and interesting to get all former references (r6994, rev 6994,
>>> 4.0.0-rc...)
>> migrated over to the git side once.
>
> My one gripe about git is the commit hash tags.  They really are not
> very user friendly.  The tags you mention above are all in 4 stable
> branch so if you continue to use bzr for the stable 4 branch, you should
> not have any issues.  I will tag future stable versions in git when we
> get to that point so you will be able to use git tags in the same
> manner.  I'm not sure how maintaining a stable branch in git is going to
> work.  I'm guessing that it will be a completely separate repo like we
> do with bzr but I'm going to worry about that when the time comes.

 Personally I would do a stable branch as a literal branch in git rather
 than a repository. This makes it much easier to move code between the
 branches - when you want to pull a commit onto stable, just 'git
 checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
 developers to switch between them, as well - I would very much
 appreciate stable being a proper branch as it would make developing
 fixes on stable and forward-porting them to devel, as you said we
 should, much simpler.

 I suspect most developers familiar with git will be strongly in favor of
 this - it's how branches are meant to work in git. Fairly standard
 workflow.

 Then just use tags to mark releases in the stable branch.

 Easy as pie. :)
>>>
>>> For future stable releases, this is fine but I don't think there is any
>>> easy way to reassemble the separate bzr stable 4 branch into a git
>>> branch that we could commit to the main development repo.  If someone
>>> knows of an easy way to do this or better yet actually creates the
>>> branch, I would be more that happy to start using git to track the
>>> stable 4 branch.
>>>

>
>>
>> Regards,
>>
>> Clemens
>>
>> ___
>> 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
>>>
>>> ___
>>> 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

Re: [Kicad-developers] Git transition

[Chris Pavlina]

I'm used to git repo surgery enough to make the branch - if nobody else
does it before I get out of work tonight, I'll do it then.

As Shane says it should be very easy though, assuming there's nothing
funny going on.

On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
> It should be really easy.  Create a branch and overlay stable 4 branch via
> manual or checkout the hash mark you need and commit to branch.  I
> typically do a develop branch (bleeding edge) and branch of stable without
> any issues and created stable in same fashion the first time.
> 
> On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh 
> wrote:
> 
> > On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> > > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > >> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > >>> Hi, Wayne!
> > >>>
> > >>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
> >  I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
> >  there wont be too many more 4 stable releases so I'm not sure it's
> > worth
> >  the effort.
> > >>>
> > >>> Ok, I was wondering...
> > >>> I was missing the stable branch, too - as well as all the tags of the
> > old
> > >>> releases, etc. I personally don't need them, but it could be useful
> > >>> and interesting to get all former references (r6994, rev 6994,
> > 4.0.0-rc...)
> > >>> migrated over to the git side once.
> > >>
> > >> My one gripe about git is the commit hash tags.  They really are not
> > >> very user friendly.  The tags you mention above are all in 4 stable
> > >> branch so if you continue to use bzr for the stable 4 branch, you should
> > >> not have any issues.  I will tag future stable versions in git when we
> > >> get to that point so you will be able to use git tags in the same
> > >> manner.  I'm not sure how maintaining a stable branch in git is going to
> > >> work.  I'm guessing that it will be a completely separate repo like we
> > >> do with bzr but I'm going to worry about that when the time comes.
> > >
> > > Personally I would do a stable branch as a literal branch in git rather
> > > than a repository. This makes it much easier to move code between the
> > > branches - when you want to pull a commit onto stable, just 'git
> > > checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
> > > developers to switch between them, as well - I would very much
> > > appreciate stable being a proper branch as it would make developing
> > > fixes on stable and forward-porting them to devel, as you said we
> > > should, much simpler.
> > >
> > > I suspect most developers familiar with git will be strongly in favor of
> > > this - it's how branches are meant to work in git. Fairly standard
> > > workflow.
> > >
> > > Then just use tags to mark releases in the stable branch.
> > >
> > > Easy as pie. :)
> >
> > For future stable releases, this is fine but I don't think there is any
> > easy way to reassemble the separate bzr stable 4 branch into a git
> > branch that we could commit to the main development repo.  If someone
> > knows of an easy way to do this or better yet actually creates the
> > branch, I would be more that happy to start using git to track the
> > stable 4 branch.
> >
> > >
> > >>
> > >>>
> > >>> Regards,
> > >>>
> > >>> Clemens
> > >>>
> > >>> ___
> > >>> 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
> >
> > ___
> > 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
>> On 8/22/2016 9:53 AM, Clemens Koller wrote:
>>> Hi, Wayne!
>>>
>>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
 I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
 there wont be too many more 4 stable releases so I'm not sure it's worth
 the effort.
>>>
>>> Ok, I was wondering...
>>> I was missing the stable branch, too - as well as all the tags of the old
>>> releases, etc. I personally don't need them, but it could be useful
>>> and interesting to get all former references (r6994, rev 6994, 4.0.0-rc...)
>>> migrated over to the git side once.
>>
>> My one gripe about git is the commit hash tags.  They really are not
>> very user friendly.  The tags you mention above are all in 4 stable
>> branch so if you continue to use bzr for the stable 4 branch, you should
>> not have any issues.  I will tag future stable versions in git when we
>> get to that point so you will be able to use git tags in the same
>> manner.  I'm not sure how maintaining a stable branch in git is going to
>> work.  I'm guessing that it will be a completely separate repo like we
>> do with bzr but I'm going to worry about that when the time comes.
> 
> Personally I would do a stable branch as a literal branch in git rather
> than a repository. This makes it much easier to move code between the
> branches - when you want to pull a commit onto stable, just 'git
> checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
> developers to switch between them, as well - I would very much
> appreciate stable being a proper branch as it would make developing
> fixes on stable and forward-porting them to devel, as you said we
> should, much simpler.
> 
> I suspect most developers familiar with git will be strongly in favor of
> this - it's how branches are meant to work in git. Fairly standard
> workflow.
> 
> Then just use tags to mark releases in the stable branch.
> 
> Easy as pie. :)

For future stable releases, this is fine but I don't think there is any
easy way to reassemble the separate bzr stable 4 branch into a git
branch that we could commit to the main development repo.  If someone
knows of an easy way to do this or better yet actually creates the
branch, I would be more that happy to start using git to track the
stable 4 branch.

> 
>>
>>>
>>> Regards,
>>>
>>> Clemens
>>>
>>> ___
>>> 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

___
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] Git transition

[Shane Burrell]

It should be really easy.  Create a branch and overlay stable 4 branch via
manual or checkout the hash mark you need and commit to branch.  I
typically do a develop branch (bleeding edge) and branch of stable without
any issues and created stable in same fashion the first time.

On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh 
wrote:

> On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> >> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> >>> Hi, Wayne!
> >>>
> >>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
>  I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
>  there wont be too many more 4 stable releases so I'm not sure it's
> worth
>  the effort.
> >>>
> >>> Ok, I was wondering...
> >>> I was missing the stable branch, too - as well as all the tags of the
> old
> >>> releases, etc. I personally don't need them, but it could be useful
> >>> and interesting to get all former references (r6994, rev 6994,
> 4.0.0-rc...)
> >>> migrated over to the git side once.
> >>
> >> My one gripe about git is the commit hash tags.  They really are not
> >> very user friendly.  The tags you mention above are all in 4 stable
> >> branch so if you continue to use bzr for the stable 4 branch, you should
> >> not have any issues.  I will tag future stable versions in git when we
> >> get to that point so you will be able to use git tags in the same
> >> manner.  I'm not sure how maintaining a stable branch in git is going to
> >> work.  I'm guessing that it will be a completely separate repo like we
> >> do with bzr but I'm going to worry about that when the time comes.
> >
> > Personally I would do a stable branch as a literal branch in git rather
> > than a repository. This makes it much easier to move code between the
> > branches - when you want to pull a commit onto stable, just 'git
> > checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
> > developers to switch between them, as well - I would very much
> > appreciate stable being a proper branch as it would make developing
> > fixes on stable and forward-porting them to devel, as you said we
> > should, much simpler.
> >
> > I suspect most developers familiar with git will be strongly in favor of
> > this - it's how branches are meant to work in git. Fairly standard
> > workflow.
> >
> > Then just use tags to mark releases in the stable branch.
> >
> > Easy as pie. :)
>
> For future stable releases, this is fine but I don't think there is any
> easy way to reassemble the separate bzr stable 4 branch into a git
> branch that we could commit to the main development repo.  If someone
> knows of an easy way to do this or better yet actually creates the
> branch, I would be more that happy to start using git to track the
> stable 4 branch.
>
> >
> >>
> >>>
> >>> Regards,
> >>>
> >>> Clemens
> >>>
> >>> ___
> >>> 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
>
> ___
> 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

Re: [Kicad-developers] Git transition

[Chris Pavlina]

On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > Hi, Wayne!
> > 
> > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> >> I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
> >> there wont be too many more 4 stable releases so I'm not sure it's worth
> >> the effort.
> > 
> > Ok, I was wondering...
> > I was missing the stable branch, too - as well as all the tags of the old
> > releases, etc. I personally don't need them, but it could be useful
> > and interesting to get all former references (r6994, rev 6994, 4.0.0-rc...)
> > migrated over to the git side once.
> 
> My one gripe about git is the commit hash tags.  They really are not
> very user friendly.  The tags you mention above are all in 4 stable
> branch so if you continue to use bzr for the stable 4 branch, you should
> not have any issues.  I will tag future stable versions in git when we
> get to that point so you will be able to use git tags in the same
> manner.  I'm not sure how maintaining a stable branch in git is going to
> work.  I'm guessing that it will be a completely separate repo like we
> do with bzr but I'm going to worry about that when the time comes.

As for the hashes not being user-friendly...well, that's what tags are
for! Commits aren't really sequential anyway, since you can do all sorts
of weird stuff with branching and merging, so bzr's sequential numbers
do start to fall apart once you do that. When you have code you think is
ready for public release, tag it!

We could even do a 'testing' series, where we move commits from devel
that are mostly okay, and tag a testing 'release' roughly weekly or so
with a simple incrementing version number - this would be a nice middle
ground between stable, which honestly starts to get a bit stale, and
devel which occasionally breaks.

This could even then be used as a staging ground for things to be
brought into the stable branch, allowing a somewhat smoother release
cadence.

Pardon me, I'm just daydreaming a bit... :)

> 
> > 
> > Regards,
> > 
> > Clemens
> > 
> > ___
> > 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

___
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] Git transition

[Adam Wolf]

What Chris said is exactly what I'd ask for!

Adam Wolf

On Mon, Aug 22, 2016 at 9:13 AM, Chris Pavlina 
wrote:

> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > Hi, Wayne!
> > >
> > > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > >> I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
> > >> there wont be too many more 4 stable releases so I'm not sure it's
> worth
> > >> the effort.
> > >
> > > Ok, I was wondering...
> > > I was missing the stable branch, too - as well as all the tags of the
> old
> > > releases, etc. I personally don't need them, but it could be useful
> > > and interesting to get all former references (r6994, rev 6994,
> 4.0.0-rc...)
> > > migrated over to the git side once.
> >
> > My one gripe about git is the commit hash tags.  They really are not
> > very user friendly.  The tags you mention above are all in 4 stable
> > branch so if you continue to use bzr for the stable 4 branch, you should
> > not have any issues.  I will tag future stable versions in git when we
> > get to that point so you will be able to use git tags in the same
> > manner.  I'm not sure how maintaining a stable branch in git is going to
> > work.  I'm guessing that it will be a completely separate repo like we
> > do with bzr but I'm going to worry about that when the time comes.
>
> Personally I would do a stable branch as a literal branch in git rather
> than a repository. This makes it much easier to move code between the
> branches - when you want to pull a commit onto stable, just 'git
> checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
> developers to switch between them, as well - I would very much
> appreciate stable being a proper branch as it would make developing
> fixes on stable and forward-porting them to devel, as you said we
> should, much simpler.
>
> I suspect most developers familiar with git will be strongly in favor of
> this - it's how branches are meant to work in git. Fairly standard
> workflow.
>
> Then just use tags to mark releases in the stable branch.
>
> Easy as pie. :)
>
> >
> > >
> > > Regards,
> > >
> > > Clemens
> > >
> > > ___
> > > 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
>
> ___
> 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

Re: [Kicad-developers] Git transition

[Chris Pavlina]

On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > Hi, Wayne!
> > 
> > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> >> I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
> >> there wont be too many more 4 stable releases so I'm not sure it's worth
> >> the effort.
> > 
> > Ok, I was wondering...
> > I was missing the stable branch, too - as well as all the tags of the old
> > releases, etc. I personally don't need them, but it could be useful
> > and interesting to get all former references (r6994, rev 6994, 4.0.0-rc...)
> > migrated over to the git side once.
> 
> My one gripe about git is the commit hash tags.  They really are not
> very user friendly.  The tags you mention above are all in 4 stable
> branch so if you continue to use bzr for the stable 4 branch, you should
> not have any issues.  I will tag future stable versions in git when we
> get to that point so you will be able to use git tags in the same
> manner.  I'm not sure how maintaining a stable branch in git is going to
> work.  I'm guessing that it will be a completely separate repo like we
> do with bzr but I'm going to worry about that when the time comes.

Personally I would do a stable branch as a literal branch in git rather
than a repository. This makes it much easier to move code between the
branches - when you want to pull a commit onto stable, just 'git
checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
developers to switch between them, as well - I would very much
appreciate stable being a proper branch as it would make developing
fixes on stable and forward-porting them to devel, as you said we
should, much simpler.

I suspect most developers familiar with git will be strongly in favor of
this - it's how branches are meant to work in git. Fairly standard
workflow.

Then just use tags to mark releases in the stable branch.

Easy as pie. :)

> 
> > 
> > Regards,
> > 
> > Clemens
> > 
> > ___
> > 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

___
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] Git transition

[Wayne Stambaugh]

On 8/22/2016 9:53 AM, Clemens Koller wrote:
> Hi, Wayne!
> 
> On 2016-08-22 14:09, Wayne Stambaugh wrote:
>> I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
>> there wont be too many more 4 stable releases so I'm not sure it's worth
>> the effort.
> 
> Ok, I was wondering...
> I was missing the stable branch, too - as well as all the tags of the old
> releases, etc. I personally don't need them, but it could be useful
> and interesting to get all former references (r6994, rev 6994, 4.0.0-rc...)
> migrated over to the git side once.

My one gripe about git is the commit hash tags.  They really are not
very user friendly.  The tags you mention above are all in 4 stable
branch so if you continue to use bzr for the stable 4 branch, you should
not have any issues.  I will tag future stable versions in git when we
get to that point so you will be able to use git tags in the same
manner.  I'm not sure how maintaining a stable branch in git is going to
work.  I'm guessing that it will be a completely separate repo like we
do with bzr but I'm going to worry about that when the time comes.

> 
> Regards,
> 
> Clemens
> 
> ___
> 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

Re: [Kicad-developers] Git transition

[Clemens Koller]

Hi, Wayne!

On 2016-08-22 14:09, Wayne Stambaugh wrote:
> I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
> there wont be too many more 4 stable releases so I'm not sure it's worth
> the effort.

Ok, I was wondering...
I was missing the stable branch, too - as well as all the tags of the old
releases, etc. I personally don't need them, but it could be useful
and interesting to get all former references (r6994, rev 6994, 4.0.0-rc...)
migrated over to the git side once.

Regards,

Clemens

___
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] Git transition

[Wayne Stambaugh]

There is one issue.  I cannot associate series or milestone to a git
repo.  This means the nifty timeline on the summary page doesn't work.
If you click on the product-git series, you will find there is no repo
association like there was with the bzr product repo.  I don't know if
this something that hasn't been implemented yet by the LP folks or if
they are not going to bother.  I will ping them to see if I can get an
answer.  In the mean time you click on the code page to view the git repo.

On 8/22/2016 4:16 AM, Maciej Sumiński wrote:
> This is really excellent news! Thank you Wayne!
> The webhook is already set, let's fix a few bugs to see if it works.
> 
> Just to remind you, there is a git config file that should ease marking
> commits as bug fixes [1].
> 
> Cheers,
> Orson
> 
> 1. https://lists.launchpad.net/kicad-developers/msg25728.html
> 
> On 08/22/2016 01:34 AM, Wayne Stambaugh wrote:
>> Christmas in August has arrived!  I think.  I've switch the KiCad
>> project over to Git and the product branch (renamed product-git to avoid
>> conflict with the bzr product branch) seems to be up to date and ready
>> to go.  As with the product branch the product-git branch is owned by
>> the kicad-product-committers team so the same devs should be able to
>> push to the product-git branch.  Let me know if you have any issues.  As
>> for how this is all going to work as far as usage goes, that remains to
>> be seen.  In the short term, I expect that patches and branch merges
>> will be done as usual.  As for the level of support from LP for merging
>> and branching goes, I have no idea.  We will deal with the issues as
>> they arise.  You can clone the repo by using:
>>
>> git clone https://git.launchpad.net/kicad
>>
>> There is some useful info on configuring git for launchpad here:
>>
>> https://help.launchpad.net/Code/Git
>>
>> Do really need to keep the mirror on Github now that we are using Git?
>> If so, would someone please update the current mirror to point the url
>> above so the mirror is kept up to date.
>>
>> Thank you for your patience during the transition and happy version
>> controlling!
>>
>> Wayne
>>
>> On 8/21/2016 3:25 PM, Nick Østergaard wrote:
>>> 2016-08-21 20:26 GMT+02:00 Chris Pavlina :
 On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
>> [snip]
>
> To all my developers with commit access, please do not commit any
> changes to the product branch until further notice.  I am going to
> attempt to switch the project over to use git as the default vcs
> sometime later today and I don't want to have to resync from bzr to git
> during this transition.  I have no idea what issues I will run into so
> please be patient.  Hopefully things will go smoothly.  I will make the
> announcement once the git repo is online.  @Orson, since you are the one
> who drove this, I'm giving you the honor of being the goto guy in case
> things go side ways.  I just thought you should know. :).

 It's like Christmas!! :O

>>>
>>> Yeah, except there is no powder snow to roll around in because of pure
>>> happiness! (at least not where I am located)
>>>
>
> Cheers,
>
> Wayne
>
> ___
> 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
>>
>>
>> ___
>> 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

I wasn't planning on migrating the stable 4 branch to git.  I'm hoping
there wont be too many more 4 stable releases so I'm not sure it's worth
the effort.

On 8/21/2016 11:45 PM, kinichiro inoguchi wrote:
> Hi,
> Thanks for transitioning to git  !
> 
> Do you plan to move stable 4.0 blanch, too ?
> Mainly for GUI translation work, I  would like to check stable 4.0.
> If it remains in bzr, I will check the bzr stable 4.0 blanch.
> 
> Thanks a lot.
> 

___
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] Git transition

[Maciej Sumiński]

This is really excellent news! Thank you Wayne!
The webhook is already set, let's fix a few bugs to see if it works.

Just to remind you, there is a git config file that should ease marking
commits as bug fixes [1].

Cheers,
Orson

1. https://lists.launchpad.net/kicad-developers/msg25728.html

On 08/22/2016 01:34 AM, Wayne Stambaugh wrote:
> Christmas in August has arrived!  I think.  I've switch the KiCad
> project over to Git and the product branch (renamed product-git to avoid
> conflict with the bzr product branch) seems to be up to date and ready
> to go.  As with the product branch the product-git branch is owned by
> the kicad-product-committers team so the same devs should be able to
> push to the product-git branch.  Let me know if you have any issues.  As
> for how this is all going to work as far as usage goes, that remains to
> be seen.  In the short term, I expect that patches and branch merges
> will be done as usual.  As for the level of support from LP for merging
> and branching goes, I have no idea.  We will deal with the issues as
> they arise.  You can clone the repo by using:
> 
> git clone https://git.launchpad.net/kicad
> 
> There is some useful info on configuring git for launchpad here:
> 
> https://help.launchpad.net/Code/Git
> 
> Do really need to keep the mirror on Github now that we are using Git?
> If so, would someone please update the current mirror to point the url
> above so the mirror is kept up to date.
> 
> Thank you for your patience during the transition and happy version
> controlling!
> 
> Wayne
> 
> On 8/21/2016 3:25 PM, Nick Østergaard wrote:
>> 2016-08-21 20:26 GMT+02:00 Chris Pavlina :
>>> On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
> [snip]

 To all my developers with commit access, please do not commit any
 changes to the product branch until further notice.  I am going to
 attempt to switch the project over to use git as the default vcs
 sometime later today and I don't want to have to resync from bzr to git
 during this transition.  I have no idea what issues I will run into so
 please be patient.  Hopefully things will go smoothly.  I will make the
 announcement once the git repo is online.  @Orson, since you are the one
 who drove this, I'm giving you the honor of being the goto guy in case
 things go side ways.  I just thought you should know. :).
>>>
>>> It's like Christmas!! :O
>>>
>>
>> Yeah, except there is no powder snow to roll around in because of pure
>> happiness! (at least not where I am located)
>>

 Cheers,

 Wayne

 ___
 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
> 
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Git transition

[kinichiro inoguchi]

Hi,
Thanks for transitioning to git  !

Do you plan to move stable 4.0 blanch, too ?
Mainly for GUI translation work, I  would like to check stable 4.0.
If it remains in bzr, I will check the bzr stable 4.0 blanch.

Thanks a lot.
___
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] Git transition

[Cirilo Bernardo]

Thanks to everyone who worked on this issue.  I can't wait to be
able to bury bzr.  I was holding off on proposing a merge of OCE
related bits because I really needed git rebase and bzr just couldn't
deliver anything remotely useful.

- Cirilo

On Mon, Aug 22, 2016 at 9:34 AM, Wayne Stambaugh 
wrote:

> Christmas in August has arrived!  I think.  I've switch the KiCad
> project over to Git and the product branch (renamed product-git to avoid
> conflict with the bzr product branch) seems to be up to date and ready
> to go.  As with the product branch the product-git branch is owned by
> the kicad-product-committers team so the same devs should be able to
> push to the product-git branch.  Let me know if you have any issues.  As
> for how this is all going to work as far as usage goes, that remains to
> be seen.  In the short term, I expect that patches and branch merges
> will be done as usual.  As for the level of support from LP for merging
> and branching goes, I have no idea.  We will deal with the issues as
> they arise.  You can clone the repo by using:
>
> git clone https://git.launchpad.net/kicad
>
> There is some useful info on configuring git for launchpad here:
>
> https://help.launchpad.net/Code/Git
>
> Do really need to keep the mirror on Github now that we are using Git?
> If so, would someone please update the current mirror to point the url
> above so the mirror is kept up to date.
>
> Thank you for your patience during the transition and happy version
> controlling!
>
> Wayne
>
> On 8/21/2016 3:25 PM, Nick Østergaard wrote:
> > 2016-08-21 20:26 GMT+02:00 Chris Pavlina :
> >> On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
>  [snip]
> >>>
> >>> To all my developers with commit access, please do not commit any
> >>> changes to the product branch until further notice.  I am going to
> >>> attempt to switch the project over to use git as the default vcs
> >>> sometime later today and I don't want to have to resync from bzr to git
> >>> during this transition.  I have no idea what issues I will run into so
> >>> please be patient.  Hopefully things will go smoothly.  I will make the
> >>> announcement once the git repo is online.  @Orson, since you are the
> one
> >>> who drove this, I'm giving you the honor of being the goto guy in case
> >>> things go side ways.  I just thought you should know. :).
> >>
> >> It's like Christmas!! :O
> >>
> >
> > Yeah, except there is no powder snow to roll around in because of pure
> > happiness! (at least not where I am located)
> >
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> ___
> >>> 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
>
>
> ___
> 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

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

Christmas in August has arrived!  I think.  I've switch the KiCad
project over to Git and the product branch (renamed product-git to avoid
conflict with the bzr product branch) seems to be up to date and ready
to go.  As with the product branch the product-git branch is owned by
the kicad-product-committers team so the same devs should be able to
push to the product-git branch.  Let me know if you have any issues.  As
for how this is all going to work as far as usage goes, that remains to
be seen.  In the short term, I expect that patches and branch merges
will be done as usual.  As for the level of support from LP for merging
and branching goes, I have no idea.  We will deal with the issues as
they arise.  You can clone the repo by using:

git clone https://git.launchpad.net/kicad

There is some useful info on configuring git for launchpad here:

https://help.launchpad.net/Code/Git

Do really need to keep the mirror on Github now that we are using Git?
If so, would someone please update the current mirror to point the url
above so the mirror is kept up to date.

Thank you for your patience during the transition and happy version
controlling!

Wayne

On 8/21/2016 3:25 PM, Nick Østergaard wrote:
> 2016-08-21 20:26 GMT+02:00 Chris Pavlina :
>> On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
 [snip]
>>>
>>> To all my developers with commit access, please do not commit any
>>> changes to the product branch until further notice.  I am going to
>>> attempt to switch the project over to use git as the default vcs
>>> sometime later today and I don't want to have to resync from bzr to git
>>> during this transition.  I have no idea what issues I will run into so
>>> please be patient.  Hopefully things will go smoothly.  I will make the
>>> announcement once the git repo is online.  @Orson, since you are the one
>>> who drove this, I'm giving you the honor of being the goto guy in case
>>> things go side ways.  I just thought you should know. :).
>>
>> It's like Christmas!! :O
>>
> 
> Yeah, except there is no powder snow to roll around in because of pure
> happiness! (at least not where I am located)
> 
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> ___
>>> 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


___
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] Git transition

[Nick Østergaard]

2016-08-21 20:26 GMT+02:00 Chris Pavlina :
> On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
>> > [snip]
>>
>> To all my developers with commit access, please do not commit any
>> changes to the product branch until further notice.  I am going to
>> attempt to switch the project over to use git as the default vcs
>> sometime later today and I don't want to have to resync from bzr to git
>> during this transition.  I have no idea what issues I will run into so
>> please be patient.  Hopefully things will go smoothly.  I will make the
>> announcement once the git repo is online.  @Orson, since you are the one
>> who drove this, I'm giving you the honor of being the goto guy in case
>> things go side ways.  I just thought you should know. :).
>
> It's like Christmas!! :O
>

Yeah, except there is no powder snow to roll around in because of pure
happiness! (at least not where I am located)

>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> 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

___
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] Git transition

[Lorenzo Marcantonio]

On Sun, Aug 21, 2016 at 02:26:04PM -0400, Chris Pavlina wrote:

> It's like Christmas!! :O

Well *I* personally suck with both bzr and git since I am an svn user...

However bzr gave me a lot of problem (and still doesn't properly support
a proxy!) and in general I had less issues with projects using git.

All in all it should be an improvement!

-- 
Lorenzo Marcantonio


signature.asc
Description: PGP signature
___
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] Git transition

[Chris Pavlina]

On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
> > [snip]
> 
> To all my developers with commit access, please do not commit any
> changes to the product branch until further notice.  I am going to
> attempt to switch the project over to use git as the default vcs
> sometime later today and I don't want to have to resync from bzr to git
> during this transition.  I have no idea what issues I will run into so
> please be patient.  Hopefully things will go smoothly.  I will make the
> announcement once the git repo is online.  @Orson, since you are the one
> who drove this, I'm giving you the honor of being the goto guy in case
> things go side ways.  I just thought you should know. :).

It's like Christmas!! :O

> 
> Cheers,
> 
> Wayne
> 
> ___
> 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

Re: [Kicad-developers] Git transition

[Maciej Sumiński]

On 08/21/2016 05:30 PM, Wayne Stambaugh wrote:
[snip]
> To all my developers with commit access, please do not commit any
> changes to the product branch until further notice.  I am going to
> attempt to switch the project over to use git as the default vcs
> sometime later today and I don't want to have to resync from bzr to git
> during this transition.  I have no idea what issues I will run into so
> please be patient.  Hopefully things will go smoothly.  I will make the
> announcement once the git repo is online.  @Orson, since you are the one
> who drove this, I'm giving you the honor of being the goto guy in case
> things go side ways.  I just thought you should know. :).

Sir, yes sir! I keep my fingers crossed and await the result in
excitement. Let me know when it is up, so I will set the webhook for
managing the bug tracker.

Regards,
Orson

> Cheers,
> 
> Wayne
> 



signature.asc
Description: OpenPGP digital signature
___
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] Git transition

[Wayne Stambaugh]

On 8/12/2016 3:44 PM, Wayne Stambaugh wrote:
> On 8/12/2016 5:36 AM, Maciej Sumiński wrote:
>> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
>> [snip]
>>> I'll see if I can figure out how to do this and if it works we can use
>>> it instead of adding the bug report url to the commit message.  I wonder
>>> if we can link a commit to a bug report?  That could be an issue if we
>>> cannot.  I don't want to have to always create a separate branch, push
>>> it to my personal repo, and then merge it into the product branch for
>>> simple bug fixes.
>>
>> I already link commits to corresponding bug reports, see an example [1].
>>
>> To make life even easier, I have just pushed an additional git config
>> file (rev 7022). To enable it:
>>
>>   git config --add include.path "$(pwd)/helpers/git/fixes_alias"
>>
>> And afterwards:
>>
>>   
>>   git commit -a -m "Fixed a memleak"
>>   git fixes 123456
>>   git push
>>
>> In the current form it is a mix of what Wayne and Chris have suggested,
>> so in the end you will get:
>>
>> orson@pcbe15262 ~/workspace/kicad % git log -n1
>> commit 4ea4dcd67d89ce612aa1826dc845cc1137040fbf
>> Author: Maciej Suminski 
>> Date:   Fri Aug 12 11:34:06 2016 +0200
>>
>> Fixed a memleak
>>
>> Fixes: lp:123456
>> * https://bugs.launchpad.net/kicad/+bug/123456
>>
>> Regards,
>> Orson
>>
>> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1612107
>>
> 
> This appears to be just what we are looking for.  Thanks Orson!
> 
> Since I haven't heard anything from anyone besides Adam, I'm going to
> assume everyone is OK with going live with the git transition on 8/21.
> I will most likely make the bzr repo read only a few hours before I push
> the git repo and make it the product branch so if you have commit access
> please do not commit anything to the bzr repo on 8/21.  I will make an
> announcement as soon as I have it up and running.  I think I hear the
> "Hallelujah Chorus" in the background. ;)
> 

To all my developers with commit access, please do not commit any
changes to the product branch until further notice.  I am going to
attempt to switch the project over to use git as the default vcs
sometime later today and I don't want to have to resync from bzr to git
during this transition.  I have no idea what issues I will run into so
please be patient.  Hopefully things will go smoothly.  I will make the
announcement once the git repo is online.  @Orson, since you are the one
who drove this, I'm giving you the honor of being the goto guy in case
things go side ways.  I just thought you should know. :).

Cheers,

Wayne

___
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] Git transition

[Eldar Khayrullin]

I think git-SUM is something like that:
$ git log --oneline | wc -l

В Пятница, 12 авг. 2016 в 11:26 , Nick Østergaard 
 написал:

What do you mean with git-SUM, is that the bzrlike revno or is that
the short git sha1?

I personally like the way we have it now with the build date, the
bzrlike revno serial and the git sha1.

Or are you suggesting to do like (2016-08-03 2383bcf-6299)-product
instead of (2016-08-03 BZR 6299, Git 2383bcf)-product?

2016-08-12 21:37 GMT+02:00 Wayne Stambaugh :
 I'm OK with git-SUM rather than the obnoxiously long git rev 
numbers.

 Anyone object to this?

 On 8/12/2016 1:25 AM, Simon Wells wrote:
 In regards to this, Currently bzr revs are just the number and the 
git
 revs are the bzr number and the git sum. Is it worthwhile 
(esspeically

 in the title bar just changing this to git-BZRREV or just git-SUM
 since git will be the primary vcs?

 On Fri, Aug 12, 2016 at 7:55 AM, Adam Wolf
  wrote:

 Sounds good!  I think that timeline is fine.

 Adam Wolf


 On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh 
 wrote:


 You have a couple of options.

 You could just clone directly from the source mirror on github 
for
 testing then update the url when we go live with git on 
launchpad.


 You could create your own clone of the github source mirror and 
add a
 remote link to your own personal git branch on launchpad and use 
that
 for testing.  This is what I have been using.  The set the url 
to push

 to your own git repo on launchpad run:

 git remote add launchpad
 git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev

 git push launchpad (OPTIONAL-REPO-NAME-ON-LP)

 You will now have your own kicad git repo on launchpad which you 
can

 clone for testing.

 On 8/11/2016 3:36 PM, Adam Wolf wrote:
 It should.  Can we somehow push a copy of what it is now so I 
have

 something to build against?




___
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

Re: [Kicad-developers] Git transition

[Chris Pavlina]

On Fri, Aug 12, 2016 at 04:31:52PM -0400, Wayne Stambaugh wrote:
> [snip] I just want to do things because that's what all the
> cool kids are doing.  If it makes sense, then we should adopt it.  If
> not we should do what is appropriate for us.  In this case is seems to
> make sense.

We're only talking about commit message formatting here, not choosing a
version control system or host or anything like that... ;)

> 
> > 
> >> I'm all for adding this information to the commit message.
> >> I looked at Orson's web hook and this is all we need for it to link the
> >> bug reports to the commit.  Let's go with "Fixes: lp:###" as a
> >> separate line in the commit message and see how it goes.  If we have
> >> issues, we can adjust accordingly.
> >>
> >>>
> >>> lp: without "Fixes" may not be obvious at first glance to people
> >>> unfamiliar with our conventions.
> >>>
> >>> On Thu, Aug 11, 2016 at 04:09:11PM +0200, Nick Østergaard wrote:
>  Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
> >
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>  The last time I looked, notifications of repo commits still were not
>  implemented.  This is a show stopper for me.  I don't want to have to
>  constantly grep the git commit log to see what changed.  If change
>  notifications are working correctly, then I'm OK with moving forward
>  on
>  this if you can get the bug fix linking working.  We definitely 
>  should
>  do some testing before we go live with this.
> >>>
> >>> I see there is an option to set notifications, in the same way as for
> >>> the bazaar branches ("Edit your subscriptions" on the right side 
> >>> pane).
> >>> I could not verify it, as likely I cannot receive notifications for 
> >>> the
> >>> changes I introduce. Even if it does not work, I can implement it in 
> >>> my
> >>> webhook.
> >>
> >> I spent some time yesterday creating my own git clone of kicad on LP 
> >> and
> >> I noticed that the subscriptions that I need appear to be available for
> >> git repos so we shouldn't need any webhooks in for that unless they do
> >> not work.
> >
> > If they do not work, let me know and I will fix it in the hook.
> >
> >>>
> >>> The webhook has reached beta stage. I have created a dummy project for
> >>> testing purposes, where you can see a bug report [1] and a commit [2]
> >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
>  match.
> >>> When it is detected, it automatically adds a message, changes the bug
> >>> status and assignee. One thing that is not possible right now is
>  linking
> >>> with git branches, as apparently launchpad does not handle this at the
> >>> moment (or I could not find the right format to specify a branch).
> >>
> >> Bug report linking is very important to me since I am responsible for
> >> the stable branch.  If there is no support for this yet, I'm OK with
> >> adding the bug report number to the first line of the commit message 
> >> and
> >> the URL somewhere in the commit message body.  If I give the OK to use
> >> git, I will expect all developers that have commit privileges to the
> >> product repo to follow this without exception.  The commit message for
> >> bug report fixes must have this format:
> >>
> >> Description of bug report fix. (fixes lp:)
> >>
> >> * https://bugs.launchpad.net/kicad/+bug/
> >>
> >> If this is not acceptable, then the git transition will have to wait
> >> until Canonical gets git bug report linking implemented or Orson beats
> >> them to it.
> >
> > I spoke with a Launchpad developer and they have it already in their
> > todo list. There is a plan to migrate Launchpad itself to git, so I
> > believe they will do it well.
> >
> > From what I heard, currently it is possible to link git merge requests
> > to bug reports, so it may temporarily solve the problem.
> >
> >>> All we need to do is to set a webhook pointing to my script [3]. If it
> >>> is accepted, then I am going to create a separate lp account for the
> >>> automated changes.
> >>>
> >>> Currently the webhook works on my home server which has a high uptime,
> >>> but still it is not as reliable as dedicated servers. If there is
> >>> someone willing to host it on a better machine, I will be pleased to
>  help.
> >>>
> >>> If you are curious about the source code, then I can put it in the
>  KiCad
> >>> github (once I get a repository there) or just post it somewhere.
> >>
> >> I can create a repo on github or you can create a repo on launchpad.
> >> Either way is fine by me.  If you want to 

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

On 8/12/2016 4:30 PM, Chris Pavlina wrote:
> On Fri, Aug 12, 2016 at 03:34:35PM -0400, Wayne Stambaugh wrote:
>> On 8/11/2016 11:28 AM, Chris Pavlina wrote:
>>> I stand by my recommendation to use a "Fixes: lp:n" on a line by
>>> itself. This is _established convention_ in git commit messages. A quick
>>> example from the Linux kernel tree has Reported-by, Requested-by, Cc,
>>> Signed-off-by all formatted in this way.
>>>
>>> Come on... it's established convention already, use it. We don't have to
>>> be different for the sake of it.
>>
>> It's an established convention for the linux kernel develpers not kicad
>> developers.
> 
> That's what I mean about being different for the sake of it. They
> already have a method, why create a new one because they're not us?
> Considering git was created specifically for linux kernel development
> I'd think that if anyone can establish convention, it's them.

They have their own hosting and bug tracking which is a luxury that we
don't have.  What makes sense for linux kernel development may or may
not make sense for us.  There are limitations to what we can do versus
what they can do.  I just want to do things because that's what all the
cool kids are doing.  If it makes sense, then we should adopt it.  If
not we should do what is appropriate for us.  In this case is seems to
make sense.

> 
>> I'm all for adding this information to the commit message.
>> I looked at Orson's web hook and this is all we need for it to link the
>> bug reports to the commit.  Let's go with "Fixes: lp:###" as a
>> separate line in the commit message and see how it goes.  If we have
>> issues, we can adjust accordingly.
>>
>>>
>>> lp: without "Fixes" may not be obvious at first glance to people
>>> unfamiliar with our conventions.
>>>
>>> On Thu, Aug 11, 2016 at 04:09:11PM +0200, Nick Østergaard wrote:
 Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
>
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
>> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
 The last time I looked, notifications of repo commits still were not
 implemented.  This is a show stopper for me.  I don't want to have to
 constantly grep the git commit log to see what changed.  If change
 notifications are working correctly, then I'm OK with moving forward
 on
 this if you can get the bug fix linking working.  We definitely should
 do some testing before we go live with this.
>>>
>>> I see there is an option to set notifications, in the same way as for
>>> the bazaar branches ("Edit your subscriptions" on the right side pane).
>>> I could not verify it, as likely I cannot receive notifications for the
>>> changes I introduce. Even if it does not work, I can implement it in my
>>> webhook.
>>
>> I spent some time yesterday creating my own git clone of kicad on LP and
>> I noticed that the subscriptions that I need appear to be available for
>> git repos so we shouldn't need any webhooks in for that unless they do
>> not work.
>
> If they do not work, let me know and I will fix it in the hook.
>
>>>
>>> The webhook has reached beta stage. I have created a dummy project for
>>> testing purposes, where you can see a bug report [1] and a commit [2]
>>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
 match.
>>> When it is detected, it automatically adds a message, changes the bug
>>> status and assignee. One thing that is not possible right now is
 linking
>>> with git branches, as apparently launchpad does not handle this at the
>>> moment (or I could not find the right format to specify a branch).
>>
>> Bug report linking is very important to me since I am responsible for
>> the stable branch.  If there is no support for this yet, I'm OK with
>> adding the bug report number to the first line of the commit message and
>> the URL somewhere in the commit message body.  If I give the OK to use
>> git, I will expect all developers that have commit privileges to the
>> product repo to follow this without exception.  The commit message for
>> bug report fixes must have this format:
>>
>> Description of bug report fix. (fixes lp:)
>>
>> * https://bugs.launchpad.net/kicad/+bug/
>>
>> If this is not acceptable, then the git transition will have to wait
>> until Canonical gets git bug report linking implemented or Orson beats
>> them to it.
>
> I spoke with a Launchpad developer and they have it already in their
> todo list. There is a plan to migrate Launchpad itself to git, so I
> believe they will do it well.
>
> From what I heard, currently it is possible to link git merge requests
> to bug reports, so it may temporarily solve the problem.
>
>>> All we need to do is to set a we

Re: [Kicad-developers] Git transition

[Chris Pavlina]

On Fri, Aug 12, 2016 at 03:34:35PM -0400, Wayne Stambaugh wrote:
> On 8/11/2016 11:28 AM, Chris Pavlina wrote:
> > I stand by my recommendation to use a "Fixes: lp:n" on a line by
> > itself. This is _established convention_ in git commit messages. A quick
> > example from the Linux kernel tree has Reported-by, Requested-by, Cc,
> > Signed-off-by all formatted in this way.
> > 
> > Come on... it's established convention already, use it. We don't have to
> > be different for the sake of it.
> 
> It's an established convention for the linux kernel develpers not kicad
> developers.

That's what I mean about being different for the sake of it. They
already have a method, why create a new one because they're not us?
Considering git was created specifically for linux kernel development
I'd think that if anyone can establish convention, it's them.

> I'm all for adding this information to the commit message.
> I looked at Orson's web hook and this is all we need for it to link the
> bug reports to the commit.  Let's go with "Fixes: lp:###" as a
> separate line in the commit message and see how it goes.  If we have
> issues, we can adjust accordingly.
> 
> > 
> > lp: without "Fixes" may not be obvious at first glance to people
> > unfamiliar with our conventions.
> > 
> > On Thu, Aug 11, 2016 at 04:09:11PM +0200, Nick Østergaard wrote:
> >> Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
> >>>
> >>> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
>  On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >> The last time I looked, notifications of repo commits still were not
> >> implemented.  This is a show stopper for me.  I don't want to have to
> >> constantly grep the git commit log to see what changed.  If change
> >> notifications are working correctly, then I'm OK with moving forward
> >> on
> >> this if you can get the bug fix linking working.  We definitely should
> >> do some testing before we go live with this.
> >
> > I see there is an option to set notifications, in the same way as for
> > the bazaar branches ("Edit your subscriptions" on the right side pane).
> > I could not verify it, as likely I cannot receive notifications for the
> > changes I introduce. Even if it does not work, I can implement it in my
> > webhook.
> 
>  I spent some time yesterday creating my own git clone of kicad on LP and
>  I noticed that the subscriptions that I need appear to be available for
>  git repos so we shouldn't need any webhooks in for that unless they do
>  not work.
> >>>
> >>> If they do not work, let me know and I will fix it in the hook.
> >>>
> >
> > The webhook has reached beta stage. I have created a dummy project for
> > testing purposes, where you can see a bug report [1] and a commit [2]
> > with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
> >> match.
> > When it is detected, it automatically adds a message, changes the bug
> > status and assignee. One thing that is not possible right now is
> >> linking
> > with git branches, as apparently launchpad does not handle this at the
> > moment (or I could not find the right format to specify a branch).
> 
>  Bug report linking is very important to me since I am responsible for
>  the stable branch.  If there is no support for this yet, I'm OK with
>  adding the bug report number to the first line of the commit message and
>  the URL somewhere in the commit message body.  If I give the OK to use
>  git, I will expect all developers that have commit privileges to the
>  product repo to follow this without exception.  The commit message for
>  bug report fixes must have this format:
> 
>  Description of bug report fix. (fixes lp:)
> 
>  * https://bugs.launchpad.net/kicad/+bug/
> 
>  If this is not acceptable, then the git transition will have to wait
>  until Canonical gets git bug report linking implemented or Orson beats
>  them to it.
> >>>
> >>> I spoke with a Launchpad developer and they have it already in their
> >>> todo list. There is a plan to migrate Launchpad itself to git, so I
> >>> believe they will do it well.
> >>>
> >>> From what I heard, currently it is possible to link git merge requests
> >>> to bug reports, so it may temporarily solve the problem.
> >>>
> > All we need to do is to set a webhook pointing to my script [3]. If it
> > is accepted, then I am going to create a separate lp account for the
> > automated changes.
> >
> > Currently the webhook works on my home server which has a high uptime,
> > but still it is not as reliable as dedicated servers. If there is
> > someone willing to host it on a better machine, I will be pleased to
> >> help.
> >
> > If you are curious about the source code, then I can put it in the
> >> KiCad
> > github 

Re: [Kicad-developers] Git transition

[Nick Østergaard]

What do you mean with git-SUM, is that the bzrlike revno or is that
the short git sha1?

I personally like the way we have it now with the build date, the
bzrlike revno serial and the git sha1.

Or are you suggesting to do like (2016-08-03 2383bcf-6299)-product
instead of (2016-08-03 BZR 6299, Git 2383bcf)-product?

2016-08-12 21:37 GMT+02:00 Wayne Stambaugh :
> I'm OK with git-SUM rather than the obnoxiously long git rev numbers.
> Anyone object to this?
>
> On 8/12/2016 1:25 AM, Simon Wells wrote:
>> In regards to this, Currently bzr revs are just the number and the git
>> revs are the bzr number and the git sum. Is it worthwhile (esspeically
>> in the title bar just changing this to git-BZRREV or just git-SUM
>> since git will be the primary vcs?
>>
>> On Fri, Aug 12, 2016 at 7:55 AM, Adam Wolf
>>  wrote:
>>> Sounds good!  I think that timeline is fine.
>>>
>>> Adam Wolf
>>>
>>>
>>> On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh  wrote:

 You have a couple of options.

 You could just clone directly from the source mirror on github for
 testing then update the url when we go live with git on launchpad.

 You could create your own clone of the github source mirror and add a
 remote link to your own personal git branch on launchpad and use that
 for testing.  This is what I have been using.  The set the url to push
 to your own git repo on launchpad run:

 git remote add launchpad
 git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev

 git push launchpad (OPTIONAL-REPO-NAME-ON-LP)

 You will now have your own kicad git repo on launchpad which you can
 clone for testing.

 On 8/11/2016 3:36 PM, Adam Wolf wrote:
> It should.  Can we somehow push a copy of what it is now so I have
> something to build against?
>


___
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] Git transition

[Wayne Stambaugh]

On 8/12/2016 5:36 AM, Maciej Sumiński wrote:
> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
> [snip]
>> I'll see if I can figure out how to do this and if it works we can use
>> it instead of adding the bug report url to the commit message.  I wonder
>> if we can link a commit to a bug report?  That could be an issue if we
>> cannot.  I don't want to have to always create a separate branch, push
>> it to my personal repo, and then merge it into the product branch for
>> simple bug fixes.
> 
> I already link commits to corresponding bug reports, see an example [1].
> 
> To make life even easier, I have just pushed an additional git config
> file (rev 7022). To enable it:
> 
>   git config --add include.path "$(pwd)/helpers/git/fixes_alias"
> 
> And afterwards:
> 
>   
>   git commit -a -m "Fixed a memleak"
>   git fixes 123456
>   git push
> 
> In the current form it is a mix of what Wayne and Chris have suggested,
> so in the end you will get:
> 
> orson@pcbe15262 ~/workspace/kicad % git log -n1
> commit 4ea4dcd67d89ce612aa1826dc845cc1137040fbf
> Author: Maciej Suminski 
> Date:   Fri Aug 12 11:34:06 2016 +0200
> 
> Fixed a memleak
> 
> Fixes: lp:123456
> * https://bugs.launchpad.net/kicad/+bug/123456
> 
> Regards,
> Orson
> 
> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1612107
> 

This appears to be just what we are looking for.  Thanks Orson!

Since I haven't heard anything from anyone besides Adam, I'm going to
assume everyone is OK with going live with the git transition on 8/21.
I will most likely make the bzr repo read only a few hours before I push
the git repo and make it the product branch so if you have commit access
please do not commit anything to the bzr repo on 8/21.  I will make an
announcement as soon as I have it up and running.  I think I hear the
"Hallelujah Chorus" in the background. ;)

___
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] Git transition

[Wayne Stambaugh]

I'm OK with git-SUM rather than the obnoxiously long git rev numbers.
Anyone object to this?

On 8/12/2016 1:25 AM, Simon Wells wrote:
> In regards to this, Currently bzr revs are just the number and the git
> revs are the bzr number and the git sum. Is it worthwhile (esspeically
> in the title bar just changing this to git-BZRREV or just git-SUM
> since git will be the primary vcs?
> 
> On Fri, Aug 12, 2016 at 7:55 AM, Adam Wolf
>  wrote:
>> Sounds good!  I think that timeline is fine.
>>
>> Adam Wolf
>>
>>
>> On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh  wrote:
>>>
>>> You have a couple of options.
>>>
>>> You could just clone directly from the source mirror on github for
>>> testing then update the url when we go live with git on launchpad.
>>>
>>> You could create your own clone of the github source mirror and add a
>>> remote link to your own personal git branch on launchpad and use that
>>> for testing.  This is what I have been using.  The set the url to push
>>> to your own git repo on launchpad run:
>>>
>>> git remote add launchpad
>>> git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev
>>>
>>> git push launchpad (OPTIONAL-REPO-NAME-ON-LP)
>>>
>>> You will now have your own kicad git repo on launchpad which you can
>>> clone for testing.
>>>
>>> On 8/11/2016 3:36 PM, Adam Wolf wrote:
 It should.  Can we somehow push a copy of what it is now so I have
 something to build against?

 On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh >>> > wrote:

 If we go live with git on 8/21, will that give you enough time to
 get
 things squared away on your end?

 On 8/11/2016 2:41 PM, Adam Wolf wrote:
 > The Git part will take maybe 1 week for OS X.  I am in favor of
 this
 > transition.
 >
 > Adam Wolf
 >
 >
 > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh" >>> 
 > >>
 wrote:
 >
 > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
 > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
 > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
 > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
 >  The last time I looked, notifications of repo commits
 still
 > were not
 >  implemented.  This is a show stopper for me.  I don't
 want to
 > have to
 >  constantly grep the git commit log to see what changed.
 If change
 >  notifications are working correctly, then I'm OK with
 moving
 > forward on
 >  this if you can get the bug fix linking working.  We
 definitely
 > should
 >  do some testing before we go live with this.
 > >>>
 > >>> I see there is an option to set notifications, in the same
 way
 > as for
 > >>> the bazaar branches ("Edit your subscriptions" on the
 right side
 > pane).
 > >>> I could not verify it, as likely I cannot receive
 notifications
 > for the
 > >>> changes I introduce. Even if it does not work, I can
 implement
 > it in my
 > >>> webhook.
 > >>
 > >> I spent some time yesterday creating my own git clone of
 kicad on
 > LP and
 > >> I noticed that the subscriptions that I need appear to be
 > available for
 > >> git repos so we shouldn't need any webhooks in for that
 unless
 > they do
 > >> not work.
 > >
 > > If they do not work, let me know and I will fix it in the
 hook.
 > >
 > >>>
 > >>> The webhook has reached beta stage. I have created a dummy
 > project for
 > >>> testing purposes, where you can see a bug report [1] and a
 > commit [2]
 > >>> with message that includes a "fix(es)?[
 ]+(lp:|#)?([0-9]+)"
 > regex match.
 > >>> When it is detected, it automatically adds a message,
 changes
 > the bug
 > >>> status and assignee. One thing that is not possible right
 now is
 > linking
 > >>> with git branches, as apparently launchpad does not handle
 this
 > at the
 > >>> moment (or I could not find the right format to specify a
 branch).
 > >>
 > >> Bug report linking is very important to me since I am
 responsible for
 > >> the stable branch.  If there is no support for this yet,
 I'm OK with
 > >> adding the bug report number to the first line of the
 commit
 > messa

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

On 8/11/2016 11:28 AM, Chris Pavlina wrote:
> I stand by my recommendation to use a "Fixes: lp:n" on a line by
> itself. This is _established convention_ in git commit messages. A quick
> example from the Linux kernel tree has Reported-by, Requested-by, Cc,
> Signed-off-by all formatted in this way.
> 
> Come on... it's established convention already, use it. We don't have to
> be different for the sake of it.

It's an established convention for the linux kernel develpers not kicad
developers.  I'm all for adding this information to the commit message.
I looked at Orson's web hook and this is all we need for it to link the
bug reports to the commit.  Let's go with "Fixes: lp:###" as a
separate line in the commit message and see how it goes.  If we have
issues, we can adjust accordingly.

> 
> lp: without "Fixes" may not be obvious at first glance to people
> unfamiliar with our conventions.
> 
> On Thu, Aug 11, 2016 at 04:09:11PM +0200, Nick Østergaard wrote:
>> Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
>>>
>>> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
 On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>> The last time I looked, notifications of repo commits still were not
>> implemented.  This is a show stopper for me.  I don't want to have to
>> constantly grep the git commit log to see what changed.  If change
>> notifications are working correctly, then I'm OK with moving forward
>> on
>> this if you can get the bug fix linking working.  We definitely should
>> do some testing before we go live with this.
>
> I see there is an option to set notifications, in the same way as for
> the bazaar branches ("Edit your subscriptions" on the right side pane).
> I could not verify it, as likely I cannot receive notifications for the
> changes I introduce. Even if it does not work, I can implement it in my
> webhook.

 I spent some time yesterday creating my own git clone of kicad on LP and
 I noticed that the subscriptions that I need appear to be available for
 git repos so we shouldn't need any webhooks in for that unless they do
 not work.
>>>
>>> If they do not work, let me know and I will fix it in the hook.
>>>
>
> The webhook has reached beta stage. I have created a dummy project for
> testing purposes, where you can see a bug report [1] and a commit [2]
> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
>> match.
> When it is detected, it automatically adds a message, changes the bug
> status and assignee. One thing that is not possible right now is
>> linking
> with git branches, as apparently launchpad does not handle this at the
> moment (or I could not find the right format to specify a branch).

 Bug report linking is very important to me since I am responsible for
 the stable branch.  If there is no support for this yet, I'm OK with
 adding the bug report number to the first line of the commit message and
 the URL somewhere in the commit message body.  If I give the OK to use
 git, I will expect all developers that have commit privileges to the
 product repo to follow this without exception.  The commit message for
 bug report fixes must have this format:

 Description of bug report fix. (fixes lp:)

 * https://bugs.launchpad.net/kicad/+bug/

 If this is not acceptable, then the git transition will have to wait
 until Canonical gets git bug report linking implemented or Orson beats
 them to it.
>>>
>>> I spoke with a Launchpad developer and they have it already in their
>>> todo list. There is a plan to migrate Launchpad itself to git, so I
>>> believe they will do it well.
>>>
>>> From what I heard, currently it is possible to link git merge requests
>>> to bug reports, so it may temporarily solve the problem.
>>>
> All we need to do is to set a webhook pointing to my script [3]. If it
> is accepted, then I am going to create a separate lp account for the
> automated changes.
>
> Currently the webhook works on my home server which has a high uptime,
> but still it is not as reliable as dedicated servers. If there is
> someone willing to host it on a better machine, I will be pleased to
>> help.
>
> If you are curious about the source code, then I can put it in the
>> KiCad
> github (once I get a repository there) or just post it somewhere.

 I can create a repo on github or you can create a repo on launchpad.
 Either way is fine by me.  If you want to use github, let me know what
 name you want for the repo and your github user name and I will set up
 the repo and give you admin rights.
>>>
>>> I have just pushed the code to Launchpad [1] and consider it ready to
>>> go. There is also a new account (KiCad Janitor) awaiting approval for
>>> kicad-developers membership, so a

Re: [Kicad-developers] Git transition

[Maciej Sumiński]

On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
[snip]
> I'll see if I can figure out how to do this and if it works we can use
> it instead of adding the bug report url to the commit message.  I wonder
> if we can link a commit to a bug report?  That could be an issue if we
> cannot.  I don't want to have to always create a separate branch, push
> it to my personal repo, and then merge it into the product branch for
> simple bug fixes.

I already link commits to corresponding bug reports, see an example [1].

To make life even easier, I have just pushed an additional git config
file (rev 7022). To enable it:

  git config --add include.path "$(pwd)/helpers/git/fixes_alias"

And afterwards:

  
  git commit -a -m "Fixed a memleak"
  git fixes 123456
  git push

In the current form it is a mix of what Wayne and Chris have suggested,
so in the end you will get:

orson@pcbe15262 ~/workspace/kicad % git log -n1
commit 4ea4dcd67d89ce612aa1826dc845cc1137040fbf
Author: Maciej Suminski 
Date:   Fri Aug 12 11:34:06 2016 +0200

Fixed a memleak

Fixes: lp:123456
* https://bugs.launchpad.net/kicad/+bug/123456

Regards,
Orson

1. https://bugs.launchpad.net/kicad-git-test/+bug/1612107



signature.asc
Description: OpenPGP digital signature
___
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] Git transition

[Simon Wells]

In regards to this, Currently bzr revs are just the number and the git
revs are the bzr number and the git sum. Is it worthwhile (esspeically
in the title bar just changing this to git-BZRREV or just git-SUM
since git will be the primary vcs?

On Fri, Aug 12, 2016 at 7:55 AM, Adam Wolf
 wrote:
> Sounds good!  I think that timeline is fine.
>
> Adam Wolf
>
>
> On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh  wrote:
>>
>> You have a couple of options.
>>
>> You could just clone directly from the source mirror on github for
>> testing then update the url when we go live with git on launchpad.
>>
>> You could create your own clone of the github source mirror and add a
>> remote link to your own personal git branch on launchpad and use that
>> for testing.  This is what I have been using.  The set the url to push
>> to your own git repo on launchpad run:
>>
>> git remote add launchpad
>> git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev
>>
>> git push launchpad (OPTIONAL-REPO-NAME-ON-LP)
>>
>> You will now have your own kicad git repo on launchpad which you can
>> clone for testing.
>>
>> On 8/11/2016 3:36 PM, Adam Wolf wrote:
>> > It should.  Can we somehow push a copy of what it is now so I have
>> > something to build against?
>> >
>> > On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh > > > wrote:
>> >
>> > If we go live with git on 8/21, will that give you enough time to
>> > get
>> > things squared away on your end?
>> >
>> > On 8/11/2016 2:41 PM, Adam Wolf wrote:
>> > > The Git part will take maybe 1 week for OS X.  I am in favor of
>> > this
>> > > transition.
>> > >
>> > > Adam Wolf
>> > >
>> > >
>> > > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh" > > 
>> > > >>
>> > wrote:
>> > >
>> > > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
>> > > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
>> > > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>> > > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>> > >  The last time I looked, notifications of repo commits
>> > still
>> > > were not
>> > >  implemented.  This is a show stopper for me.  I don't
>> > want to
>> > > have to
>> > >  constantly grep the git commit log to see what changed.
>> > If change
>> > >  notifications are working correctly, then I'm OK with
>> > moving
>> > > forward on
>> > >  this if you can get the bug fix linking working.  We
>> > definitely
>> > > should
>> > >  do some testing before we go live with this.
>> > > >>>
>> > > >>> I see there is an option to set notifications, in the same
>> > way
>> > > as for
>> > > >>> the bazaar branches ("Edit your subscriptions" on the
>> > right side
>> > > pane).
>> > > >>> I could not verify it, as likely I cannot receive
>> > notifications
>> > > for the
>> > > >>> changes I introduce. Even if it does not work, I can
>> > implement
>> > > it in my
>> > > >>> webhook.
>> > > >>
>> > > >> I spent some time yesterday creating my own git clone of
>> > kicad on
>> > > LP and
>> > > >> I noticed that the subscriptions that I need appear to be
>> > > available for
>> > > >> git repos so we shouldn't need any webhooks in for that
>> > unless
>> > > they do
>> > > >> not work.
>> > > >
>> > > > If they do not work, let me know and I will fix it in the
>> > hook.
>> > > >
>> > > >>>
>> > > >>> The webhook has reached beta stage. I have created a dummy
>> > > project for
>> > > >>> testing purposes, where you can see a bug report [1] and a
>> > > commit [2]
>> > > >>> with message that includes a "fix(es)?[
>> > ]+(lp:|#)?([0-9]+)"
>> > > regex match.
>> > > >>> When it is detected, it automatically adds a message,
>> > changes
>> > > the bug
>> > > >>> status and assignee. One thing that is not possible right
>> > now is
>> > > linking
>> > > >>> with git branches, as apparently launchpad does not handle
>> > this
>> > > at the
>> > > >>> moment (or I could not find the right format to specify a
>> > branch).
>> > > >>
>> > > >> Bug report linking is very important to me since I am
>> > responsible for
>> > > >> the stable branch.  If there is no support for this yet,
>> > I'm OK with
>> > > >> adding the bug report number to the first line of the
>> > commit
>> > > message and
>> > > >> the URL somewhere in the commit message body.  If I give
>> > the OK
>> > > to use
>> > > >> git, I will expect all developers that ha

Re: [Kicad-developers] Git transition

[Adam Wolf]

Sounds good!  I think that timeline is fine.

Adam Wolf

On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh  wrote:

> You have a couple of options.
>
> You could just clone directly from the source mirror on github for
> testing then update the url when we go live with git on launchpad.
>
> You could create your own clone of the github source mirror and add a
> remote link to your own personal git branch on launchpad and use that
> for testing.  This is what I have been using.  The set the url to push
> to your own git repo on launchpad run:
>
> git remote add launchpad
> git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev
>
> git push launchpad (OPTIONAL-REPO-NAME-ON-LP)
>
> You will now have your own kicad git repo on launchpad which you can
> clone for testing.
>
> On 8/11/2016 3:36 PM, Adam Wolf wrote:
> > It should.  Can we somehow push a copy of what it is now so I have
> > something to build against?
> >
> > On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh  > > wrote:
> >
> > If we go live with git on 8/21, will that give you enough time to get
> > things squared away on your end?
> >
> > On 8/11/2016 2:41 PM, Adam Wolf wrote:
> > > The Git part will take maybe 1 week for OS X.  I am in favor of
> this
> > > transition.
> > >
> > > Adam Wolf
> > >
> > >
> > > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  > 
> > > >>
> wrote:
> > >
> > > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> > >  The last time I looked, notifications of repo commits
> still
> > > were not
> > >  implemented.  This is a show stopper for me.  I don't
> want to
> > > have to
> > >  constantly grep the git commit log to see what changed.
> > If change
> > >  notifications are working correctly, then I'm OK with
> moving
> > > forward on
> > >  this if you can get the bug fix linking working.  We
> > definitely
> > > should
> > >  do some testing before we go live with this.
> > > >>>
> > > >>> I see there is an option to set notifications, in the same
> way
> > > as for
> > > >>> the bazaar branches ("Edit your subscriptions" on the
> > right side
> > > pane).
> > > >>> I could not verify it, as likely I cannot receive
> > notifications
> > > for the
> > > >>> changes I introduce. Even if it does not work, I can
> implement
> > > it in my
> > > >>> webhook.
> > > >>
> > > >> I spent some time yesterday creating my own git clone of
> > kicad on
> > > LP and
> > > >> I noticed that the subscriptions that I need appear to be
> > > available for
> > > >> git repos so we shouldn't need any webhooks in for that
> unless
> > > they do
> > > >> not work.
> > > >
> > > > If they do not work, let me know and I will fix it in the
> hook.
> > > >
> > > >>>
> > > >>> The webhook has reached beta stage. I have created a dummy
> > > project for
> > > >>> testing purposes, where you can see a bug report [1] and a
> > > commit [2]
> > > >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> > > regex match.
> > > >>> When it is detected, it automatically adds a message,
> changes
> > > the bug
> > > >>> status and assignee. One thing that is not possible right
> > now is
> > > linking
> > > >>> with git branches, as apparently launchpad does not handle
> > this
> > > at the
> > > >>> moment (or I could not find the right format to specify a
> > branch).
> > > >>
> > > >> Bug report linking is very important to me since I am
> > responsible for
> > > >> the stable branch.  If there is no support for this yet,
> > I'm OK with
> > > >> adding the bug report number to the first line of the commit
> > > message and
> > > >> the URL somewhere in the commit message body.  If I give
> the OK
> > > to use
> > > >> git, I will expect all developers that have commit
> > privileges to the
> > > >> product repo to follow this without exception.  The commit
> > > message for
> > > >> bug report fixes must have this format:
> > > >>
> > > >> Description of bug report fix. (fixes lp:)
> > > >>
> > > >> * https://bugs.launchpad.net/kicad/+bug/
> 
> > 

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

You have a couple of options.

You could just clone directly from the source mirror on github for
testing then update the url when we go live with git on launchpad.

You could create your own clone of the github source mirror and add a
remote link to your own personal git branch on launchpad and use that
for testing.  This is what I have been using.  The set the url to push
to your own git repo on launchpad run:

git remote add launchpad
git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev

git push launchpad (OPTIONAL-REPO-NAME-ON-LP)

You will now have your own kicad git repo on launchpad which you can
clone for testing.

On 8/11/2016 3:36 PM, Adam Wolf wrote:
> It should.  Can we somehow push a copy of what it is now so I have
> something to build against?
> 
> On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh  > wrote:
> 
> If we go live with git on 8/21, will that give you enough time to get
> things squared away on your end?
> 
> On 8/11/2016 2:41 PM, Adam Wolf wrote:
> > The Git part will take maybe 1 week for OS X.  I am in favor of this
> > transition.
> >
> > Adam Wolf
> >
> >
> > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  
> > >> wrote:
> >
> > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >  The last time I looked, notifications of repo commits still
> > were not
> >  implemented.  This is a show stopper for me.  I don't want to
> > have to
> >  constantly grep the git commit log to see what changed. 
> If change
> >  notifications are working correctly, then I'm OK with moving
> > forward on
> >  this if you can get the bug fix linking working.  We
> definitely
> > should
> >  do some testing before we go live with this.
> > >>>
> > >>> I see there is an option to set notifications, in the same way
> > as for
> > >>> the bazaar branches ("Edit your subscriptions" on the
> right side
> > pane).
> > >>> I could not verify it, as likely I cannot receive
> notifications
> > for the
> > >>> changes I introduce. Even if it does not work, I can implement
> > it in my
> > >>> webhook.
> > >>
> > >> I spent some time yesterday creating my own git clone of
> kicad on
> > LP and
> > >> I noticed that the subscriptions that I need appear to be
> > available for
> > >> git repos so we shouldn't need any webhooks in for that unless
> > they do
> > >> not work.
> > >
> > > If they do not work, let me know and I will fix it in the hook.
> > >
> > >>>
> > >>> The webhook has reached beta stage. I have created a dummy
> > project for
> > >>> testing purposes, where you can see a bug report [1] and a
> > commit [2]
> > >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> > regex match.
> > >>> When it is detected, it automatically adds a message, changes
> > the bug
> > >>> status and assignee. One thing that is not possible right
> now is
> > linking
> > >>> with git branches, as apparently launchpad does not handle
> this
> > at the
> > >>> moment (or I could not find the right format to specify a
> branch).
> > >>
> > >> Bug report linking is very important to me since I am
> responsible for
> > >> the stable branch.  If there is no support for this yet,
> I'm OK with
> > >> adding the bug report number to the first line of the commit
> > message and
> > >> the URL somewhere in the commit message body.  If I give the OK
> > to use
> > >> git, I will expect all developers that have commit
> privileges to the
> > >> product repo to follow this without exception.  The commit
> > message for
> > >> bug report fixes must have this format:
> > >>
> > >> Description of bug report fix. (fixes lp:)
> > >>
> > >> * https://bugs.launchpad.net/kicad/+bug/
> 
> >  >
> > >>
> > >> If this is not acceptable, then the git transition will
> have to wait
> > >> until Canonical gets git bug report linking implemented or
> Orson
> > beats
> > >> them to it.
> > >
>

Re: [Kicad-developers] Git transition

[Adam Wolf]

It should.  Can we somehow push a copy of what it is now so I have
something to build against?

On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh  wrote:

> If we go live with git on 8/21, will that give you enough time to get
> things squared away on your end?
>
> On 8/11/2016 2:41 PM, Adam Wolf wrote:
> > The Git part will take maybe 1 week for OS X.  I am in favor of this
> > transition.
> >
> > Adam Wolf
> >
> >
> > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  > > wrote:
> >
> > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >  The last time I looked, notifications of repo commits still
> > were not
> >  implemented.  This is a show stopper for me.  I don't want to
> > have to
> >  constantly grep the git commit log to see what changed.  If
> change
> >  notifications are working correctly, then I'm OK with moving
> > forward on
> >  this if you can get the bug fix linking working.  We definitely
> > should
> >  do some testing before we go live with this.
> > >>>
> > >>> I see there is an option to set notifications, in the same way
> > as for
> > >>> the bazaar branches ("Edit your subscriptions" on the right side
> > pane).
> > >>> I could not verify it, as likely I cannot receive notifications
> > for the
> > >>> changes I introduce. Even if it does not work, I can implement
> > it in my
> > >>> webhook.
> > >>
> > >> I spent some time yesterday creating my own git clone of kicad on
> > LP and
> > >> I noticed that the subscriptions that I need appear to be
> > available for
> > >> git repos so we shouldn't need any webhooks in for that unless
> > they do
> > >> not work.
> > >
> > > If they do not work, let me know and I will fix it in the hook.
> > >
> > >>>
> > >>> The webhook has reached beta stage. I have created a dummy
> > project for
> > >>> testing purposes, where you can see a bug report [1] and a
> > commit [2]
> > >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> > regex match.
> > >>> When it is detected, it automatically adds a message, changes
> > the bug
> > >>> status and assignee. One thing that is not possible right now is
> > linking
> > >>> with git branches, as apparently launchpad does not handle this
> > at the
> > >>> moment (or I could not find the right format to specify a
> branch).
> > >>
> > >> Bug report linking is very important to me since I am responsible
> for
> > >> the stable branch.  If there is no support for this yet, I'm OK
> with
> > >> adding the bug report number to the first line of the commit
> > message and
> > >> the URL somewhere in the commit message body.  If I give the OK
> > to use
> > >> git, I will expect all developers that have commit privileges to
> the
> > >> product repo to follow this without exception.  The commit
> > message for
> > >> bug report fixes must have this format:
> > >>
> > >> Description of bug report fix. (fixes lp:)
> > >>
> > >> * https://bugs.launchpad.net/kicad/+bug/
> 
> >  >
> > >>
> > >> If this is not acceptable, then the git transition will have to
> wait
> > >> until Canonical gets git bug report linking implemented or Orson
> > beats
> > >> them to it.
> > >
> > > I spoke with a Launchpad developer and they have it already in
> their
> > > todo list. There is a plan to migrate Launchpad itself to git, so I
> > > believe they will do it well.
> > >
> > > From what I heard, currently it is possible to link git merge
> requests
> > > to bug reports, so it may temporarily solve the problem.
> >
> > I'll see if I can figure out how to do this and if it works we can
> use
> > it instead of adding the bug report url to the commit message.  I
> wonder
> > if we can link a commit to a bug report?  That could be an issue if
> we
> > cannot.  I don't want to have to always create a separate branch,
> push
> > it to my personal repo, and then merge it into the product branch for
> > simple bug fixes.
> >
> > >
> > >>> All we need to do is to set a webhook pointing to my script [3].
> > If it
> > >>> is accepted, then I am going to create a separate lp account for
> the
> > >>> automated changes.
> > >>>
> > >>> Currently the webhook works on my home server which has a high
> > uptime,
> > >>> but still it is not as reliable as dedicated servers. If there is

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

If we go live with git on 8/21, will that give you enough time to get
things squared away on your end?

On 8/11/2016 2:41 PM, Adam Wolf wrote:
> The Git part will take maybe 1 week for OS X.  I am in favor of this
> transition.
> 
> Adam Wolf
> 
> 
> On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  > wrote:
> 
> On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>  The last time I looked, notifications of repo commits still
> were not
>  implemented.  This is a show stopper for me.  I don't want to
> have to
>  constantly grep the git commit log to see what changed.  If change
>  notifications are working correctly, then I'm OK with moving
> forward on
>  this if you can get the bug fix linking working.  We definitely
> should
>  do some testing before we go live with this.
> >>>
> >>> I see there is an option to set notifications, in the same way
> as for
> >>> the bazaar branches ("Edit your subscriptions" on the right side
> pane).
> >>> I could not verify it, as likely I cannot receive notifications
> for the
> >>> changes I introduce. Even if it does not work, I can implement
> it in my
> >>> webhook.
> >>
> >> I spent some time yesterday creating my own git clone of kicad on
> LP and
> >> I noticed that the subscriptions that I need appear to be
> available for
> >> git repos so we shouldn't need any webhooks in for that unless
> they do
> >> not work.
> >
> > If they do not work, let me know and I will fix it in the hook.
> >
> >>>
> >>> The webhook has reached beta stage. I have created a dummy
> project for
> >>> testing purposes, where you can see a bug report [1] and a
> commit [2]
> >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> regex match.
> >>> When it is detected, it automatically adds a message, changes
> the bug
> >>> status and assignee. One thing that is not possible right now is
> linking
> >>> with git branches, as apparently launchpad does not handle this
> at the
> >>> moment (or I could not find the right format to specify a branch).
> >>
> >> Bug report linking is very important to me since I am responsible for
> >> the stable branch.  If there is no support for this yet, I'm OK with
> >> adding the bug report number to the first line of the commit
> message and
> >> the URL somewhere in the commit message body.  If I give the OK
> to use
> >> git, I will expect all developers that have commit privileges to the
> >> product repo to follow this without exception.  The commit
> message for
> >> bug report fixes must have this format:
> >>
> >> Description of bug report fix. (fixes lp:)
> >>
> >> * https://bugs.launchpad.net/kicad/+bug/
> 
> >>
> >> If this is not acceptable, then the git transition will have to wait
> >> until Canonical gets git bug report linking implemented or Orson
> beats
> >> them to it.
> >
> > I spoke with a Launchpad developer and they have it already in their
> > todo list. There is a plan to migrate Launchpad itself to git, so I
> > believe they will do it well.
> >
> > From what I heard, currently it is possible to link git merge requests
> > to bug reports, so it may temporarily solve the problem.
> 
> I'll see if I can figure out how to do this and if it works we can use
> it instead of adding the bug report url to the commit message.  I wonder
> if we can link a commit to a bug report?  That could be an issue if we
> cannot.  I don't want to have to always create a separate branch, push
> it to my personal repo, and then merge it into the product branch for
> simple bug fixes.
> 
> >
> >>> All we need to do is to set a webhook pointing to my script [3].
> If it
> >>> is accepted, then I am going to create a separate lp account for the
> >>> automated changes.
> >>>
> >>> Currently the webhook works on my home server which has a high
> uptime,
> >>> but still it is not as reliable as dedicated servers. If there is
> >>> someone willing to host it on a better machine, I will be
> pleased to help.
> >>>
> >>> If you are curious about the source code, then I can put it in
> the KiCad
> >>> github (once I get a repository there) or just post it somewhere.
> >>
> >> I can create a repo on github or you can create a repo on launchpad.
> >> Either way is fine by me.  If you want to use github, let me know
> what
> >> name you want for the repo and your github user name and I will
> 

Re: [Kicad-developers] Git transition

[Adam Wolf]

The Git part will take maybe 1 week for OS X.  I am in favor of this
transition.

Adam Wolf

On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  wrote:

> On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>  The last time I looked, notifications of repo commits still were not
>  implemented.  This is a show stopper for me.  I don't want to have to
>  constantly grep the git commit log to see what changed.  If change
>  notifications are working correctly, then I'm OK with moving forward
> on
>  this if you can get the bug fix linking working.  We definitely should
>  do some testing before we go live with this.
> >>>
> >>> I see there is an option to set notifications, in the same way as for
> >>> the bazaar branches ("Edit your subscriptions" on the right side pane).
> >>> I could not verify it, as likely I cannot receive notifications for the
> >>> changes I introduce. Even if it does not work, I can implement it in my
> >>> webhook.
> >>
> >> I spent some time yesterday creating my own git clone of kicad on LP and
> >> I noticed that the subscriptions that I need appear to be available for
> >> git repos so we shouldn't need any webhooks in for that unless they do
> >> not work.
> >
> > If they do not work, let me know and I will fix it in the hook.
> >
> >>>
> >>> The webhook has reached beta stage. I have created a dummy project for
> >>> testing purposes, where you can see a bug report [1] and a commit [2]
> >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
> match.
> >>> When it is detected, it automatically adds a message, changes the bug
> >>> status and assignee. One thing that is not possible right now is
> linking
> >>> with git branches, as apparently launchpad does not handle this at the
> >>> moment (or I could not find the right format to specify a branch).
> >>
> >> Bug report linking is very important to me since I am responsible for
> >> the stable branch.  If there is no support for this yet, I'm OK with
> >> adding the bug report number to the first line of the commit message and
> >> the URL somewhere in the commit message body.  If I give the OK to use
> >> git, I will expect all developers that have commit privileges to the
> >> product repo to follow this without exception.  The commit message for
> >> bug report fixes must have this format:
> >>
> >> Description of bug report fix. (fixes lp:)
> >>
> >> * https://bugs.launchpad.net/kicad/+bug/
> >>
> >> If this is not acceptable, then the git transition will have to wait
> >> until Canonical gets git bug report linking implemented or Orson beats
> >> them to it.
> >
> > I spoke with a Launchpad developer and they have it already in their
> > todo list. There is a plan to migrate Launchpad itself to git, so I
> > believe they will do it well.
> >
> > From what I heard, currently it is possible to link git merge requests
> > to bug reports, so it may temporarily solve the problem.
>
> I'll see if I can figure out how to do this and if it works we can use
> it instead of adding the bug report url to the commit message.  I wonder
> if we can link a commit to a bug report?  That could be an issue if we
> cannot.  I don't want to have to always create a separate branch, push
> it to my personal repo, and then merge it into the product branch for
> simple bug fixes.
>
> >
> >>> All we need to do is to set a webhook pointing to my script [3]. If it
> >>> is accepted, then I am going to create a separate lp account for the
> >>> automated changes.
> >>>
> >>> Currently the webhook works on my home server which has a high uptime,
> >>> but still it is not as reliable as dedicated servers. If there is
> >>> someone willing to host it on a better machine, I will be pleased to
> help.
> >>>
> >>> If you are curious about the source code, then I can put it in the
> KiCad
> >>> github (once I get a repository there) or just post it somewhere.
> >>
> >> I can create a repo on github or you can create a repo on launchpad.
> >> Either way is fine by me.  If you want to use github, let me know what
> >> name you want for the repo and your github user name and I will set up
> >> the repo and give you admin rights.
> >
> > I have just pushed the code to Launchpad [1] and consider it ready to
> > go. There is also a new account (KiCad Janitor) awaiting approval for
> > kicad-developers membership, so all the changes will be done using this
> > dedicated account.
> >
> > The webhook has been modified to accept a wider set of phrases
> > indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
> >
> > Let me know when the git repository is set up, so I can install the
> webhook.
>
> This will require some coordination with our package devs.  Package
> devs, when can we be ready to provide nightly builds from the git repo?
> Does anyone else h

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
>> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
 The last time I looked, notifications of repo commits still were not
 implemented.  This is a show stopper for me.  I don't want to have to
 constantly grep the git commit log to see what changed.  If change
 notifications are working correctly, then I'm OK with moving forward on
 this if you can get the bug fix linking working.  We definitely should
 do some testing before we go live with this.
>>>
>>> I see there is an option to set notifications, in the same way as for
>>> the bazaar branches ("Edit your subscriptions" on the right side pane).
>>> I could not verify it, as likely I cannot receive notifications for the
>>> changes I introduce. Even if it does not work, I can implement it in my
>>> webhook.
>>
>> I spent some time yesterday creating my own git clone of kicad on LP and
>> I noticed that the subscriptions that I need appear to be available for
>> git repos so we shouldn't need any webhooks in for that unless they do
>> not work.
> 
> If they do not work, let me know and I will fix it in the hook.
> 
>>>
>>> The webhook has reached beta stage. I have created a dummy project for
>>> testing purposes, where you can see a bug report [1] and a commit [2]
>>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex match.
>>> When it is detected, it automatically adds a message, changes the bug
>>> status and assignee. One thing that is not possible right now is linking
>>> with git branches, as apparently launchpad does not handle this at the
>>> moment (or I could not find the right format to specify a branch).
>>
>> Bug report linking is very important to me since I am responsible for
>> the stable branch.  If there is no support for this yet, I'm OK with
>> adding the bug report number to the first line of the commit message and
>> the URL somewhere in the commit message body.  If I give the OK to use
>> git, I will expect all developers that have commit privileges to the
>> product repo to follow this without exception.  The commit message for
>> bug report fixes must have this format:
>>
>> Description of bug report fix. (fixes lp:)
>>
>> * https://bugs.launchpad.net/kicad/+bug/
>>
>> If this is not acceptable, then the git transition will have to wait
>> until Canonical gets git bug report linking implemented or Orson beats
>> them to it.
> 
> I spoke with a Launchpad developer and they have it already in their
> todo list. There is a plan to migrate Launchpad itself to git, so I
> believe they will do it well.
> 
> From what I heard, currently it is possible to link git merge requests
> to bug reports, so it may temporarily solve the problem.

I'll see if I can figure out how to do this and if it works we can use
it instead of adding the bug report url to the commit message.  I wonder
if we can link a commit to a bug report?  That could be an issue if we
cannot.  I don't want to have to always create a separate branch, push
it to my personal repo, and then merge it into the product branch for
simple bug fixes.

> 
>>> All we need to do is to set a webhook pointing to my script [3]. If it
>>> is accepted, then I am going to create a separate lp account for the
>>> automated changes.
>>>
>>> Currently the webhook works on my home server which has a high uptime,
>>> but still it is not as reliable as dedicated servers. If there is
>>> someone willing to host it on a better machine, I will be pleased to help.
>>>
>>> If you are curious about the source code, then I can put it in the KiCad
>>> github (once I get a repository there) or just post it somewhere.
>>
>> I can create a repo on github or you can create a repo on launchpad.
>> Either way is fine by me.  If you want to use github, let me know what
>> name you want for the repo and your github user name and I will set up
>> the repo and give you admin rights.
> 
> I have just pushed the code to Launchpad [1] and consider it ready to
> go. There is also a new account (KiCad Janitor) awaiting approval for
> kicad-developers membership, so all the changes will be done using this
> dedicated account.
> 
> The webhook has been modified to accept a wider set of phrases
> indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
> 
> Let me know when the git repository is set up, so I can install the webhook.

This will require some coordination with our package devs.  Package
devs, when can we be ready to provide nightly builds from the git repo?
Does anyone else have any issues with converting over to git?  Speak now
or forever hold your peace.

> 
> Regards,
> Orson
> 
> 1. https://launchpad.net/kicad-git-hook
> 
>> Thanks for working on this.
>>
>> Cheers,
>>
>> Wayne
>>
>>>
>>> Regards,
>>> Orson
>>>
>>> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
>>> 2.
>>> https://git.la

Re: [Kicad-developers] Git transition

[Chris Pavlina]

I stand by my recommendation to use a "Fixes: lp:n" on a line by
itself. This is _established convention_ in git commit messages. A quick
example from the Linux kernel tree has Reported-by, Requested-by, Cc,
Signed-off-by all formatted in this way.

Come on... it's established convention already, use it. We don't have to
be different for the sake of it.

lp: without "Fixes" may not be obvious at first glance to people
unfamiliar with our conventions.

On Thu, Aug 11, 2016 at 04:09:11PM +0200, Nick Østergaard wrote:
> Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
> >
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > > On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > >> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> > >>> The last time I looked, notifications of repo commits still were not
> > >>> implemented.  This is a show stopper for me.  I don't want to have to
> > >>> constantly grep the git commit log to see what changed.  If change
> > >>> notifications are working correctly, then I'm OK with moving forward
> on
> > >>> this if you can get the bug fix linking working.  We definitely should
> > >>> do some testing before we go live with this.
> > >>
> > >> I see there is an option to set notifications, in the same way as for
> > >> the bazaar branches ("Edit your subscriptions" on the right side pane).
> > >> I could not verify it, as likely I cannot receive notifications for the
> > >> changes I introduce. Even if it does not work, I can implement it in my
> > >> webhook.
> > >
> > > I spent some time yesterday creating my own git clone of kicad on LP and
> > > I noticed that the subscriptions that I need appear to be available for
> > > git repos so we shouldn't need any webhooks in for that unless they do
> > > not work.
> >
> > If they do not work, let me know and I will fix it in the hook.
> >
> > >>
> > >> The webhook has reached beta stage. I have created a dummy project for
> > >> testing purposes, where you can see a bug report [1] and a commit [2]
> > >> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
> match.
> > >> When it is detected, it automatically adds a message, changes the bug
> > >> status and assignee. One thing that is not possible right now is
> linking
> > >> with git branches, as apparently launchpad does not handle this at the
> > >> moment (or I could not find the right format to specify a branch).
> > >
> > > Bug report linking is very important to me since I am responsible for
> > > the stable branch.  If there is no support for this yet, I'm OK with
> > > adding the bug report number to the first line of the commit message and
> > > the URL somewhere in the commit message body.  If I give the OK to use
> > > git, I will expect all developers that have commit privileges to the
> > > product repo to follow this without exception.  The commit message for
> > > bug report fixes must have this format:
> > >
> > > Description of bug report fix. (fixes lp:)
> > >
> > > * https://bugs.launchpad.net/kicad/+bug/
> > >
> > > If this is not acceptable, then the git transition will have to wait
> > > until Canonical gets git bug report linking implemented or Orson beats
> > > them to it.
> >
> > I spoke with a Launchpad developer and they have it already in their
> > todo list. There is a plan to migrate Launchpad itself to git, so I
> > believe they will do it well.
> >
> > From what I heard, currently it is possible to link git merge requests
> > to bug reports, so it may temporarily solve the problem.
> >
> > >> All we need to do is to set a webhook pointing to my script [3]. If it
> > >> is accepted, then I am going to create a separate lp account for the
> > >> automated changes.
> > >>
> > >> Currently the webhook works on my home server which has a high uptime,
> > >> but still it is not as reliable as dedicated servers. If there is
> > >> someone willing to host it on a better machine, I will be pleased to
> help.
> > >>
> > >> If you are curious about the source code, then I can put it in the
> KiCad
> > >> github (once I get a repository there) or just post it somewhere.
> > >
> > > I can create a repo on github or you can create a repo on launchpad.
> > > Either way is fine by me.  If you want to use github, let me know what
> > > name you want for the repo and your github user name and I will set up
> > > the repo and give you admin rights.
> >
> > I have just pushed the code to Launchpad [1] and consider it ready to
> > go. There is also a new account (KiCad Janitor) awaiting approval for
> > kicad-developers membership, so all the changes will be done using this
> > dedicated account.
> >
> > The webhook has been modified to accept a wider set of phrases
> > indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
> >
> 
> I would like to suggest that we don't write "fixes:" as a prefix, I don't
> see it adds any added information. Simply write:
> lp:4232442
> 
> And in the rare event it is for multipl

Re: [Kicad-developers] Git transition

[Nick Østergaard]

Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
>
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >>> The last time I looked, notifications of repo commits still were not
> >>> implemented.  This is a show stopper for me.  I don't want to have to
> >>> constantly grep the git commit log to see what changed.  If change
> >>> notifications are working correctly, then I'm OK with moving forward
on
> >>> this if you can get the bug fix linking working.  We definitely should
> >>> do some testing before we go live with this.
> >>
> >> I see there is an option to set notifications, in the same way as for
> >> the bazaar branches ("Edit your subscriptions" on the right side pane).
> >> I could not verify it, as likely I cannot receive notifications for the
> >> changes I introduce. Even if it does not work, I can implement it in my
> >> webhook.
> >
> > I spent some time yesterday creating my own git clone of kicad on LP and
> > I noticed that the subscriptions that I need appear to be available for
> > git repos so we shouldn't need any webhooks in for that unless they do
> > not work.
>
> If they do not work, let me know and I will fix it in the hook.
>
> >>
> >> The webhook has reached beta stage. I have created a dummy project for
> >> testing purposes, where you can see a bug report [1] and a commit [2]
> >> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
match.
> >> When it is detected, it automatically adds a message, changes the bug
> >> status and assignee. One thing that is not possible right now is
linking
> >> with git branches, as apparently launchpad does not handle this at the
> >> moment (or I could not find the right format to specify a branch).
> >
> > Bug report linking is very important to me since I am responsible for
> > the stable branch.  If there is no support for this yet, I'm OK with
> > adding the bug report number to the first line of the commit message and
> > the URL somewhere in the commit message body.  If I give the OK to use
> > git, I will expect all developers that have commit privileges to the
> > product repo to follow this without exception.  The commit message for
> > bug report fixes must have this format:
> >
> > Description of bug report fix. (fixes lp:)
> >
> > * https://bugs.launchpad.net/kicad/+bug/
> >
> > If this is not acceptable, then the git transition will have to wait
> > until Canonical gets git bug report linking implemented or Orson beats
> > them to it.
>
> I spoke with a Launchpad developer and they have it already in their
> todo list. There is a plan to migrate Launchpad itself to git, so I
> believe they will do it well.
>
> From what I heard, currently it is possible to link git merge requests
> to bug reports, so it may temporarily solve the problem.
>
> >> All we need to do is to set a webhook pointing to my script [3]. If it
> >> is accepted, then I am going to create a separate lp account for the
> >> automated changes.
> >>
> >> Currently the webhook works on my home server which has a high uptime,
> >> but still it is not as reliable as dedicated servers. If there is
> >> someone willing to host it on a better machine, I will be pleased to
help.
> >>
> >> If you are curious about the source code, then I can put it in the
KiCad
> >> github (once I get a repository there) or just post it somewhere.
> >
> > I can create a repo on github or you can create a repo on launchpad.
> > Either way is fine by me.  If you want to use github, let me know what
> > name you want for the repo and your github user name and I will set up
> > the repo and give you admin rights.
>
> I have just pushed the code to Launchpad [1] and consider it ready to
> go. There is also a new account (KiCad Janitor) awaiting approval for
> kicad-developers membership, so all the changes will be done using this
> dedicated account.
>
> The webhook has been modified to accept a wider set of phrases
> indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
>

I would like to suggest that we don't write "fixes:" as a prefix, I don't
see it adds any added information. Simply write:
lp:4232442

And in the rare event it is for multiple bugs just append more lines of it.

> Let me know when the git repository is set up, so I can install the
webhook.
>
> Regards,
> Orson
>
> 1. https://launchpad.net/kicad-git-hook
>
> > Thanks for working on this.
> >
> > Cheers,
> >
> > Wayne
> >
> >>
> >> Regards,
> >> Orson
> >>
> >> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
> >> 2.
> >>
https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
> >> 3. https://orson.net.pl/kicad_git_hook
> >>
> >>> Before every starts beating the GitHub drum, I have one major issue
with
> >>> GitHub and that is control.  There is no way that I know of to
moderate
> >>> a project on github.  Anyone with a github acco

Re: [Kicad-developers] Git transition

[Maciej Sumiński]

On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>>> The last time I looked, notifications of repo commits still were not
>>> implemented.  This is a show stopper for me.  I don't want to have to
>>> constantly grep the git commit log to see what changed.  If change
>>> notifications are working correctly, then I'm OK with moving forward on
>>> this if you can get the bug fix linking working.  We definitely should
>>> do some testing before we go live with this.
>>
>> I see there is an option to set notifications, in the same way as for
>> the bazaar branches ("Edit your subscriptions" on the right side pane).
>> I could not verify it, as likely I cannot receive notifications for the
>> changes I introduce. Even if it does not work, I can implement it in my
>> webhook.
> 
> I spent some time yesterday creating my own git clone of kicad on LP and
> I noticed that the subscriptions that I need appear to be available for
> git repos so we shouldn't need any webhooks in for that unless they do
> not work.

If they do not work, let me know and I will fix it in the hook.

>>
>> The webhook has reached beta stage. I have created a dummy project for
>> testing purposes, where you can see a bug report [1] and a commit [2]
>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex match.
>> When it is detected, it automatically adds a message, changes the bug
>> status and assignee. One thing that is not possible right now is linking
>> with git branches, as apparently launchpad does not handle this at the
>> moment (or I could not find the right format to specify a branch).
> 
> Bug report linking is very important to me since I am responsible for
> the stable branch.  If there is no support for this yet, I'm OK with
> adding the bug report number to the first line of the commit message and
> the URL somewhere in the commit message body.  If I give the OK to use
> git, I will expect all developers that have commit privileges to the
> product repo to follow this without exception.  The commit message for
> bug report fixes must have this format:
> 
> Description of bug report fix. (fixes lp:)
> 
> * https://bugs.launchpad.net/kicad/+bug/
> 
> If this is not acceptable, then the git transition will have to wait
> until Canonical gets git bug report linking implemented or Orson beats
> them to it.

I spoke with a Launchpad developer and they have it already in their
todo list. There is a plan to migrate Launchpad itself to git, so I
believe they will do it well.

From what I heard, currently it is possible to link git merge requests
to bug reports, so it may temporarily solve the problem.

>> All we need to do is to set a webhook pointing to my script [3]. If it
>> is accepted, then I am going to create a separate lp account for the
>> automated changes.
>>
>> Currently the webhook works on my home server which has a high uptime,
>> but still it is not as reliable as dedicated servers. If there is
>> someone willing to host it on a better machine, I will be pleased to help.
>>
>> If you are curious about the source code, then I can put it in the KiCad
>> github (once I get a repository there) or just post it somewhere.
> 
> I can create a repo on github or you can create a repo on launchpad.
> Either way is fine by me.  If you want to use github, let me know what
> name you want for the repo and your github user name and I will set up
> the repo and give you admin rights.

I have just pushed the code to Launchpad [1] and consider it ready to
go. There is also a new account (KiCad Janitor) awaiting approval for
kicad-developers membership, so all the changes will be done using this
dedicated account.

The webhook has been modified to accept a wider set of phrases
indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).

Let me know when the git repository is set up, so I can install the webhook.

Regards,
Orson

1. https://launchpad.net/kicad-git-hook

> Thanks for working on this.
> 
> Cheers,
> 
> Wayne
> 
>>
>> Regards,
>> Orson
>>
>> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
>> 2.
>> https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
>> 3. https://orson.net.pl/kicad_git_hook
>>
>>> Before every starts beating the GitHub drum, I have one major issue with
>>> GitHub and that is control.  There is no way that I know of to moderate
>>> a project on github.  Anyone with a github account can submit a pull
>>> requests at anytime even if they are not part of the dev team.  As
>>> project leader, this is an issue.  I'm already a my limit with the
>>> development team we have in place and I really don't want to deal with a
>>> wide open code hosting.  I also have no way of removing someone from the
>>> list should I need to.  I know it hasn't happened yet but I am not naive
>>> enough to think that it wont happen.  At this time, I a

Re: [Kicad-developers] Git transition

[Maciej Sumiński]

On 08/10/2016 04:49 PM, Chris Pavlina wrote:
[snip]
> Any particular reason for having (fixes lp:) in the first
> line? Typically the first line of the commit message is kept very
> short and limited to things one might need when quickly browsing a
> log. The usual convention in git is to write something like this at
> the bottom of the message:
> 
> Fixes: lp:
> 
> It's very easy to search for those if you want, using git log --grep:
> 
> git log --grep="^Fixes: lp:12345678"

Currently the webhook accepts a few formats: "fix(es)?[
]+(lp:|#)?([0-9]+)", but it can be easily changed. I would not mind
extending it to catch the mentioned phrase. It also accepts the formula
anywhere in the commit message, not only the first line, so it is up to
Wayne to set the rules.

Regards,
Orson



signature.asc
Description: OpenPGP digital signature
___
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] Git transition

[Chris Pavlina]

On Wed, Aug 10, 2016 at 9:34 AM, Wayne Stambaugh  wrote:
>
> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >> The last time I looked, notifications of repo commits still were not
> >> implemented.  This is a show stopper for me.  I don't want to have to
> >> constantly grep the git commit log to see what changed.  If change
> >> notifications are working correctly, then I'm OK with moving forward on
> >> this if you can get the bug fix linking working.  We definitely should
> >> do some testing before we go live with this.
> >
> > I see there is an option to set notifications, in the same way as for
> > the bazaar branches ("Edit your subscriptions" on the right side pane).
> > I could not verify it, as likely I cannot receive notifications for the
> > changes I introduce. Even if it does not work, I can implement it in my
> > webhook.
>
> I spent some time yesterday creating my own git clone of kicad on LP and
> I noticed that the subscriptions that I need appear to be available for
> git repos so we shouldn't need any webhooks in for that unless they do
> not work.
>
> >
> > The webhook has reached beta stage. I have created a dummy project for
> > testing purposes, where you can see a bug report [1] and a commit [2]
> > with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex match.
> > When it is detected, it automatically adds a message, changes the bug
> > status and assignee. One thing that is not possible right now is linking
> > with git branches, as apparently launchpad does not handle this at the
> > moment (or I could not find the right format to specify a branch).
>
> Bug report linking is very important to me since I am responsible for
> the stable branch.  If there is no support for this yet, I'm OK with
> adding the bug report number to the first line of the commit message and
> the URL somewhere in the commit message body.  If I give the OK to use
> git, I will expect all developers that have commit privileges to the
> product repo to follow this without exception.  The commit message for
> bug report fixes must have this format:
>
> Description of bug report fix. (fixes lp:)
>
> * https://bugs.launchpad.net/kicad/+bug/
>
> If this is not acceptable, then the git transition will have to wait
> until Canonical gets git bug report linking implemented or Orson beats
> them to it.


Any particular reason for having (fixes lp:) in the first
line? Typically the first line of the commit message is kept very
short and limited to things one might need when quickly browsing a
log. The usual convention in git is to write something like this at
the bottom of the message:

Fixes: lp:

It's very easy to search for those if you want, using git log --grep:

git log --grep="^Fixes: lp:12345678"


>
>
>
>
> >
> > All we need to do is to set a webhook pointing to my script [3]. If it
> > is accepted, then I am going to create a separate lp account for the
> > automated changes.
> >
> > Currently the webhook works on my home server which has a high uptime,
> > but still it is not as reliable as dedicated servers. If there is
> > someone willing to host it on a better machine, I will be pleased to help.
> >
> > If you are curious about the source code, then I can put it in the KiCad
> > github (once I get a repository there) or just post it somewhere.
>
> I can create a repo on github or you can create a repo on launchpad.
> Either way is fine by me.  If you want to use github, let me know what
> name you want for the repo and your github user name and I will set up
> the repo and give you admin rights.
>
> Thanks for working on this.
>
> Cheers,
>
> Wayne
>
> >
> > Regards,
> > Orson
> >
> > 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
> > 2.
> > https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
> > 3. https://orson.net.pl/kicad_git_hook
> >
> >> Before every starts beating the GitHub drum, I have one major issue with
> >> GitHub and that is control.  There is no way that I know of to moderate
> >> a project on github.  Anyone with a github account can submit a pull
> >> requests at anytime even if they are not part of the dev team.  As
> >> project leader, this is an issue.  I'm already a my limit with the
> >> development team we have in place and I really don't want to deal with a
> >> wide open code hosting.  I also have no way of removing someone from the
> >> list should I need to.  I know it hasn't happened yet but I am not naive
> >> enough to think that it wont happen.  At this time, I am more
> >> comfortable with LP until something better comes along or we take full
> >> control a provide our own hosting.
> >>
> >> On 8/8/2016 3:58 AM, Maciej Sumiński wrote:
> >>> Apparently we have not discussed git transition for a long time now, so
> >>> I felt it is the right time to raise the subject again to keep our 
> >>> routine.
> >>>
> >>> Launchpad now supp

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>> The last time I looked, notifications of repo commits still were not
>> implemented.  This is a show stopper for me.  I don't want to have to
>> constantly grep the git commit log to see what changed.  If change
>> notifications are working correctly, then I'm OK with moving forward on
>> this if you can get the bug fix linking working.  We definitely should
>> do some testing before we go live with this.
> 
> I see there is an option to set notifications, in the same way as for
> the bazaar branches ("Edit your subscriptions" on the right side pane).
> I could not verify it, as likely I cannot receive notifications for the
> changes I introduce. Even if it does not work, I can implement it in my
> webhook.

I spent some time yesterday creating my own git clone of kicad on LP and
I noticed that the subscriptions that I need appear to be available for
git repos so we shouldn't need any webhooks in for that unless they do
not work.

> 
> The webhook has reached beta stage. I have created a dummy project for
> testing purposes, where you can see a bug report [1] and a commit [2]
> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex match.
> When it is detected, it automatically adds a message, changes the bug
> status and assignee. One thing that is not possible right now is linking
> with git branches, as apparently launchpad does not handle this at the
> moment (or I could not find the right format to specify a branch).

Bug report linking is very important to me since I am responsible for
the stable branch.  If there is no support for this yet, I'm OK with
adding the bug report number to the first line of the commit message and
the URL somewhere in the commit message body.  If I give the OK to use
git, I will expect all developers that have commit privileges to the
product repo to follow this without exception.  The commit message for
bug report fixes must have this format:

Description of bug report fix. (fixes lp:)

* https://bugs.launchpad.net/kicad/+bug/

If this is not acceptable, then the git transition will have to wait
until Canonical gets git bug report linking implemented or Orson beats
them to it.

> 
> All we need to do is to set a webhook pointing to my script [3]. If it
> is accepted, then I am going to create a separate lp account for the
> automated changes.
> 
> Currently the webhook works on my home server which has a high uptime,
> but still it is not as reliable as dedicated servers. If there is
> someone willing to host it on a better machine, I will be pleased to help.
> 
> If you are curious about the source code, then I can put it in the KiCad
> github (once I get a repository there) or just post it somewhere.

I can create a repo on github or you can create a repo on launchpad.
Either way is fine by me.  If you want to use github, let me know what
name you want for the repo and your github user name and I will set up
the repo and give you admin rights.

Thanks for working on this.

Cheers,

Wayne

> 
> Regards,
> Orson
> 
> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
> 2.
> https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
> 3. https://orson.net.pl/kicad_git_hook
> 
>> Before every starts beating the GitHub drum, I have one major issue with
>> GitHub and that is control.  There is no way that I know of to moderate
>> a project on github.  Anyone with a github account can submit a pull
>> requests at anytime even if they are not part of the dev team.  As
>> project leader, this is an issue.  I'm already a my limit with the
>> development team we have in place and I really don't want to deal with a
>> wide open code hosting.  I also have no way of removing someone from the
>> list should I need to.  I know it hasn't happened yet but I am not naive
>> enough to think that it wont happen.  At this time, I am more
>> comfortable with LP until something better comes along or we take full
>> control a provide our own hosting.
>>
>> On 8/8/2016 3:58 AM, Maciej Sumiński wrote:
>>> Apparently we have not discussed git transition for a long time now, so
>>> I felt it is the right time to raise the subject again to keep our routine.
>>>
>>> Launchpad now supports merge proposals [1] and it looks like they are
>>> still improving git integration. The only missing feature are links
>>> between bug fixing commits and respective bug reports (bzr commit ...
>>> --fixes=lp:123456). It is not supported by git itself, but might be
>>> resolved using webhooks [2] and appropriate keywords in commit messages
>>> (e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
>>> obstacle, then I volunteer to provide code for the hook.
>>>
>>> What do you think? Is there anything else that prevents transition?
>>>
>>> Regards,
>>> Orson
>>>
>>> 1. https://help.launchpad.net/Code/Git
>>> 2. https://help.launchpad.net/API/We

Re: [Kicad-developers] Git transition

[Maciej Sumiński]

On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> The last time I looked, notifications of repo commits still were not
> implemented.  This is a show stopper for me.  I don't want to have to
> constantly grep the git commit log to see what changed.  If change
> notifications are working correctly, then I'm OK with moving forward on
> this if you can get the bug fix linking working.  We definitely should
> do some testing before we go live with this.

I see there is an option to set notifications, in the same way as for
the bazaar branches ("Edit your subscriptions" on the right side pane).
I could not verify it, as likely I cannot receive notifications for the
changes I introduce. Even if it does not work, I can implement it in my
webhook.

The webhook has reached beta stage. I have created a dummy project for
testing purposes, where you can see a bug report [1] and a commit [2]
with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex match.
When it is detected, it automatically adds a message, changes the bug
status and assignee. One thing that is not possible right now is linking
with git branches, as apparently launchpad does not handle this at the
moment (or I could not find the right format to specify a branch).

All we need to do is to set a webhook pointing to my script [3]. If it
is accepted, then I am going to create a separate lp account for the
automated changes.

Currently the webhook works on my home server which has a high uptime,
but still it is not as reliable as dedicated servers. If there is
someone willing to host it on a better machine, I will be pleased to help.

If you are curious about the source code, then I can put it in the KiCad
github (once I get a repository there) or just post it somewhere.

Regards,
Orson

1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
2.
https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
3. https://orson.net.pl/kicad_git_hook

> Before every starts beating the GitHub drum, I have one major issue with
> GitHub and that is control.  There is no way that I know of to moderate
> a project on github.  Anyone with a github account can submit a pull
> requests at anytime even if they are not part of the dev team.  As
> project leader, this is an issue.  I'm already a my limit with the
> development team we have in place and I really don't want to deal with a
> wide open code hosting.  I also have no way of removing someone from the
> list should I need to.  I know it hasn't happened yet but I am not naive
> enough to think that it wont happen.  At this time, I am more
> comfortable with LP until something better comes along or we take full
> control a provide our own hosting.
> 
> On 8/8/2016 3:58 AM, Maciej Sumiński wrote:
>> Apparently we have not discussed git transition for a long time now, so
>> I felt it is the right time to raise the subject again to keep our routine.
>>
>> Launchpad now supports merge proposals [1] and it looks like they are
>> still improving git integration. The only missing feature are links
>> between bug fixing commits and respective bug reports (bzr commit ...
>> --fixes=lp:123456). It is not supported by git itself, but might be
>> resolved using webhooks [2] and appropriate keywords in commit messages
>> (e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
>> obstacle, then I volunteer to provide code for the hook.
>>
>> What do you think? Is there anything else that prevents transition?
>>
>> Regards,
>> Orson
>>
>> 1. https://help.launchpad.net/Code/Git
>> 2. https://help.launchpad.net/API/Webhooks
>>
>>
>>
>> ___
>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Git transition

[John Beard]

I understand that many people will be using the Bzr UI tools, but Git is
very good at enabling digging in the history using the command line.

I have a handy Git alias which shows me a condensed version of the history
(it's actually coloured in my terminal, so it's really clear what's going on):

* 9f5f0ab (upstream/master) Minor OpenGL GAL code changes
| * 53b2afd (HEAD -> master) Fix .gitconfig syntax
|/
* 7bc8cb5 Fix bug: Impossible to rescale 3D models

The alias is

lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all

lol shows only current or specified branches, lola shows all branches, as above.
From [1]. Very handy for scanning though and seeing where you are, and can be
piped to grep. You can modify the alias to also print the commit
author name too,
if you like:

lolc = log --graph --decorate --pretty='format:%h %d [%cn] %s' --abbrev-commit

Obviously there are tons of format/print options. So, as Adam was saying,
it is very easy to see what has changed without using email as a middleman, or
having to deal with the full git log.

You also have the --grep options for git log for looking for text in
commit messages,
not to mention -S and -G which only show commits that change the number of
occurrences of a string or contain text within changed lines respectively.

What makes Git so attractive to me is the interactive rebase which means you can
juggle and squash commits extremely easily before sending off. That,
to me, is the
killer feature of Git over Bzr. It provides enormous flexibility to
the developer,
and greatly helps in producing logical commit histories, because you can rebase
unrelated tweaks out as you go along.

The speed helps too!

Cheers,

John

[1] http://blog.kfish.org/2010/04/git-lola.html#!

On Tue, Aug 9, 2016 at 1:02 AM, Chris Pavlina  wrote:
> Well, I can't help with getting email notifications, but I don't
> understand why logs are being grepped either. Getting a summary of
> changes since the last update should be as simple as 'git fetch'
> followed by something like 'git log master..origin/master', and you'll
> get it in a nice summary form :P
>
> Personally I'd go insane if I got an email for every commit ^_^
>
>
> On Mon, Aug 08, 2016 at 12:48:27PM -0400, Wayne Stambaugh wrote:
>> On 8/8/2016 12:23 PM, Chris Pavlina wrote:
>> > Well, we're not looking at Github anymore, right? Just Git on Launchpad?
>> > So the pull request thing doesn't matter.
>> >
>> > We use Stash (Bitbucket) at work, it seems to give much better control.
>> > GitLab is also popular. I really, really want to see us switch to git,
>> > as do many others, but I don't really care about GitHub and I think I'm
>> > not entirely alone. Git is wonderful; GitHub is just a git service, and
>> > honestly a bit of a mediocre one.
>> >
>> > I think there is an advantage to us being on GitHub which is the
>> > community exposure, since it's large and popular. The pull requests are
>> > a side effect of that, one comes with the other. I think we wouldn't
>> > really have a problem closing out frivolous PRs anyway. Also, there are
>> > multiple bots that you can use to "disable" PRs by automatically closing
>> > them, if you really want.
>> >
>> > I'm not sure what sort of notifications you're talking about, but
>> > there's probably already an easy way to do whatever it is you want with
>> > git, without tedious log-grepping. What are Launchpad's notifications
>> > like?
>>
>> Anyone subscribed to lp:kicad will get an email notification of the
>> commit log entry and if the diff is less than 10K (I think) will also
>> get the diff as an attachment when a commit to lp:kicad.  The last time
>> I looked at the implementation status of git on LP, that still wasn't
>> complete unless I am misunderstanding what work they still have left to do.
>>
>> >
>> > On Mon, Aug 08, 2016 at 12:09:34PM -0400, Wayne Stambaugh wrote:
>> >> The last time I looked, notifications of repo commits still were not
>> >> implemented.  This is a show stopper for me.  I don't want to have to
>> >> constantly grep the git commit log to see what changed.  If change
>> >> notifications are working correctly, then I'm OK with moving forward on
>> >> this if you can get the bug fix linking working.  We definitely should
>> >> do some testing before we go live with this.
>> >>
>> >> Before every starts beating the GitHub drum, I have one major issue with
>> >> GitHub and that is control.  There is no way that I know of to moderate
>> >> a project on github.  Anyone with a github account can submit a pull
>> >> requests at anytime even if they are not part of the dev team.  As
>> >> project leader, this is an issue.  I'm already a my limit with the
>> >> development team we have in place and I really don't want to deal with a
>> >> wide open code hosting.  I also have no way of removing someone from the
>> >> list should I need to.  I know it hasn't happened yet but I am not

Re: [Kicad-developers] Git transition

[Tiger12506]

I was really confused for a minute when someone verbosely said git log 
master..origin/master


Here's my current aliases. Aliases really make git awesome. Pay 
particular attention to `git hist` and `git ll` and `git d`


[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --all --pretty=format:\"%h %aN | %C(yellow)%d%Creset%s\" 
--abbrev-commit --graph --date=short

type = cat-file -t
dump = cat-file -p
ll = log --stat --abbrev-commit
d = whatchanged -1 -p
del = !git rm $(git ls-files --deleted)
wd = diff --word-diff
cw = diff --color-words
b = blame -w

Most of these are not my derivation, personally, but are collected from 
various tutorials.


Also, I like gitolite, but that's probably too fine-grained and 
configurable for a project like this, and the downside would be it would 
have to be hosted somewhere. Not trying to influence, just mentioning it 
since no one had.



On 8/8/2016 1:02 PM, Chris Pavlina wrote:

Well, I can't help with getting email notifications, but I don't
understand why logs are being grepped either. Getting a summary of
changes since the last update should be as simple as 'git fetch'
followed by something like 'git log master..origin/master', and you'll
get it in a nice summary form :P

Personally I'd go insane if I got an email for every commit ^_^


On Mon, Aug 08, 2016 at 12:48:27PM -0400, Wayne Stambaugh wrote:

On 8/8/2016 12:23 PM, Chris Pavlina wrote:

Well, we're not looking at Github anymore, right? Just Git on Launchpad?
So the pull request thing doesn't matter.

We use Stash (Bitbucket) at work, it seems to give much better control.
GitLab is also popular. I really, really want to see us switch to git,
as do many others, but I don't really care about GitHub and I think I'm
not entirely alone. Git is wonderful; GitHub is just a git service, and
honestly a bit of a mediocre one.

I think there is an advantage to us being on GitHub which is the
community exposure, since it's large and popular. The pull requests are
a side effect of that, one comes with the other. I think we wouldn't
really have a problem closing out frivolous PRs anyway. Also, there are
multiple bots that you can use to "disable" PRs by automatically closing
them, if you really want.

I'm not sure what sort of notifications you're talking about, but
there's probably already an easy way to do whatever it is you want with
git, without tedious log-grepping. What are Launchpad's notifications
like?

Anyone subscribed to lp:kicad will get an email notification of the
commit log entry and if the diff is less than 10K (I think) will also
get the diff as an attachment when a commit to lp:kicad.  The last time
I looked at the implementation status of git on LP, that still wasn't
complete unless I am misunderstanding what work they still have left to do.


On Mon, Aug 08, 2016 at 12:09:34PM -0400, Wayne Stambaugh wrote:

The last time I looked, notifications of repo commits still were not
implemented.  This is a show stopper for me.  I don't want to have to
constantly grep the git commit log to see what changed.  If change
notifications are working correctly, then I'm OK with moving forward on
this if you can get the bug fix linking working.  We definitely should
do some testing before we go live with this.

Before every starts beating the GitHub drum, I have one major issue with
GitHub and that is control.  There is no way that I know of to moderate
a project on github.  Anyone with a github account can submit a pull
requests at anytime even if they are not part of the dev team.  As
project leader, this is an issue.  I'm already a my limit with the
development team we have in place and I really don't want to deal with a
wide open code hosting.  I also have no way of removing someone from the
list should I need to.  I know it hasn't happened yet but I am not naive
enough to think that it wont happen.  At this time, I am more
comfortable with LP until something better comes along or we take full
control a provide our own hosting.

On 8/8/2016 3:58 AM, Maciej Sumiński wrote:

Apparently we have not discussed git transition for a long time now, so
I felt it is the right time to raise the subject again to keep our routine.

Launchpad now supports merge proposals [1] and it looks like they are
still improving git integration. The only missing feature are links
between bug fixing commits and respective bug reports (bzr commit ...
--fixes=lp:123456). It is not supported by git itself, but might be
resolved using webhooks [2] and appropriate keywords in commit messages
(e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
obstacle, then I volunteer to provide code for the hook.

What do you think? Is there anything else that prevents transition?

Regards,
Orson

1. https://help.launchpad.net/Code/Git
2. https://help.launchpad.net/API/Webhooks



___
Mailing list: https://launchpad.net/~kicad-d

Re: [Kicad-developers] Git transition

[Chris Pavlina]

Well, I can't help with getting email notifications, but I don't
understand why logs are being grepped either. Getting a summary of
changes since the last update should be as simple as 'git fetch'
followed by something like 'git log master..origin/master', and you'll
get it in a nice summary form :P

Personally I'd go insane if I got an email for every commit ^_^


On Mon, Aug 08, 2016 at 12:48:27PM -0400, Wayne Stambaugh wrote:
> On 8/8/2016 12:23 PM, Chris Pavlina wrote:
> > Well, we're not looking at Github anymore, right? Just Git on Launchpad?
> > So the pull request thing doesn't matter.
> > 
> > We use Stash (Bitbucket) at work, it seems to give much better control.
> > GitLab is also popular. I really, really want to see us switch to git,
> > as do many others, but I don't really care about GitHub and I think I'm
> > not entirely alone. Git is wonderful; GitHub is just a git service, and
> > honestly a bit of a mediocre one.
> > 
> > I think there is an advantage to us being on GitHub which is the
> > community exposure, since it's large and popular. The pull requests are
> > a side effect of that, one comes with the other. I think we wouldn't
> > really have a problem closing out frivolous PRs anyway. Also, there are
> > multiple bots that you can use to "disable" PRs by automatically closing
> > them, if you really want.
> > 
> > I'm not sure what sort of notifications you're talking about, but
> > there's probably already an easy way to do whatever it is you want with
> > git, without tedious log-grepping. What are Launchpad's notifications
> > like?
> 
> Anyone subscribed to lp:kicad will get an email notification of the
> commit log entry and if the diff is less than 10K (I think) will also
> get the diff as an attachment when a commit to lp:kicad.  The last time
> I looked at the implementation status of git on LP, that still wasn't
> complete unless I am misunderstanding what work they still have left to do.
> 
> > 
> > On Mon, Aug 08, 2016 at 12:09:34PM -0400, Wayne Stambaugh wrote:
> >> The last time I looked, notifications of repo commits still were not
> >> implemented.  This is a show stopper for me.  I don't want to have to
> >> constantly grep the git commit log to see what changed.  If change
> >> notifications are working correctly, then I'm OK with moving forward on
> >> this if you can get the bug fix linking working.  We definitely should
> >> do some testing before we go live with this.
> >>
> >> Before every starts beating the GitHub drum, I have one major issue with
> >> GitHub and that is control.  There is no way that I know of to moderate
> >> a project on github.  Anyone with a github account can submit a pull
> >> requests at anytime even if they are not part of the dev team.  As
> >> project leader, this is an issue.  I'm already a my limit with the
> >> development team we have in place and I really don't want to deal with a
> >> wide open code hosting.  I also have no way of removing someone from the
> >> list should I need to.  I know it hasn't happened yet but I am not naive
> >> enough to think that it wont happen.  At this time, I am more
> >> comfortable with LP until something better comes along or we take full
> >> control a provide our own hosting.
> >>
> >> On 8/8/2016 3:58 AM, Maciej Sumiński wrote:
> >>> Apparently we have not discussed git transition for a long time now, so
> >>> I felt it is the right time to raise the subject again to keep our 
> >>> routine.
> >>>
> >>> Launchpad now supports merge proposals [1] and it looks like they are
> >>> still improving git integration. The only missing feature are links
> >>> between bug fixing commits and respective bug reports (bzr commit ...
> >>> --fixes=lp:123456). It is not supported by git itself, but might be
> >>> resolved using webhooks [2] and appropriate keywords in commit messages
> >>> (e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
> >>> obstacle, then I volunteer to provide code for the hook.
> >>>
> >>> What do you think? Is there anything else that prevents transition?
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>> 1. https://help.launchpad.net/Code/Git
> >>> 2. https://help.launchpad.net/API/Webhooks
> >>>
> >>>
> >>>
> >>> ___
> >>> 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

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kica

Re: [Kicad-developers] Git transition

[Wayne Stambaugh]

On 8/8/2016 12:23 PM, Chris Pavlina wrote:
> Well, we're not looking at Github anymore, right? Just Git on Launchpad?
> So the pull request thing doesn't matter.
> 
> We use Stash (Bitbucket) at work, it seems to give much better control.
> GitLab is also popular. I really, really want to see us switch to git,
> as do many others, but I don't really care about GitHub and I think I'm
> not entirely alone. Git is wonderful; GitHub is just a git service, and
> honestly a bit of a mediocre one.
> 
> I think there is an advantage to us being on GitHub which is the
> community exposure, since it's large and popular. The pull requests are
> a side effect of that, one comes with the other. I think we wouldn't
> really have a problem closing out frivolous PRs anyway. Also, there are
> multiple bots that you can use to "disable" PRs by automatically closing
> them, if you really want.
> 
> I'm not sure what sort of notifications you're talking about, but
> there's probably already an easy way to do whatever it is you want with
> git, without tedious log-grepping. What are Launchpad's notifications
> like?

Anyone subscribed to lp:kicad will get an email notification of the
commit log entry and if the diff is less than 10K (I think) will also
get the diff as an attachment when a commit to lp:kicad.  The last time
I looked at the implementation status of git on LP, that still wasn't
complete unless I am misunderstanding what work they still have left to do.

> 
> On Mon, Aug 08, 2016 at 12:09:34PM -0400, Wayne Stambaugh wrote:
>> The last time I looked, notifications of repo commits still were not
>> implemented.  This is a show stopper for me.  I don't want to have to
>> constantly grep the git commit log to see what changed.  If change
>> notifications are working correctly, then I'm OK with moving forward on
>> this if you can get the bug fix linking working.  We definitely should
>> do some testing before we go live with this.
>>
>> Before every starts beating the GitHub drum, I have one major issue with
>> GitHub and that is control.  There is no way that I know of to moderate
>> a project on github.  Anyone with a github account can submit a pull
>> requests at anytime even if they are not part of the dev team.  As
>> project leader, this is an issue.  I'm already a my limit with the
>> development team we have in place and I really don't want to deal with a
>> wide open code hosting.  I also have no way of removing someone from the
>> list should I need to.  I know it hasn't happened yet but I am not naive
>> enough to think that it wont happen.  At this time, I am more
>> comfortable with LP until something better comes along or we take full
>> control a provide our own hosting.
>>
>> On 8/8/2016 3:58 AM, Maciej Sumiński wrote:
>>> Apparently we have not discussed git transition for a long time now, so
>>> I felt it is the right time to raise the subject again to keep our routine.
>>>
>>> Launchpad now supports merge proposals [1] and it looks like they are
>>> still improving git integration. The only missing feature are links
>>> between bug fixing commits and respective bug reports (bzr commit ...
>>> --fixes=lp:123456). It is not supported by git itself, but might be
>>> resolved using webhooks [2] and appropriate keywords in commit messages
>>> (e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
>>> obstacle, then I volunteer to provide code for the hook.
>>>
>>> What do you think? Is there anything else that prevents transition?
>>>
>>> Regards,
>>> Orson
>>>
>>> 1. https://help.launchpad.net/Code/Git
>>> 2. https://help.launchpad.net/API/Webhooks
>>>
>>>
>>>
>>> ___
>>> 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

___
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] Git transition

[Chris Pavlina]

Well, we're not looking at Github anymore, right? Just Git on Launchpad?
So the pull request thing doesn't matter.

We use Stash (Bitbucket) at work, it seems to give much better control.
GitLab is also popular. I really, really want to see us switch to git,
as do many others, but I don't really care about GitHub and I think I'm
not entirely alone. Git is wonderful; GitHub is just a git service, and
honestly a bit of a mediocre one.

I think there is an advantage to us being on GitHub which is the
community exposure, since it's large and popular. The pull requests are
a side effect of that, one comes with the other. I think we wouldn't
really have a problem closing out frivolous PRs anyway. Also, there are
multiple bots that you can use to "disable" PRs by automatically closing
them, if you really want.

I'm not sure what sort of notifications you're talking about, but
there's probably already an easy way to do whatever it is you want with
git, without tedious log-grepping. What are Launchpad's notifications
like?

On Mon, Aug 08, 2016 at 12:09:34PM -0400, Wayne Stambaugh wrote:
> The last time I looked, notifications of repo commits still were not
> implemented.  This is a show stopper for me.  I don't want to have to
> constantly grep the git commit log to see what changed.  If change
> notifications are working correctly, then I'm OK with moving forward on
> this if you can get the bug fix linking working.  We definitely should
> do some testing before we go live with this.
> 
> Before every starts beating the GitHub drum, I have one major issue with
> GitHub and that is control.  There is no way that I know of to moderate
> a project on github.  Anyone with a github account can submit a pull
> requests at anytime even if they are not part of the dev team.  As
> project leader, this is an issue.  I'm already a my limit with the
> development team we have in place and I really don't want to deal with a
> wide open code hosting.  I also have no way of removing someone from the
> list should I need to.  I know it hasn't happened yet but I am not naive
> enough to think that it wont happen.  At this time, I am more
> comfortable with LP until something better comes along or we take full
> control a provide our own hosting.
> 
> On 8/8/2016 3:58 AM, Maciej Sumiński wrote:
> > Apparently we have not discussed git transition for a long time now, so
> > I felt it is the right time to raise the subject again to keep our routine.
> > 
> > Launchpad now supports merge proposals [1] and it looks like they are
> > still improving git integration. The only missing feature are links
> > between bug fixing commits and respective bug reports (bzr commit ...
> > --fixes=lp:123456). It is not supported by git itself, but might be
> > resolved using webhooks [2] and appropriate keywords in commit messages
> > (e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
> > obstacle, then I volunteer to provide code for the hook.
> > 
> > What do you think? Is there anything else that prevents transition?
> > 
> > Regards,
> > Orson
> > 
> > 1. https://help.launchpad.net/Code/Git
> > 2. https://help.launchpad.net/API/Webhooks
> > 
> > 
> > 
> > ___
> > 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

___
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] Git transition

[Wayne Stambaugh]

The last time I looked, notifications of repo commits still were not
implemented.  This is a show stopper for me.  I don't want to have to
constantly grep the git commit log to see what changed.  If change
notifications are working correctly, then I'm OK with moving forward on
this if you can get the bug fix linking working.  We definitely should
do some testing before we go live with this.

Before every starts beating the GitHub drum, I have one major issue with
GitHub and that is control.  There is no way that I know of to moderate
a project on github.  Anyone with a github account can submit a pull
requests at anytime even if they are not part of the dev team.  As
project leader, this is an issue.  I'm already a my limit with the
development team we have in place and I really don't want to deal with a
wide open code hosting.  I also have no way of removing someone from the
list should I need to.  I know it hasn't happened yet but I am not naive
enough to think that it wont happen.  At this time, I am more
comfortable with LP until something better comes along or we take full
control a provide our own hosting.

On 8/8/2016 3:58 AM, Maciej Sumiński wrote:
> Apparently we have not discussed git transition for a long time now, so
> I felt it is the right time to raise the subject again to keep our routine.
> 
> Launchpad now supports merge proposals [1] and it looks like they are
> still improving git integration. The only missing feature are links
> between bug fixing commits and respective bug reports (bzr commit ...
> --fixes=lp:123456). It is not supported by git itself, but might be
> resolved using webhooks [2] and appropriate keywords in commit messages
> (e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
> obstacle, then I volunteer to provide code for the hook.
> 
> What do you think? Is there anything else that prevents transition?
> 
> Regards,
> Orson
> 
> 1. https://help.launchpad.net/Code/Git
> 2. https://help.launchpad.net/API/Webhooks
> 
> 
> 
> ___
> 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

Re: [Kicad-developers] Git transition

[Adam Wolf]

Hi Maciej,

It would be a net benefit for the OS X builder for us to switch to git.
The Jenkins bzr plugin is not very good.  Usually when the OS X nightlies
stop for a few days, it is because the plugin got stuck updating and never
times out.  I tried to fix it upstream but there were issues.

It is not an emergency but it would be nice.

Adam Wolf

On Mon, Aug 8, 2016 at 2:58 AM, Maciej Sumiński 
wrote:

> Apparently we have not discussed git transition for a long time now, so
> I felt it is the right time to raise the subject again to keep our routine.
>
> Launchpad now supports merge proposals [1] and it looks like they are
> still improving git integration. The only missing feature are links
> between bug fixing commits and respective bug reports (bzr commit ...
> --fixes=lp:123456). It is not supported by git itself, but might be
> resolved using webhooks [2] and appropriate keywords in commit messages
> (e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
> obstacle, then I volunteer to provide code for the hook.
>
> What do you think? Is there anything else that prevents transition?
>
> Regards,
> Orson
>
> 1. https://help.launchpad.net/Code/Git
> 2. https://help.launchpad.net/API/Webhooks
>
>
> ___
> 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] Git transition

[Maciej Sumiński]

Apparently we have not discussed git transition for a long time now, so
I felt it is the right time to raise the subject again to keep our routine.

Launchpad now supports merge proposals [1] and it looks like they are
still improving git integration. The only missing feature are links
between bug fixing commits and respective bug reports (bzr commit ...
--fixes=lp:123456). It is not supported by git itself, but might be
resolved using webhooks [2] and appropriate keywords in commit messages
(e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
obstacle, then I volunteer to provide code for the hook.

What do you think? Is there anything else that prevents transition?

Regards,
Orson

1. https://help.launchpad.net/Code/Git
2. https://help.launchpad.net/API/Webhooks



signature.asc
Description: OpenPGP digital signature
___
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