Re: [Kicad-developers] Developer documentation on new website.

[Nick Østergaard]

I did that intentionally. The front page body text page is empty, so I
would rather motivate people to see the coding style policy, than an
empty page.

2015-09-12 18:37 GMT+02:00 Wayne Stambaugh :
> Looks good except the link points to the coding policy rather than the
> top level index of the documentation.
>
> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/index.html
>
> On 9/12/2015 12:11 PM, Nick Østergaard wrote:
>> I have added a description here:
>> https://github.com/KiCad/kicad-website/commit/22159855b4e1e4eeaad14278a4d1041c69baa6b2
>>
>> 2015-09-11 23:27 GMT+02:00 Nick Østergaard :
>>> Where would you like it? In the descriptions on the developers page or
>>> in the menu system directly?
>>>
>>> 2015-09-11 23:13 GMT+02:00 Wayne Stambaugh :
 There is no direct link to the developer documentation on the website.
 I can get there indirectly by click on the coding policy link but I
 think there should be a direct link somewhere in the developers section.
  Can someone please take a look at this when they get a chance?

 Thanks,

 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] Developer documentation on new website.

[Mark Roszko]

We have build instructions via Download > Source Code
http://kicad-pcb.org/download/source/

___
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] Developer documentation on new website.

[Wayne Stambaugh]

Looks good except the link points to the coding policy rather than the
top level index of the documentation.

http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/index.html

On 9/12/2015 12:11 PM, Nick Østergaard wrote:
> I have added a description here:
> https://github.com/KiCad/kicad-website/commit/22159855b4e1e4eeaad14278a4d1041c69baa6b2
> 
> 2015-09-11 23:27 GMT+02:00 Nick Østergaard :
>> Where would you like it? In the descriptions on the developers page or
>> in the menu system directly?
>>
>> 2015-09-11 23:13 GMT+02:00 Wayne Stambaugh :
>>> There is no direct link to the developer documentation on the website.
>>> I can get there indirectly by click on the coding policy link but I
>>> think there should be a direct link somewhere in the developers section.
>>>  Can someone please take a look at this when they get a chance?
>>>
>>> Thanks,
>>>
>>> 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

[Kicad-developers] Export to IPC-2581

[timofonic timofonic]

Hello.

In order to not hijack the ODB++ discussion, here's this other message.

Is IPC-2581 support feasible? They mention about being open. But I'm not
sure how open, because isn't an ISO/IEC/ECMA/IEEE standard and that worries
me.

It seems most IPC standards require certification and documentation is
sold, not free at all.

Here's an old "bug" about adding IPC-2581 support: https
://
bugs.launchpad.net
/
kicad
/+bug/594013


This is the related IPC-2581 open source stuff I found:
https://github.com/curtacircuitos/pcb-tools/commit/29deffcf77e963ae81aec9f8cbc61b029f3052d5
https://github.com/Cobra-Kao/ipc2581_to_odb

A Japanese guy said the following: " As a hobby, wrote my own IPC-2581
parser which covers all (161?) tags. Used Perl script to automatically
generate most part (about 7000 lines in C++) of parser code, from "formal"
format definition in xsd (2249 lines)."
http://www.naymz.com/takushiitadani2813467
http://www.yatedo.fr/p/Takushi+Itadani/normal/1150312ae839c4d532298caf9921387c

Some subtle reference to IPC-2581

It's free to join the consortium, but it requires a corporate entity it
seems: http://www.ipc2581.com/index.php/join-the-consortia

There's Associate Membership too:
http://www.ipc2581.com/index.php/associate-membership

Here are free viewers: http://
www.ipc2581.com
/
index.php
/ipc-2581-files


Some general information, press releases and such

http://www.eevblog.com/2012/09/13/eevblog-349-smcba-lecture-ipc-2581-open-standards-for-pcb-design-data/

An user said the following about IPC-2581: "IPC-2581 is similar to the
Linux OS as it's an open source code with a consortium developing it.
Hopefully there will only be one flavor."
http://www.pcblibraries.com/forum/ipc2581_topic886.html

http://www.multi-circuit-boards.eu/en/support/pcb-data/ipc-2581.html
http://web.archive.org/web/20140806104621/http://www.cadence.com/Community/blogs/ii/archive/2012/10/02/pcb-west-update-how-ipc-2581-data-transfer-standard-is-moving-forward.aspx

Academic paper describing stuff to add to PCBNEW, including IPC-2581:
BIDULOCK, Brian. PCBNEW Wishlists, Blueprints, Design and Implementation
Notes. 2010.
http://www.openss7.org/docs/NOTES.pdf

http://www.cadence.com/products/pcb/pages/ipc.aspx

http://www.odb-sa.com/community/topic/article-mentor-to-support-ipc-2581-to-printed-circuit-design-fab-magazine-on/

http://pcdandf.com/pcdesign/index.php/news-itemid-fix/7627-mentor-to-support-ipc-2581

http://www.eetimes.com/author.asp?section_id=36_id=1319781

http://www.pcb-investigator.com/en/forum/ipc2581-better-odb

http://signal-integrity.blogs.keysight.com/2012/o-is-for/

http://techdocs.altium.com/display/ADOH/IPC-2581+Support (ironically, you
need to BUY the plugin)
On Sep 12, 2015 6:11 PM, "Tomasz Wlostowski" 
wrote:

On 12.09.2015 18:04, Chris Pavlina wrote:
> Not GPL-compatible because the restriction would apply to anyone making
> a derivative of KiCad as well. The only way I can see to do this is a
> clean-room reverse engineering, which does not appear to be feasible.

Use plugins. The ODB++/IPC-2581 ones could be kept outside mainline
Kicad if we would ensure they can be easily installed by a non-programmer.

- my 5 cents,
Tom



>
> On Sep 10, 2015 12:48 PM, "Mark Roszko"  > wrote:
>
> Nope, you don't have to advertise for Mentor Graphics
>
> Here are the terms:
>
> 4. PROMOTION.
>
> Participant agrees to promote the integration between the ODB++ Format
> and the Participant Products by: (i) joining the ODB++ Solutions
> Alliance as a “solutions development partnering” member, via the ODB++
> Website, including providing a quote about Participant’s ODB++ Format
> implementation for use in Mentor Graphics’ promotional materials and
> on the ODB++ Website; (ii) allowing Mentor Graphics to use
> Participant’s logo in Mentor Graphics promotional materials and on the
> ODB++ Website; (iii) including a brief factual statement on the ODB++
> Format implementation in Participant’s promotional materials and a
> link from Participant’s website to the ODB++ Website; (iv) making a
> visible acknowledgement in the Participant’s Products (user-interface
> and documentation) of the support received from Mentor Graphics under
> this Agreement for the implementation of the ODB++ Format; and (v)
> agreeing to the publication by Mentor Graphics of the existence 

Re: [Kicad-developers] FW: Export to ODB++

[Lorenzo Marcantonio]

