Re: [Kicad-developers] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

2019-04-21 Thread Rene Pöschl
On 21/04/19 22:58, Henner Zeller wrote: On Sun, 21 Apr 2019 at 13:28, Nick Østergaard wrote: Hello Henner, I think the Librarians more or less communicate exclusively via github issues. So it may be worth to post this as an issue on the kicad-symbols repo over on github. Thanks Nick; looks

Re: [Kicad-developers] 5.1.1 issue

2019-04-21 Thread Rene Pöschl
Is this the official decision because i can tag the libraries with 5.1.2 at any time. (On the same commit as 5.1.1.) On 22/04/19 00:03, Nick Østergaard wrote: Yes, just retag the 5.1.1 tags as 5.1.2 as well. We have done that before and is probably what will have the least workload. :) On Sun

Re: [Kicad-developers] 5.1.1 issue

2019-04-21 Thread Adam Wolf
Hi folks! I was able to pin Boost to the previous homebrew build and things seem to build for macOS again. I generated 5.1.1 packages, and I can even upload them, but it will be mere single-digit minutes of extra effort to spin a 5.1.2 once things are tagged again. I have a 5.0 branch nightly.

Re: [Kicad-developers] 5.1.1 issue

2019-04-21 Thread Wayne Stambaugh
Hey Frank, On 4/21/19 6:33 PM, Frank Severinsen wrote: > a non-dev-lead +1 ;) LOL! > > As a small side note there is a discussion on the forum to get a V5.1 > branch "nightly" going. > https://forum.kicad.info/t/does-it-make-sense-to-have-development-snapshots-for-the-v5-1-branch-going-forward/

Re: [Kicad-developers] 5.1.1 issue

2019-04-21 Thread Frank Severinsen
a non-dev-lead +1 ;) As a small side note there is a discussion on the forum to get a V5.1 branch "nightly" going. This would hopefully help avoiding bugfix enduced bugs making

Re: [Kicad-developers] 5.1.1 issue

2019-04-21 Thread Nick Østergaard
Yes, just retag the 5.1.1 tags as 5.1.2 as well. We have done that before and is probably what will have the least workload. :) On Sun, 21 Apr 2019 at 23:44, Steven A. Falco wrote: > On 4/21/19 5:18 PM, Wayne Stambaugh wrote: > > It's looks like 5.1.1 has a serious issue which was fixed and will

Re: [Kicad-developers] 5.1.1 issue

2019-04-21 Thread Steven A. Falco
On 4/21/19 5:18 PM, Wayne Stambaugh wrote: > It's looks like 5.1.1 has a serious issue which was fixed and will be > released in 5.1.2. Since folks have already started downloading 5.1.1, > I don't think changing the 5.1.1 tag is a good idea. How much trouble > would it be to spin 5.1.2 and skip

Re: [Kicad-developers] A neat decision-making scheme

2019-04-21 Thread Jeff Young
I’d suggest amending that slightly to “requires three lead-dev +1s, and no lead-dev -1s”. We should encourage others to participate, even if their votes are “non-binding”. And yes, even at Day management still had the last say. ;) Cheers, Jeff. > On 21 Apr 2019, at 22:12, Wayne Stambaugh wr

[Kicad-developers] 5.1.1 issue

2019-04-21 Thread Wayne Stambaugh
It's looks like 5.1.1 has a serious issue which was fixed and will be released in 5.1.2. Since folks have already started downloading 5.1.1, I don't think changing the 5.1.1 tag is a good idea. How much trouble would it be to spin 5.1.2 and skip formally releasing 5.1.1? I'm fine if we use the 5

Re: [Kicad-developers] A neat decision-making scheme

2019-04-21 Thread Wayne Stambaugh
As long as the only members of the lead development team have voting rights and the project leader has veto power than I am fine with this. I haven't had to use veto power yet but I am not naive enough to believe that there are no circumstances which I wouldn't veto a majority vote. Cheers, Wayne

Re: [Kicad-developers] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

2019-04-21 Thread Henner Zeller
On Sun, 21 Apr 2019 at 13:28, Nick Østergaard wrote: > > Hello Henner, > > I think the Librarians more or less communicate exclusively via github > issues. So it may be worth to post this as an issue on the kicad-symbols repo > over on github. Thanks Nick; looks like this is https://github.com/

Re: [Kicad-developers] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

2019-04-21 Thread Nick Østergaard
Hello Henner, I think the Librarians more or less communicate exclusively via github issues. So it may be worth to post this as an issue on the kicad-symbols repo over on github. Regards Nick On Sun, 21 Apr 2019 at 22:12, Henner Zeller wrote: > Hi, > While converting some older project to curr

Re: [Kicad-developers] A neat decision-making scheme

2019-04-21 Thread Jeff Young
Good questions, John. At Day, the use of a veto was a rare occurrence. So it wasn’t used for “give me a minute”. Which is not to say that their usage was right or wrong, but it did work for them. Generally speaking you’d only give a +1 if you had thought it through. So in practice if three

