[Kicad-developers] Couple raytracer "problems"/questions

[Chris Pavlina]

Mostly asking Mário here - couple slight issues/questions with the
raytracer..

https://misc.c4757p.com/raytrace-example.png

1) Am I the only one getting missing chunks in the corner like that?
That happens very often for me.

2) Any necessary reason why it's so grainy?


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

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 

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   : 

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

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
>

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

[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