On Sat, Sep 12, 2015 at 06:01:30PM +0200, timofonic timofonic wrote:
> I see.
> 
> What about IPC-2581? Is really open? Do PCB manufacturers support it?

IPC specs are usually open as in 'buy the paper and then you can
implement it'; no consortium, no mandatory fee/royalties/whatever.

As in manufacturers support, my experience is that manufacturers just
supports gerbers/excellon and maybe one or two CAD packages they have
available (usually OrCAD and/or PADS); OTOH since it seems that *all* of
them are using genesis 2000 (at least here in italy), they could support
OBD++ (but maybe that's an additional license in genesis to buy!)

-- 
Lorenzo Marcantonio
Logos Srl

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

[Cirilo Bernardo]

I had the impression that it would be a separate branch and that a number
of people would back-port any necessary patches but no new features may
be introduced. I think that arrangement would keep your generic package
maintainers and sysadmins happy; we've had so many complaints from
people about the product branch despite its stability and usability and
many admins have said they don't care about new features and would only
like to be able to tell their bosses that the upstream people have tagged
the branch as a release.

- Cirilo


On Sun, Sep 13, 2015 at 5:37 AM, Wayne Stambaugh 
wrote:

> I created the new series on Lauchpad a few hours ago.  I still have to
> decide whether to link it to the product branch or make it a separate
> source branch.  I'm still trying to wrap my head around it as well as
> get these last few dialog fixes committed.
>
> On 9/12/2015 3:33 PM, Jon Neal wrote:
> > So I don't think it is Friday in any part of the world anymore.
> >
> > Any update on the branch? :)
> >
> > Jon
> >
> > On Sat, Sep 12, 2015 at 12:18 PM, Nick Østergaard  > > wrote:
> >
> > For your (and others) information, in the current moment of writing
> > this email, there are no more critical or high bugs on the tracker.
> >
> > 2015-09-08 21:34 GMT+02:00 Wayne Stambaugh  > >:
> > > I think the current situation is as good as we can hope for as far
> as
> > > blockers for rc1. I'm going to try to create a new version 4 stable
> > > release series on Launchpad Friday if no new show stoppers crop up.
> > > Periodically I will merge any bug fixes from the product branch
> > into the
> > > 4 stable series branch and increment the rc number. If we manage
> to go
> > > a few weeks with no new crash or data loss bugs, I will tag it a
> > stable
> > > release.
> > >
> > > On 9/8/2015 3:02 PM, Nick Østergaard wrote:
> > >> Wayne, was it your intention to include the incomplete bugs in the
> > >> blockers for rc1? I mean, incomplete bugs are bugs that have a
> > >> potential to be revived, but where the developers are not really
> > >> supposed to spend more time on them until some feedback are given.
> > >>
> > >> I personally don't think they should be included in that list,
> > even if
> > >> critical or high or not.
> > >>
> > >> 2015-09-06 22:11 GMT+02:00 Wayne Stambaugh  > >:
> > >>> This is a reminder to *all* developers, please do not send any
> > patches
> > >>> or merge requests unless it is specifically to fix an existing
> bug
> > >>> report. Also, please don't bother fixing the build scripts or
> any of
> > >>> the CMake dependency library build code as they will be removed
> > during
> > >>> the next development cycle. My preference is that we focus on the
> > >>> critical bug reports that are keeping me from creating an rc1
> > branch.
> > >>> They can be found here:
> > >>>
> > >>>
> >
> https://bugs.launchpad.net/kicad/+bugs?field.searchtext==-importance=Search%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CRITICAL%3Alist=HIGH_option=any=_reporter=_commenter==_subscriber==_combinator=ANY_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on
> > >>>
> > >>> This list needs to get to zero before I'm willing to create any
> > rc1 branch.
> > >>>
> > >>> Thank you for your cooperation.
> > >>>
> > >>> 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] Developer documentation on new website.

[Wayne Stambaugh]

That's fine for now.  At some point, we should add some content to the
top level page even if it's just a simple blurb about this being the
KiCad developers documentation.  At some point, I would like to port our
build/install instructions and the UI policy to markdown so that also
gets including in the developers docs.

Thanks,

Wayne

On 9/12/2015 12:42 PM, Nick Østergaard wrote:
> I did that intentionally. The front page body text page is empty, so I
> would rather motivate people to see the coding style policy, than an
> empty page.
> 
> 2015-09-12 18:37 GMT+02:00 Wayne Stambaugh :
>> Looks good except the link points to the coding policy rather than the
>> top level index of the documentation.
>>
>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/index.html
>>
>> On 9/12/2015 12:11 PM, Nick Østergaard wrote:
>>> I have added a description here:
>>> https://github.com/KiCad/kicad-website/commit/22159855b4e1e4eeaad14278a4d1041c69baa6b2
>>>
>>> 2015-09-11 23:27 GMT+02:00 Nick Østergaard :
 Where would you like it? In the descriptions on the developers page or
 in the menu system directly?

 2015-09-11 23:13 GMT+02:00 Wayne Stambaugh :
> There is no direct link to the developer documentation on the website.
> I can get there indirectly by click on the coding policy link but I
> think there should be a direct link somewhere in the developers section.
>  Can someone please take a look at this when they get a chance?
>
> Thanks,
>
> 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] Developer documentation on new website.

[Wayne Stambaugh]

I did not notice that.  Maybe we should do away with the plain text
install files in the source repo rather than maintain it in two places.

On 9/12/2015 2:42 PM, Mark Roszko wrote:
> We have build instructions via Download > Source Code
> http://kicad-pcb.org/download/source/
> 


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

[Wayne Stambaugh]

I created the new series on Lauchpad a few hours ago.  I still have to
decide whether to link it to the product branch or make it a separate
source branch.  I'm still trying to wrap my head around it as well as
get these last few dialog fixes committed.

