Re: [Kicad-developers] 5.1.1 issue

[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, 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 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.1.1 libraries, documentation, and translations as
> nothing has change since 5.1.1 that would effect anything.  I figure
> this will give Adam some more time to get the macos release out.  I
> apologize in advance for dropping the ball on this.

My preference would be to tag all seven repositories with 5.1.2,
even if the 5.1.2 and 5.1.1 tags are on the same commit.  That
way, the intent is very clear in the history of each repo.

Changing / reusing a tag once it has been pushed is never a good
idea, IMO.

        Steve


___
Mailing list: https://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] 5.1.1 issue

[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.  I can setup a 5.1 branch as well--or is
5.0 done and should I just switch that over?

Adam


On Sun, Apr 21, 2019 at 5:51 PM Wayne Stambaugh  wrote:
>
> 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/15723/37
> > This would hopefully help avoiding bugfix enduced bugs making it to stable.
> > I can imagine alot of people (including myself) who wants to help
> > testing, but can't use nightlies due to the file fomat changes.
>
> I think this is a great idea.  This would give us more testing of the
> current stable release branch between releases.  It most likely would
> have prevented the current situation.
>
> Cheers,
>
> Wayne
>
> >
> >
> >
> > Den 21. april 2019 kl. 23.18.53 +02.00, skrev 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.1.1 libraries, documentation, and translations as
> >> nothing has change since 5.1.1 that would effect anything. I figure
> >> this will give Adam some more time to get the macos release out. I
> >> apologize in advance for dropping the ball on this.
> >>
> >> 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] 5.1.1 issue

[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/15723/37
> This would hopefully help avoiding bugfix enduced bugs making it to stable.
> I can imagine alot of people (including myself) who wants to help
> testing, but can't use nightlies due to the file fomat changes.

I think this is a great idea.  This would give us more testing of the
current stable release branch between releases.  It most likely would
have prevented the current situation.

Cheers,

Wayne

> 
> 
> 
> Den 21. april 2019 kl. 23.18.53 +02.00, skrev 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.1.1 libraries, documentation, and translations as
>> nothing has change since 5.1.1 that would effect anything. I figure
>> this will give Adam some more time to get the macos release out. I
>> apologize in advance for dropping the ball on this.
>>
>> 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] 5.1.1 issue

[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 it to stable.
I can imagine alot of people (including myself) who wants to help testing, but 
can't use nightlies due to the file fomat changes.



Den 21. april 2019 kl. 23.18.53 +02.00, skrev 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.1.1 libraries, documentation, and translations as
> nothing has change since 5.1.1 that would effect anything. I figure
> this will give Adam some more time to get the macos release out. I
> apologize in advance for dropping the ball on this.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: 
> Post to : 
> Unsubscribe : 
> More help : 
> 

___
Mailing list: https://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] 5.1.1 issue

[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 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.1.1 libraries, documentation, and translations as
> > nothing has change since 5.1.1 that would effect anything.  I figure
> > this will give Adam some more time to get the macos release out.  I
> > apologize in advance for dropping the ball on this.
>
> My preference would be to tag all seven repositories with 5.1.2, even if
> the 5.1.2 and 5.1.1 tags are on the same commit.  That way, the intent is
> very clear in the history of each repo.
>
> Changing / reusing a tag once it has been pushed is never a good idea, IMO.
>
> Steve
>
>
> ___
> Mailing list: https://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] 5.1.1 issue

[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 formally releasing 5.1.1?  I'm fine
> if we use the 5.1.1 libraries, documentation, and translations as
> nothing has change since 5.1.1 that would effect anything.  I figure
> this will give Adam some more time to get the macos release out.  I
> apologize in advance for dropping the ball on this.

My preference would be to tag all seven repositories with 5.1.2, even if the 
5.1.2 and 5.1.1 tags are on the same commit.  That way, the intent is very 
clear in the history of each repo.

Changing / reusing a tag once it has been pushed is never a good idea, IMO.

Steve


___
Mailing list: https://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] A neat decision-making scheme

[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  wrote:
> 
> 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
> 
> On 4/21/19 4:03 PM, John Beard wrote:
>> +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 count. Since KiCad is a
>> trans-continental team and core people can be busy in real life, slow
>> mail replies can happen.
>> 
>> And also the etiquette for a "delay until I can review properly" veto.
>> If we want people to be free to exercise that ability in good faith
>> without feeling shy about blocking while they check it out, it should be
>> called out as allowed and encouraged.
>> 
>> Cheers,
>> 
>> John
>> 
>> On 21 April 2019 20:34:23 BST, Tomasz Wlostowski
>>  wrote:
>> 
>>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
>>source):
>> 
>>If you need direction on something, you send an email to the
>>list. (This part is no different than what we do today.)
>> 
>>If someone agrees, they reply with “+1”.
>> 
>>If someone wants to halt progress until either some discussion
>>is had or until another direction is chosen they veto with a “-1”.
>> 
>>When you accumulate three +1s and are clear of -1s you’re good
>>to go.
>> 
>>If you do get one or more -1s you’re blocked until those folks
>>change their input to either a “+0” or a “+1”.
>> 
>>If you haven’t yet reached three +1s after a time-out period (I
>>think we used a week but it might have been two), but you are
>>clear of -1s, you can send a message to the list indicating a
>>default-consensus and go ahead and implement it.
>> 
>>Might this be useful for us?
>> 
>>+1.
>> 
>>T.
>> 
>>
>> 
>>Mailing list: https://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

[Kicad-developers] 5.1.1 issue

[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.1.1 libraries, documentation, and translations as
nothing has change since 5.1.1 that would effect anything.  I figure
this will give Adam some more time to get the macos release out.  I
apologize in advance for dropping the ball on this.

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] A neat decision-making scheme

[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

On 4/21/19 4:03 PM, John Beard wrote:
> +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 count. Since KiCad is a
> trans-continental team and core people can be busy in real life, slow
> mail replies can happen.
> 
> And also the etiquette for a "delay until I can review properly" veto.
> If we want people to be free to exercise that ability in good faith
> without feeling shy about blocking while they check it out, it should be
> called out as allowed and encouraged.
> 
> Cheers,
> 
> John
> 
> On 21 April 2019 20:34:23 BST, Tomasz Wlostowski
>  wrote:
> 
> 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
> source):
> 
> If you need direction on something, you send an email to the
> list. (This part is no different than what we do today.)
> 
> If someone agrees, they reply with “+1”.
> 
> If someone wants to halt progress until either some discussion
> is had or until another direction is chosen they veto with a “-1”.
> 
> When you accumulate three +1s and are clear of -1s you’re good
> to go.
> 
> If you do get one or more -1s you’re blocked until those folks
> change their input to either a “+0” or a “+1”.
> 
> If you haven’t yet reached three +1s after a time-out period (I
> think we used a week but it might have been two), but you are
> clear of -1s, you can send a message to the list indicating a
> default-consensus and go ahead and implement it.
> 
> Might this be useful for us?
> 
> +1.
> 
> T.
> 
> 
> 
> Mailing list: https://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] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

[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/KiCad/kicad-symbols/issues/756 and is decided to be
pushed to v6.

-h

___
Mailing list: https://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] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

[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 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 good as it does not reflect the reality of many different power
> rails in modern circuits.
>
> In other multi-gate symbols I've noticed there is these days on extra
> 'unit' that essentially contains the power pins; is this the
> recommended way these days ? And if so, is someone working on this, or
> should I prepare a pull request for 74LVC2G14 ?
>
> Is there a mailing list specifically for library discussions, or is
> this the right place ?
>
> Thanks,
>   Henner.
>
> ___
> Mailing list: https://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] A neat decision-making scheme

[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 people gave a +1 it would pretty unlikely for someone else to 
veto.  

And of course someone could always come along later and say “oh shit, wait a 
minute…” (in fact it might even be someone who had previously given a +1).  The 
scheme is just meant to speed up the normal course of things.

Cheers,
Jeff.


> On 21 Apr 2019, at 21:03, John Beard  wrote:
> 
> +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 count. Since KiCad is a trans-continental team 
> and core people can be busy in real life, slow mail replies can happen.
> 
> And also the etiquette for a "delay until I can review properly" veto. If we 
> want people to be free to exercise that ability in good faith without feeling 
> shy about blocking while they check it out, it should be called out as 
> allowed and encouraged.
> 
> Cheers,
> 
> John
> 
> On 21 April 2019 20:34:23 BST, Tomasz Wlostowski  
> wrote:
> 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 source):
> 
> If you need direction on something, you send an email to the list.  (This 
> part is no different than what we do today.)
> 
> If someone agrees, they reply with “+1”.
> 
> If someone wants to halt progress until either some discussion is had or 
> until another direction is chosen they veto with a “-1”.
> 
> When you accumulate three +1s and are clear of -1s you’re good to go.
> 
> If you do get one or more -1s you’re blocked until those folks change their 
> input to either a “+0” or a “+1”.
> 
> If you haven’t yet reached three +1s after a time-out period (I think we used 
> a week but it might have been two), but you are clear of -1s, you can send a 
> message to the list indicating a default-consensus and go ahead and implement 
> it.
> 
> Might this be useful for us?
> +1.
> 
> T.
> 
> Mailing list: https://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] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

[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 good as it does not reflect the reality of many different power
rails in modern circuits.

In other multi-gate symbols I've noticed there is these days on extra
'unit' that essentially contains the power pins; is this the
recommended way these days ? And if so, is someone working on this, or
should I prepare a pull request for 74LVC2G14 ?

Is there a mailing list specifically for library discussions, or is
this the right place ?

Thanks,
  Henner.

___
Mailing list: https://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] A neat decision-making scheme

[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 count. Since KiCad is a trans-continental team and core 
people can be busy in real life, slow mail replies can happen.

And also the etiquette for a "delay until I can review properly" veto. If we 
want people to be free to exercise that ability in good faith without feeling 
shy about blocking while they check it out, it should be called out as allowed 
and encouraged.

Cheers,

John

On 21 April 2019 20:34:23 BST, Tomasz Wlostowski  
wrote:
>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 source):
>> 
>> If you need direction on something, you send an email to the list. 
>(This part is no different than what we do today.)
>> 
>> If someone agrees, they reply with “+1”.
>> 
>> If someone wants to halt progress until either some discussion is had
>or until another direction is chosen they veto with a “-1”.
>> 
>> When you accumulate three +1s and are clear of -1s you’re good to go.
>> 
>> If you do get one or more -1s you’re blocked until those folks change
>their input to either a “+0” or a “+1”.
>> 
>> If you haven’t yet reached three +1s after a time-out period (I think
>we used a week but it might have been two), but you are clear of -1s,
>you can send a message to the list indicating a default-consensus and
>go ahead and implement it.
>> 
>> Might this be useful for us?
>+1.
>
>T.
>
>> ___
>> Mailing list: https://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] A neat decision-making scheme

[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 source):
> 
> If you need direction on something, you send an email to the list.  (This 
> part is no different than what we do today.)
> 
> If someone agrees, they reply with “+1”.
> 
> If someone wants to halt progress until either some discussion is had or 
> until another direction is chosen they veto with a “-1”.
> 
> When you accumulate three +1s and are clear of -1s you’re good to go.
> 
> If you do get one or more -1s you’re blocked until those folks change their 
> input to either a “+0” or a “+1”.
> 
> If you haven’t yet reached three +1s after a time-out period (I think we used 
> a week but it might have been two), but you are clear of -1s, you can send a 
> message to the list indicating a default-consensus and go ahead and implement 
> it.
> 
> Might this be useful for us?
+1.

T.

> ___
> Mailing list: https://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] kicad_pcb, kicad_mod format change for daily build?

[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 just fine?
> 
> Nick
> 
> On Sun, 21 Apr 2019 at 18:46, Jeff Young  > wrote:
> 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 this day and age (and going forward it will make things 
> easier).
> 
> Cheers,
> Jeff.
> 
> 
> > On 21 Apr 2019, at 17:25, Kevin Cozens  > > wrote:
> > 
> >> 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" signal)
> > 
> > When I was asking about an updated file format document I was told "There 
> > have been virtually no changes to the file format other than how symbol 
> > library links are defined for a very long time."
> > 
> > I consider it a file format change if quotes weren't needed before but they 
> > are now. It is the type of information I need to be sure I'm generating 
> > files in the proper format to avoid possibly having to go through the 
> > migration process.
> > 
> > There may be other change(s) I may need to know about because the version 
> > number in the files has been bumped since the current file format doc was 
> > written. The files I'm generating are a version behind and have to go 
> > through a migration process when I try and open them. I don't fully trust 
> > the migration process.
> > 
> > I hope someone can update the docs after KiCon, or perhaps someone can 
> > point me to which file(s) generate the schematic files used by eeschema.
> > 
> > -- 
> > Cheers!
> > 
> > Kevin.
> > 
> > http://www.ve3syb.ca/    | "Nerds make 
> > the shiny things that
> > https://www.patreon.com/KevinCozens  | 
> > distract the mouth-breathers, and
> >| that's why we're powerful"
> > Owner of Elecraft K2 #2172  |
> > #include  | --Chris Hardwick
> > 
> > ___
> > Mailing list: https://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] kicad_pcb, kicad_mod format change for daily build?

[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 (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 this day and age (and going forward it will
> make things easier).
>
> Cheers,
> Jeff.
>
>
> > On 21 Apr 2019, at 17:25, Kevin Cozens  wrote:
> >
> >> 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" signal)
> >
> > When I was asking about an updated file format document I was told
> "There have been virtually no changes to the file format other than how
> symbol library links are defined for a very long time."
> >
> > I consider it a file format change if quotes weren't needed before but
> they are now. It is the type of information I need to be sure I'm
> generating files in the proper format to avoid possibly having to go
> through the migration process.
> >
> > There may be other change(s) I may need to know about because the
> version number in the files has been bumped since the current file format
> doc was written. The files I'm generating are a version behind and have to
> go through a migration process when I try and open them. I don't fully
> trust the migration process.
> >
> > I hope someone can update the docs after KiCon, or perhaps someone can
> point me to which file(s) generate the schematic files used by eeschema.
> >
> > --
> > Cheers!
> >
> > Kevin.
> >
> > http://www.ve3syb.ca/   | "Nerds make the shiny things that
> > https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
> >| that's why we're powerful"
> > Owner of Elecraft K2 #2172  |
> > #include  | --Chris Hardwick
> >
> > ___
> > Mailing list: https://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] kicad_pcb, kicad_mod format change for daily build?

[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 this day and age (and going forward it will make things 
easier).

Cheers,
Jeff.


> On 21 Apr 2019, at 17:25, Kevin Cozens  wrote:
> 
>> 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" signal)
> 
> When I was asking about an updated file format document I was told "There 
> have been virtually no changes to the file format other than how symbol 
> library links are defined for a very long time."
> 
> I consider it a file format change if quotes weren't needed before but they 
> are now. It is the type of information I need to be sure I'm generating files 
> in the proper format to avoid possibly having to go through the migration 
> process.
> 
> There may be other change(s) I may need to know about because the version 
> number in the files has been bumped since the current file format doc was 
> written. The files I'm generating are a version behind and have to go through 
> a migration process when I try and open them. I don't fully trust the 
> migration process.
> 
> I hope someone can update the docs after KiCon, or perhaps someone can point 
> me to which file(s) generate the schematic files used by eeschema.
> 
> -- 
> Cheers!
> 
> Kevin.
> 
> http://www.ve3syb.ca/   | "Nerds make the shiny things that
> https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
>| that's why we're powerful"
> Owner of Elecraft K2 #2172  |
> #include  | --Chris Hardwick
> 
> ___
> Mailing list: https://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] A neat decision-making scheme

[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’m unaware of its source):
>
> If you need direction on something, you send an email to the list.  (This
> part is no different than what we do today.)
>
> If someone agrees, they reply with “+1”.
>
> If someone wants to halt progress until either some discussion is had or
> until another direction is chosen they veto with a “-1”.
>
> When you accumulate three +1s and are clear of -1s you’re good to go.
>
> If you do get one or more -1s you’re blocked until those folks change
> their input to either a “+0” or a “+1”.
>
> If you haven’t yet reached three +1s after a time-out period (I think we
> used a week but it might have been two), but you are clear of -1s, you can
> send a message to the list indicating a default-consensus and go ahead and
> implement it.
>
> Might this be useful for us?
> ___
> Mailing list: https://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] kicad_pcb, kicad_mod format change for daily build?

[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" signal)


When I was asking about an updated file format document I was told "There 
have been virtually no changes to the file format other than how symbol 
library links are defined for a very long time."


I consider it a file format change if quotes weren't needed before but they 
are now. It is the type of information I need to be sure I'm generating 
files in the proper format to avoid possibly having to go through the 
migration process.


There may be other change(s) I may need to know about because the version 
number in the files has been bumped since the current file format doc was 
written. The files I'm generating are a version behind and have to go 
through a migration process when I try and open them. I don't fully trust 
the migration process.


I hope someone can update the docs after KiCon, or perhaps someone can point 
me to which file(s) generate the schematic files used by eeschema.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
Mailing list: https://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] A neat decision-making scheme

[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, you send an email to the list.  (This part 
is no different than what we do today.)

If someone agrees, they reply with “+1”.

If someone wants to halt progress until either some discussion is had or until 
another direction is chosen they veto with a “-1”.

When you accumulate three +1s and are clear of -1s you’re good to go.

If you do get one or more -1s you’re blocked until those folks change their 
input to either a “+0” or a “+1”.

If you haven’t yet reached three +1s after a time-out period (I think we used a 
week but it might have been two), but you are clear of -1s, you can send a 
message to the list indicating a default-consensus and go ahead and implement 
it.

Might this be useful for us?
___
Mailing list: https://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] There seems to be an serious issue with netlist handling in KiCad 5.1.1

[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 experienced this as well
> Isn't it this issue?
> https://bugs.launchpad.net/kicad/+bug/1824764
>
> Kindest 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 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 a regression already
> present in 5.1. Basically, it causes some nets to be not connected, which
> results in missing ratsnets in pcbnew as well as ERC errors (not-connected
> pads). Visually, all pins are shown as correctly connected in eeschema. In
> pcbnew those pads are not connected at all (so no ratsnets bug).
>
> Dunno if this fix works for all people, but closing eeschema and opening
> it again causes a corrupted file warning (I think warning about an invalid
> netlist), which causes KiCad to create the netlist again and building a
> valid one which resolves the issue.
>
> As summary: it seems there is a serious bug in KiCad 5.1.x which causes
> netlist errors and file corruptions.
>
> I told everyone which had this problem to create a bug-report on launchpad
> to give some additional informations. If the issue is not found until
> KiCon, I would suggest to have one of the main-developers attend the
> beginner workshop to look for anyone having this issue and reproduce it.
>
> Regards, Thomas
>
>
> ___
> Mailing list: https://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] There seems to be an serious issue with netlist handling in KiCad 5.1.1

[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 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 a regression already present in 5.1. Basically, it causes some nets to be not connected, which results in missing ratsnets in pcbnew as well as ERC errors (not-connected pads). Visually, all pins are shown as correctly connected in eeschema. In pcbnew those pads are not connected at all (so no ratsnets bug).

 

Dunno if this fix works for all people, but closing eeschema and opening it again causes a corrupted file warning (I think warning about an invalid netlist), which causes KiCad to create the netlist again and building a valid one which resolves the issue.

 

As summary: it seems there is a serious bug in KiCad 5.1.x which causes netlist errors and file corruptions.

 

I told everyone which had this problem to create a bug-report on launchpad to give some additional informations. If the issue is not found until KiCon, I would suggest to have one of the main-developers attend the beginner workshop to look for anyone having this issue and reproduce it.

 

Regards, Thomas

___
Mailing list: https://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] There seems to be an serious issue with netlist handling in KiCad 5.1.1

[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 a regression already present in 5.1. Basically, it causes some nets to be not connected, which results in missing ratsnets in pcbnew as well as ERC errors (not-connected pads). Visually, all pins are shown as correctly connected in eeschema. In pcbnew those pads are not connected at all (so no ratsnets bug).

 

Dunno if this fix works for all people, but closing eeschema and opening it again causes a corrupted file warning (I think warning about an invalid netlist), which causes KiCad to create the netlist again and building a valid one which resolves the issue.

 

As summary: it seems there is a serious bug in KiCad 5.1.x which causes netlist errors and file corruptions.

 

I told everyone which had this problem to create a bug-report on launchpad to give some additional informations. If the issue is not found until KiCon, I would suggest to have one of the main-developers attend the beginner workshop to look for anyone having this issue and reproduce it.

 

Regards, Thomas

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