[Kicad-developers] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

2019-04-21 Thread Henner Zeller
Hi, While converting some older project to current libraries, I noticed that the 74LVC2G14 (a dual Schmitt-Trigger inverter) comes with hidden power pins. I have not followed the discussions w.r.t. hidden power pins, but it seems like they are generally discouraged these days (KLC S4.6), which is

Re: [Kicad-developers] A neat decision-making scheme

2019-04-21 Thread John Beard
+1 Reminds me of the scoring we used to do code review on Gerrit, with a different threshold. That worked well. Is there a minimum time to wait for a -1? If a reviewer didn't see the mail before three +1s, their veto is too late. But if they were checking their mail earlier, the veto would co

Re: [Kicad-developers] A neat decision-making scheme

2019-04-21 Thread Tomasz Wlostowski
On 21/04/2019 18:08, Jeff Young wrote: > In my last few years at Adobe I worked with Day Software in Switzerland which > we had just acquired. They did a lot of open-source stuff with Apache and > had this neat decision-making scheme (which may have originated at Apache — > I’m unaware of its s

Re: [Kicad-developers] kicad_pcb, kicad_mod format change for daily build?

2019-04-21 Thread Jeff Young
The latter (earlier versions will read it just fine). > On 21 Apr 2019, at 19:00, Nick Østergaard wrote: > > Hi > > I am just curious about this topic. Is this a case where we should have > bumped the SEXPR_BOARD_FILE_VERSION? Or is this not needed as an earlier > kicad version would read it

Re: [Kicad-developers] kicad_pcb, kicad_mod format change for daily build?

2019-04-21 Thread Nick Østergaard
Hi I am just curious about this topic. Is this a case where we should have bumped the SEXPR_BOARD_FILE_VERSION? Or is this not needed as an earlier kicad version would read it just fine? Nick On Sun, 21 Apr 2019 at 18:46, Jeff Young wrote: > Hi Kevin, > > KiCad will read them in either way (qu

Re: [Kicad-developers] kicad_pcb, kicad_mod format change for daily build?

2019-04-21 Thread Jeff Young
Hi Kevin, KiCad will read them in either way (quoted or un-quoted). KiCad has always written them out with quotes if they had spaces in them (so other tools have always needed to handle quotes). We’re just being more consistent now as there’s no justification for “saving a few characters” in t

Re: [Kicad-developers] A neat decision-making scheme

2019-04-21 Thread Jon Evans
+1 :-) On Sun, Apr 21, 2019 at 12:08 PM Jeff Young wrote: > In my last few years at Adobe I worked with Day Software in Switzerland > which we had just acquired. They did a lot of open-source stuff with > Apache and had this neat decision-making scheme (which may have originated > at Apache — I

Re: [Kicad-developers] kicad_pcb, kicad_mod format change for daily build?

2019-04-21 Thread Kevin Cozens
On 15 Apr 2019, at 13:56, easyw wrote: recently I have noticed that both kicad_pcb and kicad_mod seems to have changed their format. It have been introduced double quotes for layers pads etc. [snip] (layers (0 F.Cu signal) (31 B.Cu signal) (layers (0 "F.Cu" signal) (31 "B.Cu"

[Kicad-developers] A neat decision-making scheme

2019-04-21 Thread Jeff Young
In my last few years at Adobe I worked with Day Software in Switzerland which we had just acquired. They did a lot of open-source stuff with Apache and had this neat decision-making scheme (which may have originated at Apache — I’m unaware of its source): If you need direction on something, yo

Re: [Kicad-developers] There seems to be an serious issue with netlist handling in KiCad 5.1.1

2019-04-21 Thread Jon Evans
Is anyone experiencing this able to compile 5.1 branch from source (so, the code that will eventually become 5.1.2) and check if this issue is already fixed by Seth's commit? -Jon On Sun, Apr 21, 2019 at 9:10 AM Frank Severinsen < fr...@danishaviationsystems.dk> wrote: > Hi Thomas > > I have exp

Re: [Kicad-developers] There seems to be an serious issue with netlist handling in KiCad 5.1.1

2019-04-21 Thread Frank Severinsen
Hi ThomasI have experienced this as wellIsn't it this issue?https://bugs.launchpad.net/kicad/+bug/1824764Kindest regards Frank Severinsen 21. apr. 2019 11.08 skrev Thomas Pointhuber :Hi,   I made a KiCad beginner workshop yesterday (with about 45 people), and at least two of the participants appa

[Kicad-developers] There seems to be an serious issue with netlist handling in KiCad 5.1.1

2019-04-21 Thread Thomas Pointhuber
Hi,   I made a KiCad beginner workshop yesterday (with about 45 people), and at least two of the participants appared to run into serious issues regarding netlist handling. One of my colleguages as well (I hope he creates an bug-report soon).   The Issue appeared on KiCad 5.1.1, but it could be