On 9/12/2015 3:33 PM, Jon Neal wrote:
> So I don't think it is Friday in any part of the world anymore.
> 
> Any update on the branch? :)
> 
> Jon
> 
> On Sat, Sep 12, 2015 at 12:18 PM, Nick Østergaard  > wrote:
> 
> For your (and others) information, in the current moment of writing
> this email, there are no more critical or high bugs on the tracker.
> 
> 2015-09-08 21:34 GMT+02:00 Wayne Stambaugh  >:
> > I think the current situation is as good as we can hope for as far as
> > blockers for rc1. I'm going to try to create a new version 4 stable
> > release series on Launchpad Friday if no new show stoppers crop up.
> > Periodically I will merge any bug fixes from the product branch
> into the
> > 4 stable series branch and increment the rc number. If we manage to go
> > a few weeks with no new crash or data loss bugs, I will tag it a
> stable
> > release.
> >
> > On 9/8/2015 3:02 PM, Nick Østergaard wrote:
> >> Wayne, was it your intention to include the incomplete bugs in the
> >> blockers for rc1? I mean, incomplete bugs are bugs that have a
> >> potential to be revived, but where the developers are not really
> >> supposed to spend more time on them until some feedback are given.
> >>
> >> I personally don't think they should be included in that list,
> even if
> >> critical or high or not.
> >>
> >> 2015-09-06 22:11 GMT+02:00 Wayne Stambaugh  >:
> >>> This is a reminder to *all* developers, please do not send any
> patches
> >>> or merge requests unless it is specifically to fix an existing bug
> >>> report. Also, please don't bother fixing the build scripts or any of
> >>> the CMake dependency library build code as they will be removed
> during
> >>> the next development cycle. My preference is that we focus on the
> >>> critical bug reports that are keeping me from creating an rc1
> branch.
> >>> They can be found here:
> >>>
> >>>
> 
> https://bugs.launchpad.net/kicad/+bugs?field.searchtext==-importance=Search%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CRITICAL%3Alist=HIGH_option=any=_reporter=_commenter==_subscriber==_combinator=ANY_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on
> >>>
> >>> This list needs to get to zero before I'm willing to create any
> rc1 branch.
> >>>
> >>> Thank you for your cooperation.
> >>>
> >>> 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] Reminder

[Wayne Stambaugh]

There is a separate branch and the only back ports after the stable
release will be critical bugs.  As of my recent announcement, there
should be some happy admins.

On 9/12/2015 6:36 PM, Cirilo Bernardo wrote:
> I had the impression that it would be a separate branch and that a number
> of people would back-port any necessary patches but no new features may
> be introduced. I think that arrangement would keep your generic package
> maintainers and sysadmins happy; we've had so many complaints from
> people about the product branch despite its stability and usability and
> many admins have said they don't care about new features and would only
> like to be able to tell their bosses that the upstream people have tagged
> the branch as a release.
> 
> - Cirilo
> 
> 
> On Sun, Sep 13, 2015 at 5:37 AM, Wayne Stambaugh  > wrote:
> 
> I created the new series on Lauchpad a few hours ago.  I still have to
> decide whether to link it to the product branch or make it a separate
> source branch.  I'm still trying to wrap my head around it as well as
> get these last few dialog fixes committed.
> 
> On 9/12/2015 3:33 PM, Jon Neal wrote:
> > So I don't think it is Friday in any part of the world anymore.
> >
> > Any update on the branch? :)
> >
> > Jon
> >
> > On Sat, Sep 12, 2015 at 12:18 PM, Nick Østergaard  
> > >> wrote:
> >
> > For your (and others) information, in the current moment of writing
> > this email, there are no more critical or high bugs on the tracker.
> >
> > 2015-09-08 21:34 GMT+02:00 Wayne Stambaugh  
> > >>:
> > > I think the current situation is as good as we can hope for as 
> far as
> > > blockers for rc1. I'm going to try to create a new version 4 
> stable
> > > release series on Launchpad Friday if no new show stoppers crop 
> up.
> > > Periodically I will merge any bug fixes from the product branch
> > into the
> > > 4 stable series branch and increment the rc number. If we manage 
> to go
> > > a few weeks with no new crash or data loss bugs, I will tag it a
> > stable
> > > release.
> > >
> > > On 9/8/2015 3:02 PM, Nick Østergaard wrote:
> > >> Wayne, was it your intention to include the incomplete bugs in 
> the
> > >> blockers for rc1? I mean, incomplete bugs are bugs that have a
> > >> potential to be revived, but where the developers are not really
> > >> supposed to spend more time on them until some feedback are 
> given.
> > >>
> > >> I personally don't think they should be included in that list,
> > even if
> > >> critical or high or not.
> > >>
> > >> 2015-09-06 22:11 GMT+02:00 Wayne Stambaugh  
> > >>:
> > >>> This is a reminder to *all* developers, please do not send any
> > patches
> > >>> or merge requests unless it is specifically to fix an existing 
> bug
> > >>> report. Also, please don't bother fixing the build scripts or 
> any of
> > >>> the CMake dependency library build code as they will be removed
> > during
> > >>> the next development cycle. My preference is that we focus on 
> the
> > >>> critical bug reports that are keeping me from creating an rc1
> > branch.
> > >>> They can be found here:
> > >>>
> > >>>
> > 
> https://bugs.launchpad.net/kicad/+bugs?field.searchtext==-importance=Search%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CRITICAL%3Alist=HIGH_option=any=_reporter=_commenter==_subscriber==_combinator=ANY_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on
> > >>>
> > >>> This list needs to get to zero before I'm willing to create any
> > rc1 branch.
> > >>>
> > >>> Thank you for your cooperation.
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Wayne
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> 
> >  >
> > Unsubscribe : 

Re: [Kicad-developers] FW: Export to ODB++

[Dan Walmsley]

I think a plugin would be great, if it helps bring people across to KiCad it 
can only be a good thing?



If you look at the comparison of EDA software on Wikipedia, KiCad is one of the 
few that don’t support some of these formats.



(side note it might be worth updating the Wikipedia page for Kicad and the 
comparison table to reflect latest features)



Its been difficult getting my company to switch because of lack of odb++ (I 
don’t think its important).



Off topic is KiCad the only package with push and shove routing?



If any is interested in working on a plugin id gladly help out.



Thanks Dan





From: Chris Pavlina
Sent: 12 September 2015 17:14
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] FW: Export to ODB++


Yes, while I still strongly dislike the idea of a FOSS project encouraging
that sort of licensing behavior, legally speaking that would work.

Personally I would rather Mentor get stuffed with that restriction, but
your 5 cents are worth more than my two. :D
On Sep 12, 2015 12:11 PM, "Tomasz Wlostowski" 
wrote:

> On 12.09.2015 18:04, Chris Pavlina wrote:
> > Not GPL-compatible because the restriction would apply to anyone making
> > a derivative of KiCad as well. The only way I can see to do this is a
> > clean-room reverse engineering, which does not appear to be feasible.
>
> Use plugins. The ODB++/IPC-2581 ones could be kept outside mainline
> Kicad if we would ensure they can be easily installed by a non-programmer.
>
> - my 5 cents,
> Tom
>
>
>
> >
> > On Sep 10, 2015 12:48 PM, "Mark Roszko"  > > wrote:
> >
> > Nope, you don't have to advertise for Mentor Graphics
> >
> > Here are the terms:
> >
> > 4. PROMOTION.
> >
> > Participant agrees to promote the integration between the ODB++
> Format
> > and the Participant Products by: (i) joining the ODB++ Solutions
> > Alliance as a “solutions development partnering” member, via the
> ODB++
> > Website, including providing a quote about Participant’s ODB++ Format
> > implementation for use in Mentor Graphics’ promotional materials and
> > on the ODB++ Website; (ii) allowing Mentor Graphics to use
> > Participant’s logo in Mentor Graphics promotional materials and on
> the
> > ODB++ Website; (iii) including a brief factual statement on the ODB++
> > Format implementation in Participant’s promotional materials and a
> > link from Participant’s website to the ODB++ Website; (iv) making a
> > visible acknowledgement in the Participant’s Products (user-interface
> > and documentation) of the support received from Mentor Graphics under
> > this Agreement for the implementation of the ODB++ Format; and (v)
> > agreeing to the publication by Mentor Graphics of the existence of
> > Participant’s membership in the ODB++ Solutions Alliance.
> >
> >
> >
> >
> > I highly doubt Altium and Cadence (both large EDA developers) would
> be
> > supporting ODB++ if they have to advertise their competitor. Its just
> > really slapping the logo on the supported products page for ODB++ and
> > some marketing FUD for ODB++ because they really want it to take off
> > for some reason.
> > http://www.odb-sa.com/partners/
> >
> > ___
> > 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] Reminder

[Nick Østergaard]

As it is now it looks kind of seperate. Is that right? It makes more
sense to me that the branch is branched out from product (I guess this
is what you might be calling linked to). I am not too familiar with
bzr.

2015-09-12 21:37 GMT+02:00 Wayne Stambaugh :
> I created the new series on Lauchpad a few hours ago.  I still have to
> decide whether to link it to the product branch or make it a separate
> source branch.  I'm still trying to wrap my head around it as well as
> get these last few dialog fixes committed.
>
> On 9/12/2015 3:33 PM, Jon Neal wrote:
>> So I don't think it is Friday in any part of the world anymore.
>>
>> Any update on the branch? :)
>>
>> Jon
>>
>> On Sat, Sep 12, 2015 at 12:18 PM, Nick Østergaard > > wrote:
>>
>> For your (and others) information, in the current moment of writing
>> this email, there are no more critical or high bugs on the tracker.
>>
>> 2015-09-08 21:34 GMT+02:00 Wayne Stambaugh > >:
>> > I think the current situation is as good as we can hope for as far as
>> > blockers for rc1. I'm going to try to create a new version 4 stable
>> > release series on Launchpad Friday if no new show stoppers crop up.
>> > Periodically I will merge any bug fixes from the product branch
>> into the
>> > 4 stable series branch and increment the rc number. If we manage to go
>> > a few weeks with no new crash or data loss bugs, I will tag it a
>> stable
>> > release.
>> >
>> > On 9/8/2015 3:02 PM, Nick Østergaard wrote:
>> >> Wayne, was it your intention to include the incomplete bugs in the
>> >> blockers for rc1? I mean, incomplete bugs are bugs that have a
>> >> potential to be revived, but where the developers are not really
>> >> supposed to spend more time on them until some feedback are given.
>> >>
>> >> I personally don't think they should be included in that list,
>> even if
>> >> critical or high or not.
>> >>
>> >> 2015-09-06 22:11 GMT+02:00 Wayne Stambaugh > >:
>> >>> This is a reminder to *all* developers, please do not send any
>> patches
>> >>> or merge requests unless it is specifically to fix an existing bug
>> >>> report. Also, please don't bother fixing the build scripts or any of
>> >>> the CMake dependency library build code as they will be removed
>> during
>> >>> the next development cycle. My preference is that we focus on the
>> >>> critical bug reports that are keeping me from creating an rc1
>> branch.
>> >>> They can be found here:
>> >>>
>> >>>
>> 
>> https://bugs.launchpad.net/kicad/+bugs?field.searchtext==-importance=Search%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CRITICAL%3Alist=HIGH_option=any=_reporter=_commenter==_subscriber==_combinator=ANY_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on
>> >>>
>> >>> This list needs to get to zero before I'm willing to create any
>> rc1 branch.
>> >>>
>> >>> Thank you for your cooperation.
>> >>>
>> >>> 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] Reminder

[Ian Woloschin]

Would be possible to also use tags in the GitHub mirror?  GitHub allows you
to do something like this to get a tarball:

https://github.com/KiCad/kicad-source-mirror/tarball/4.0-rc1

Could potentially save some time/effort in manually maintaining tarballs?
I'm not sure if Launchpad has a similar functionality or not.  Manually
creating/hosting a tarball would work too, but might be more effort?

-Ian

On Sat, Sep 12, 2015 at 3:38 PM Wayne Stambaugh 
wrote:

> I created the new series on Lauchpad a few hours ago.  I still have to
> decide whether to link it to the product branch or make it a separate
> source branch.  I'm still trying to wrap my head around it as well as
> get these last few dialog fixes committed.
>
> On 9/12/2015 3:33 PM, Jon Neal wrote:
> > So I don't think it is Friday in any part of the world anymore.
> >
> > Any update on the branch? :)
> >
> > Jon
> >
> > On Sat, Sep 12, 2015 at 12:18 PM, Nick Østergaard  > > wrote:
> >
> > For your (and others) information, in the current moment of writing
> > this email, there are no more critical or high bugs on the tracker.
> >
> > 2015-09-08 21:34 GMT+02:00 Wayne Stambaugh  > >:
> > > I think the current situation is as good as we can hope for as far
> as
> > > blockers for rc1. I'm going to try to create a new version 4 stable
> > > release series on Launchpad Friday if no new show stoppers crop up.
> > > Periodically I will merge any bug fixes from the product branch
> > into the
> > > 4 stable series branch and increment the rc number. If we manage
> to go
> > > a few weeks with no new crash or data loss bugs, I will tag it a
> > stable
> > > release.
> > >
> > > On 9/8/2015 3:02 PM, Nick Østergaard wrote:
> > >> Wayne, was it your intention to include the incomplete bugs in the
> > >> blockers for rc1? I mean, incomplete bugs are bugs that have a
> > >> potential to be revived, but where the developers are not really
> > >> supposed to spend more time on them until some feedback are given.
> > >>
> > >> I personally don't think they should be included in that list,
> > even if
> > >> critical or high or not.
> > >>
> > >> 2015-09-06 22:11 GMT+02:00 Wayne Stambaugh  > >:
> > >>> This is a reminder to *all* developers, please do not send any
> > patches
> > >>> or merge requests unless it is specifically to fix an existing
> bug
> > >>> report. Also, please don't bother fixing the build scripts or
> any of
> > >>> the CMake dependency library build code as they will be removed
> > during
> > >>> the next development cycle. My preference is that we focus on the
> > >>> critical bug reports that are keeping me from creating an rc1
> > branch.
> > >>> They can be found here:
> > >>>
> > >>>
> >
> https://bugs.launchpad.net/kicad/+bugs?field.searchtext==-importance=Search%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CRITICAL%3Alist=HIGH_option=any=_reporter=_commenter==_subscriber==_combinator=ANY_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on
> > >>>
> > >>> This list needs to get to zero before I'm willing to create any
> > rc1 branch.
> > >>>
> > >>> Thank you for your cooperation.
> > >>>
> > >>> 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

[Kicad-developers] Any pointers to the core of this problem with DXF poly import in footprint editor?

[Marco Hess]

On and off I have been looking into getting DXF drawings imported as 
filled polygons

on copper layers.

While this is working fine in pcbnew, I have been bumping into a problem 
doing the same
the module editor. The problem is that the polygon looses the polygon 
coordinates on

the import and things go downhill from there (i.e. segfaults).

Still being very fresh to KiCad code and development, it's been a road 
of discovery as to
how to get a debug session of pcbnew working, but I now managed to get a 
debug session

with some more info illustrating this problem.

However, I have no idea how to go from here as I am definitely not a C++ 
wiz of any kind.


I am hoping somebody has an Aha moment with the info below or can 
provide a pointer

towards the core problem.

So here are the GDB steps (on Fedora Linux):

Running the footprint editor and creating a new footprint. Then going 
through the DXF import
dialog to select a DXF file. The import itself has 
DXF2BRD_CONVERTER::addPolyline

modified to create an S_POLYGON shape instead of a series of lines.

As this works Ok in pcbnew I suspect that code is at least half right.

Now from pressing Ok in the DXF import dialog, I break in 
dialog_dxf_import.cpp line 281:


Breakpoint 1, InvokeDXFDialogModuleImport (aCaller=0x2942870, 
aModule=0x952600)
at 
/home/marco/KiCad/src/kicad/pcbnew/import_dxf/dialog_dxf_import.cpp:281

281aModule->Add( converted );

This are the relevant source lines showing we had the break point just 
after the static cast

assignment in line 280:

(gdb) list
276{
277case PCB_LINE_T:
278{
279converted = new EDGE_MODULE( aModule );
280*static_cast( converted ) = 
*static_cast( item );

281aModule->Add( converted );
282static_cast( converted 
)->SetLocalCoord();

283delete item;
284break;
285}

Displaying the imported 'item' variable with m_PolyPoints vector filled 
with the points from the DXF:


(gdb) print *static_cast(item)
$6 = { = { = { = {
_vptr.VIEW_ITEM = 0x7fffd7faf590 ,
m_view = 0x0, m_flags = 1, m_requiredUpdate = 0, m_groups = 0x0,
m_groupsSize = 0, m_layers = std::bitset}, m_StructType = 
PCB_LINE_T,
  m_Status = 0, Pnext = 0x0, Pback = 0x0, m_List = 0x0, m_Parent = 
0x0,
  m_TimeStamp = 0, m_forceVisible = false, m_Flags = 0, m_Image = 
0x0},

m_Layer = F_Cu, static ZeroOffset = {x = 0, y = 0}}, m_Width = 100,
  m_Start = {x = 0, y = 0}, m_End = {x = 0, y = 0}, m_Shape = S_POLYGON,
  m_Type = 11, m_Angle = 0, m_BezierC1 = {x = 0, y = 0}, m_BezierC2 = 
{x = 0,

y = 0}, m_BezierPoints = std::vector of length 0, capacity 0,
  m_PolyPoints = std::vector of length 29, capacity 29 = {{x = 188501100,
  y = 104003600}, {x = 188501100, y = 105003600}, {x = 198501100,
  y = 105003600}, {x = 198501100, y = 94003600}, {x = 194501100,
  y = 94003600}, {x = 194501100, y = 93003600}, {x = 198501100,
  y = 93003600}, {x = 198501100, y = 90003600}, {x = 194501100,
  y = 90003600}, {x = 194501100, y = 89003600}, {x = 198501100,
  y = 89003600}, {x = 198501100, y = 85003600}, {x = 193501100,
  y = 85003600}, {x = 193501100, y = 87003600}, {x = 197501100,
  y = 87003600}, {x = 197501100, y = 88003600}, {x = 193501100,
  y = 88003600}, {x = 193501100, y = 91003600}, {x = 197501100,
  y = 91003600}, {x = 197501100, y = 92003600}, {x = 193501100,
  y = 92003600}, {x = 193501100, y = 95003600}, {x = 197501100,
  y = 95003600}, {x = 197501100, y = 97003600}, {x = 188501100,
  y = 97003600}, {x = 188501100, y = 98003600}, {x = 197501100,
  y = 98003600}, {x = 197501100, y = 104003600}, {x = 188501100,
  y = 104003600}}}

And now the 'converted' variable. The m_PolyPoints is now empty!

(gdb) print *static_cast(converted)
$7 = { = { = { = {
_vptr.VIEW_ITEM = 0x7fffd7faf720 ,
m_view = 0x0, m_flags = 1, m_requiredUpdate = 0, m_groups = 0x0,
m_groupsSize = 0, m_layers = std::bitset},
  m_StructType = PCB_MODULE_EDGE_T, m_Status = 0, Pnext = 0x0,
  Pback = 0x0, m_List = 0x0, m_Parent = 0x952600, m_TimeStamp = 0,
  m_forceVisible = false, m_Flags = 0, m_Image = 0x0}, m_Layer = F_Cu,
static ZeroOffset = {x = 0, y = 0}}, m_Width = 100, m_Start = {x = 0,
y = 0}, m_End = {x = 0, y = 0}, m_Shape = S_POLYGON, m_Type = 11,
  m_Angle = 0, m_BezierC1 = {x = 0, y = 0}, m_BezierC2 = {x = 0, y = 0},
  m_BezierPoints = std::vector of length 0, capacity 0,
  m_PolyPoints = std::vector of length 0, capacity 0}

Anybody any ideas as to where the core of this problem is or even better
an Aha moment as to where and how to fix this?

Thanks,

Marco


___
Mailing list: 

Re: [Kicad-developers] Eeschema ERC should detect unmatched local labels

[Lorenzo Marcantonio]

On Sat, Sep 12, 2015 at 10:49:59PM -0600, Joseph Chen wrote:

> Though you don't approve the change now, I hope you would approve it
> sometime later soon, like maybe RC2. I am saying this because I
> believe the fix is crucial for KiCAD to be improved towards a
> production quality EDA, after I encountered my PCB's near "DEATH"
> situation.

I don't think that checking unmatched names is so critical. In fact
*most* of my labels are simply used to... label nets, not to create a
connection. That way during routing I can see the signal which need
particular attention (also it's easier to set netclasses in this way)

A distraction like a mistyped label is akin to connecting a wire to the
wrong pin (one time I flipped over an amp symbol... lot's of smoke
happened :D); no ERC can save you from that.

The *only* feature useful in the schematic DRC is the 'unconnected pin'
warning; all the other ones (signal conflicts, power pins and so on) are
a complete nuisance (at least for mixed signal and analog-heavy boards).
Even for digital boards a filter inductor on a power pin would give a
missing power warning :P

-- 
Lorenzo Marcantonio
Logos Srl

___
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] Problem of kicad-source and kicad-doc Packaging Help Documents

[Joseph Chen]

Is this a known issue or just me?

With running KiCAD on my linux, I have long noticed that the "help 
documents" are not accessible by the running "KiCAD".  I recently found 
a work-around to make them work for me.  The work-around is to create 
some symbolic links as shown here (if your email reader cannot display 
the long lines, look at the attached the text file that contains these 
links):


./usr/local/share/doc/kicad/help/en/pcbnew.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/Pcbnew/pdf/Pcbnew.pdf
./usr/local/share/doc/kicad/help/en/cvpcb.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/CvPcb/pdf/CvPcb.pdf
./usr/local/share/doc/kicad/help/en/eeschema.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/Eeschema/pdf/Eeschema.pdf
./usr/local/share/doc/kicad/help/en/gerbview.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/GerbView/pdf/GerbView.pdf
./usr/local/share/doc/kicad/help/en/Getting_Started_in_KiCad.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/Getting_Started_in_KiCad/pdf/Getting_Started_in_KiCad.pdf
./usr/local/share/doc/kicad/help/en/kicad.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/KiCad/pdf/KiCad.pdf


As you can see from the lines,  the symbolic links circumvent the root 
causes of the problem.  The root causes seem to be resulted in with 
mis-assumptions between the codes of "kicad-source" and "kicad-doc".  
Here is the list of some mis-assumptions:


1. The "kicad-doc" assumes that the installation destination directory is
 ${CMAKE_INSTALL_PREFIX}/en/

 while "kicad-source" code assumes that the documents installed by 
"kicad-doc" is located in

${CMAKE_INSTALL_PREFIX}/share/doc/kicad/help/en/

2. The "kicad-doc" assumes extra directory layers like "/pdf", "/html", 
ect., while "kicad-source" does not.


3. The "kicad-doc" uses mixed letter cases for file names, while 
"kicad-source" uses mostly lower cases.  While this mixed-case file 
names may not be a problem for Windows OS, it is definitely a real 
problem for Linux, and for OS-X of users who installed OS-X with 
case-sensitive file-system, myself included.


I don't have a good idea how to fix these, but hope someones there from 
the two camps of  "kicad-source" and "kicad-doc" have better ideas.  
Thus I won't need my work-around anymore.


--Joe
./usr/local/share/doc/kicad/help/en/pcbnew.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/Pcbnew/pdf/Pcbnew.pdf
./usr/local/share/doc/kicad/help/en/cvpcb.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/CvPcb/pdf/CvPcb.pdf
./usr/local/share/doc/kicad/help/en/eeschema.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/Eeschema/pdf/Eeschema.pdf
./usr/local/share/doc/kicad/help/en/gerbview.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/GerbView/pdf/GerbView.pdf
./usr/local/share/doc/kicad/help/en/Getting_Started_in_KiCad.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/Getting_Started_in_KiCad/pdf/Getting_Started_in_KiCad.pdf
./usr/local/share/doc/kicad/help/en/kicad.pdf -> 
/home/jchen/kicad-local-installed/usr/local/share/doc/kicad/help/en/KiCad/pdf/KiCad.pdf
___
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] Eeschema ERC should detect unmatched local labels

[Joseph Chen]

@Wayne,

Thank you for pointing to the current stable release policy and I
respect you decision.

Though you don't approve the change now, I hope you would approve it
sometime later soon, like maybe RC2.  I am saying this because I believe
the fix is crucial for KiCAD to be improved towards a production quality
EDA, after I encountered my PCB's near "DEATH" situation.

Here is my story. Using recent KiCAD, I finished a PCB layout for my own
design, and finished  the gerber files that were to be submitted a PCB
house. While viewing the generated gerber files, I spotted a pad of one
the parts were not connected at all, which is an error. Being alarmed, I
was tracing the root cause of the error.  It turns out the error was
caused by an unmatched label in my schematic.  How could the unmatched
label have happened?  It because I mistakenly mis-spelled the label name
in the supposed second label.  The mis-spelled label did not make into
the ratnets in my PCB layout.  And thus the pad did not connect to
anything at all.  If this set of error'ed gerber files was used in
actual production, all the manufactured PCBs would have been "DEAD"
boards when they came back to me.  It would have been a catastrophe if I
just simply sent out the generated gerber files to the PCB house.  I was
lucky I spotted the error.  My PCB was relatively simple and had only 2
layers.  Without the ERC's detecting unmatched labels, I can't imagine
how we could visually inspect the gerber files of more layers to avoid
this catastrophic errors.

Hope you guys there understand that the consequences of the simple
mis-spelled or unmatched label errors are not reversible after the PCB
production, and fixing it with ERC's detecting unmatched labels is crucial.


--Joe

On 09/11/2015 03:17 PM, Wayne Stambaugh wrote:

The current stable release policy can be found here:

http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.html

I have no intention of changing it for the upcoming stable release.
This policy is based on the limited amount of manpower which I don't see
changing any time soon.  Things are improving but we still have a long
way to go until I'm willing to commit resources to a more comprehensive
release schedule.

On 9/11/2015 5:00 PM, timofonic timofonic wrote:

I have a naive idea...

What about release the stable branch when all bugs and other issues
(performance?) get resolved and then keep these changes to another
release with smaller but useful changes?

I believe this can give many advantages:

- Finally a STABLE version gets released after many years. Please avoid
excessive delays, even if that means a bugfix release. Better soon with
some to polish later than delay it and waste the newly gained interest
in KiCad.

- Minor versions could be nice gifts and keep attention span from users,
developers and media.

On Sep 11, 2015 8:02 PM, "Wayne Stambaugh" > wrote:

 Joseph,

 I've already made the call for no new features.  If I allow this change
 then that opens the flood gates for everyone else to ask for an
 exception.  We are so far behind were I would like to be on the stable
 release that I do not want to jeopardize things any longer.  Please keep
 this in a separate branch so it's ready to be merged into the product
 branch as soon as the stable release is complete.  I appreciate you
 understanding regarding this decision.  Also, please keep in mind that
 we make every effort to keep the product branch as stable as possible so
 that developers and users are willing to keep testing it.

 Cheers,

 Wayne

 On 9/11/2015 3:58 AM, Joseph Chen wrote:
 > @JP and @Wayne,
 >
 > Would you take a patch for fixing this ERC's not detecting local
 labels?
 > I know we were reminded not to, but I believe this fix should be
 in the
 > stable release.  See my explanation below.
 >
 > On 09/01/2015 12:09 AM, jp charras wrote:
 >> Le 01/09/2015 04:59, Joseph Chen a écrit :
 >>> On 08/31/2015 05:10 AM, jp charras wrote:
  Le 28/08/2015 04:54, Joseph Chen a écrit :
 > This is a resubmitting of a patch file (attached)  that fixes the
 > issue
 > of [Bug 1487945].  This time it it more coding style compliant as
 > suggested in other developer's comments.
 >
 > The fix passed tests on Ubuntu 15.04, based off KiCAD BZR 6133
 >
 > --Joe
  Committed. Thanks.
 >>> Thank you JP!  I am now working on enabling ERC to catch errors of
 >>> unmatched LOCAL labels as well.
 >>>
 >>> --Joe
 >>>
 >> Unmatched LOCAL labels are a frequent case: they can just name a
 >> connection to help routing, create schematic documentation, or
 can just
 >> act as a comment in schematics+boards (I am widely use them).
 >>
 >> Unmatched LOCAL 

Re: [Kicad-developers] [PATCH] Fixed a False BZR Version Number Built From Local Branch of GIT-Source-Mirror

[Joseph Chen]

@Wayne & @Nick,

Attached you can find the new patch file that I've incorporated the
Nick's inputs.

Thanks,

--Joe


On 09/11/2015 08:27 AM, Wayne Stambaugh wrote:

Joseph,

Please make these changes and resubmit your patch and I will commit it.

Thanks,

Wayne

On 9/11/2015 10:19 AM, Nick Østergaard wrote:

Hi Joseph

Yes, I agree with you and understand the reasoning. I was just not
able to see the file patched and only reviewed the patch file itself.
I have now tried to apply it.

Some comments:

1. The line just before "# Get origin Repo HEAD" should probably be an
empth line to match the rest of the execute_process'.

2. We also create a long hash variable, although it is not used
anywhere else than for the cmake messaging, but we should probably me
explicit on which exact has that is. As is not that is a _LOCAL hash.
This to match the short hash.

If you adjust those two points, I think it is fine to merge it.

2015-09-11 10:16 GMT+02:00 Joseph Chen :

Hi Nick,

I very much like the true BZR version number that is produced by your script
when compiling from the git mirror source.  This is very helpful when
tracking the matching version of KiCAD from the bzr repo.

In the new way that I proposed for producing BZR version number, I pretty
much borrowed the tick that is being used by Linux kernel: when a cloned
local source tree is the same as the up stream's, the version string is like
"3.2.1" as the official release number. But,  after some changes, the
version string becomes "3.2.1-dirty-f6cd3", where "f6cd3" is the short hash
of the local head.  This means that the version is not official release any
more.

I hope this trivial patch can help in distinguish a true BZR version from
those with local modifications.

--Joe


On 09/10/2015 05:54 PM, Nick Østergaard wrote:

Hi

This is a matter of what we really want. When I wrote the logic at
first, my goal was just to make sure to generate a bzr version that
matches how the bzr cmake module did it, when building with an
unmodified tree. I think my version complies to that; that is not
taking care about weather or not you are on a local banch.

I have not tested this patch, but it looks alright to me. I am fine
with extending it with this detail, although one could argue that
holding the bzr rev as is, is not entirely correct, but if you get the
complete version string you can deduce that there are changes. For
example as you state the HEAD for the bzr number, you could also state
the HEAD and origin/HEAD for the bzr number, like, BZR 1234-1236 if
you have two commits in difference from the product branch.

I am ok with either, but some people might find it odd as is.

But I think the patch is not complete, the auxilarry variables should
probably be of the last local commit. That is the variables like
_git_LAST_COMITTER and _git_LONG_HASH. (Maybe they are ok, hard to see
properly in the patch only, I did not apply it.)

Nick

2015-09-10 17:15 GMT+02:00 Wayne Stambaugh :

@Nick, have you had a chance to look at this patch?  Since you wrote
this I thought you should have some input.  I'm not sure if this the
correct behavior when using git to generate the KiCad version string.
It seems as though Joseph is correct.  Would you please take a look at
it when you get a chance and let me know if it should be committed.

Thanks,

Wayne

On 8/30/2015 4:24 PM, Joseph Chen wrote:

Please review and apply the attached patch file of
CreateGitVersion.cmake.

*Issue to be fixed: a False BZR version number**
*
The details:
After cloning the repo of git-source-mirror, and working in my own local
branch, and committing a X times, the BZR version-number that is
generated by file CreateGitVersion.cmake is incremented by X number.
This is a mismatch of the true BZR number.

The tests:
_Before applying this patch_:

The command "Copy Version Info" built from the origin "master" branch
displays the following:
  Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product release
build
which is correct.

_However_, after creating a local branch based off the "master" branch,
and having committed 2 more times in the local branch, the command "Copy
Version Info" built from the local branch displays the following false
BZR number:
  Version: (2015-08-30 *BZR 6136, Git edfb32e*)-product release
build
which is _false_, because at the time the official BZR number is only
*6134*.


_After applying this_patch_:
The command "Copy Version Info" built from the "master" branch displays
the following:
   Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product release
build
which is still correct.

Now, the command "Copy Version Info" built from the local branch that
has 2 extra commits displayes the following:
  Version: (2015-08-30 *BZR 6134, Git 4e94d52-ede23f9*)-product
release build
which is still correct with a _true_ *BZR 6134*, plus it has an *added
GIT short hash* from the local branch HEAD.

This added GIT 

Re: [Kicad-developers] FW: Export to ODB++

[timofonic timofonic]

I see.

What about IPC-2581? Is really open? Do PCB manufacturers support it?

http://www.ipc-2581.com

If yes: Would be possible to have the KiCad logo here eventually?

http://www.ipc-2581.com/index.php/members-on-top
On Sep 12, 2015 5:00 PM, "Thiadmer Riemersma" 
wrote:

>
> What about clean room reverse engineering?
>>
> I'd advise against this. I have browsed through the ODB+ specification.
> Clean room reverse engineering is a massive undertaking. ODB+ may have its
> advantages, but I doubt it is worth the cost of reverse engineering.
>
>
> ___
> 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] FW: Export to ODB++

[Chris Pavlina]

Not GPL-compatible because the restriction would apply to anyone making a
derivative of KiCad as well. The only way I can see to do this is a
clean-room reverse engineering, which does not appear to be feasible.
On Sep 10, 2015 12:48 PM, "Mark Roszko"  wrote:

> Nope, you don't have to advertise for Mentor Graphics
>
> Here are the terms:
>
> 4. PROMOTION.
>
> Participant agrees to promote the integration between the ODB++ Format
> and the Participant Products by: (i) joining the ODB++ Solutions
> Alliance as a “solutions development partnering” member, via the ODB++
> Website, including providing a quote about Participant’s ODB++ Format
> implementation for use in Mentor Graphics’ promotional materials and
> on the ODB++ Website; (ii) allowing Mentor Graphics to use
> Participant’s logo in Mentor Graphics promotional materials and on the
> ODB++ Website; (iii) including a brief factual statement on the ODB++
> Format implementation in Participant’s promotional materials and a
> link from Participant’s website to the ODB++ Website; (iv) making a
> visible acknowledgement in the Participant’s Products (user-interface
> and documentation) of the support received from Mentor Graphics under
> this Agreement for the implementation of the ODB++ Format; and (v)
> agreeing to the publication by Mentor Graphics of the existence of
> Participant’s membership in the ODB++ Solutions Alliance.
>
>
>
>
> I highly doubt Altium and Cadence (both large EDA developers) would be
> supporting ODB++ if they have to advertise their competitor. Its just
> really slapping the logo on the supported products page for ODB++ and
> some marketing FUD for ODB++ because they really want it to take off
> for some reason.
> http://www.odb-sa.com/partners/
>
> ___
> 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] FW: Export to ODB++

[Tomasz Wlostowski]

On 12.09.2015 18:04, Chris Pavlina wrote:
> Not GPL-compatible because the restriction would apply to anyone making
> a derivative of KiCad as well. The only way I can see to do this is a
> clean-room reverse engineering, which does not appear to be feasible.

Use plugins. The ODB++/IPC-2581 ones could be kept outside mainline
Kicad if we would ensure they can be easily installed by a non-programmer.

- my 5 cents,
Tom



> 
> On Sep 10, 2015 12:48 PM, "Mark Roszko"  > wrote:
> 
> Nope, you don't have to advertise for Mentor Graphics
> 
> Here are the terms:
> 
> 4. PROMOTION.
> 
> Participant agrees to promote the integration between the ODB++ Format
> and the Participant Products by: (i) joining the ODB++ Solutions
> Alliance as a “solutions development partnering” member, via the ODB++
> Website, including providing a quote about Participant’s ODB++ Format
> implementation for use in Mentor Graphics’ promotional materials and
> on the ODB++ Website; (ii) allowing Mentor Graphics to use
> Participant’s logo in Mentor Graphics promotional materials and on the
> ODB++ Website; (iii) including a brief factual statement on the ODB++
> Format implementation in Participant’s promotional materials and a
> link from Participant’s website to the ODB++ Website; (iv) making a
> visible acknowledgement in the Participant’s Products (user-interface
> and documentation) of the support received from Mentor Graphics under
> this Agreement for the implementation of the ODB++ Format; and (v)
> agreeing to the publication by Mentor Graphics of the existence of
> Participant’s membership in the ODB++ Solutions Alliance.
> 
> 
> 
> 
> I highly doubt Altium and Cadence (both large EDA developers) would be
> supporting ODB++ if they have to advertise their competitor. Its just
> really slapping the logo on the supported products page for ODB++ and
> some marketing FUD for ODB++ because they really want it to take off
> for some reason.
> http://www.odb-sa.com/partners/
> 
> ___
> 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] FW: Export to ODB++

[Chris Pavlina]

Yes, while I still strongly dislike the idea of a FOSS project encouraging
that sort of licensing behavior, legally speaking that would work.

Personally I would rather Mentor get stuffed with that restriction, but
your 5 cents are worth more than my two. :D
On Sep 12, 2015 12:11 PM, "Tomasz Wlostowski" 
wrote:

> On 12.09.2015 18:04, Chris Pavlina wrote:
> > Not GPL-compatible because the restriction would apply to anyone making
> > a derivative of KiCad as well. The only way I can see to do this is a
> > clean-room reverse engineering, which does not appear to be feasible.
>
> Use plugins. The ODB++/IPC-2581 ones could be kept outside mainline
> Kicad if we would ensure they can be easily installed by a non-programmer.
>
> - my 5 cents,
> Tom
>
>
>
> >
> > On Sep 10, 2015 12:48 PM, "Mark Roszko"  > > wrote:
> >
> > Nope, you don't have to advertise for Mentor Graphics
> >
> > Here are the terms:
> >
> > 4. PROMOTION.
> >
> > Participant agrees to promote the integration between the ODB++
> Format
> > and the Participant Products by: (i) joining the ODB++ Solutions
> > Alliance as a “solutions development partnering” member, via the
> ODB++
> > Website, including providing a quote about Participant’s ODB++ Format
> > implementation for use in Mentor Graphics’ promotional materials and
> > on the ODB++ Website; (ii) allowing Mentor Graphics to use
> > Participant’s logo in Mentor Graphics promotional materials and on
> the
> > ODB++ Website; (iii) including a brief factual statement on the ODB++
> > Format implementation in Participant’s promotional materials and a
> > link from Participant’s website to the ODB++ Website; (iv) making a
> > visible acknowledgement in the Participant’s Products (user-interface
> > and documentation) of the support received from Mentor Graphics under
> > this Agreement for the implementation of the ODB++ Format; and (v)
> > agreeing to the publication by Mentor Graphics of the existence of
> > Participant’s membership in the ODB++ Solutions Alliance.
> >
> >
> >
> >
> > I highly doubt Altium and Cadence (both large EDA developers) would
> be
> > supporting ODB++ if they have to advertise their competitor. Its just
> > really slapping the logo on the supported products page for ODB++ and
> > some marketing FUD for ODB++ because they really want it to take off
> > for some reason.
> > http://www.odb-sa.com/partners/
> >
> > ___
> > 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] Reminder

[Nick Østergaard]

For your (and others) information, in the current moment of writing this
email, there are no more critical or high bugs on the tracker.

2015-09-08 21:34 GMT+02:00 Wayne Stambaugh :
> I think the current situation is as good as we can hope for as far as
> blockers for rc1. I'm going to try to create a new version 4 stable
> release series on Launchpad Friday if no new show stoppers crop up.
> Periodically I will merge any bug fixes from the product branch into the
> 4 stable series branch and increment the rc number. If we manage to go
> a few weeks with no new crash or data loss bugs, I will tag it a stable
> release.
>
> On 9/8/2015 3:02 PM, Nick Østergaard wrote:
>> Wayne, was it your intention to include the incomplete bugs in the
>> blockers for rc1? I mean, incomplete bugs are bugs that have a
>> potential to be revived, but where the developers are not really
>> supposed to spend more time on them until some feedback are given.
>>
>> I personally don't think they should be included in that list, even if
>> critical or high or not.
>>
>> 2015-09-06 22:11 GMT+02:00 Wayne Stambaugh :
>>> This is a reminder to *all* developers, please do not send any patches
>>> or merge requests unless it is specifically to fix an existing bug
>>> report. Also, please don't bother fixing the build scripts or any of
>>> the CMake dependency library build code as they will be removed during
>>> the next development cycle. My preference is that we focus on the
>>> critical bug reports that are keeping me from creating an rc1 branch.
>>> They can be found here:
>>>
>>>
https://bugs.launchpad.net/kicad/+bugs?field.searchtext==-importance=Search%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CRITICAL%3Alist=HIGH_option=any=_reporter=_commenter==_subscriber==_combinator=ANY_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on
>>>
>>> This list needs to get to zero before I'm willing to create any rc1
branch.
>>>
>>> Thank you for your cooperation.
>>>
>>> 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] FW: Export to ODB++

[Thiadmer Riemersma]

> What about clean room reverse engineering?
>
I'd advise against this. I have browsed through the ODB+ specification.
Clean room reverse engineering is a massive undertaking. ODB+ may have its
advantages, but I doubt it is worth the cost of reverse engineering.
___
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