← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema ERC should detect unmatched local labels

 

Ugh, I sent this from the wrong email so it didn't show up on the list.

Fixed.

Adam Wolf
On Sep 11, 2015 4:06 PM, "Adam Wolf" <adamwwolf@xxxxxxxxx> wrote:

> Timofonic,
>
> You can download a build from the last week for almost every platform that
> can run KiCad.
>
> I asked you this last week--what do you think you will get if we slap the
> word stable on that build that you don't get without that name?
>
> The stable release gets no magical powers from its name.  It gets any sort
> of viability by hard work by dedicated developers, packagers, and testers.
>
> Wayne outlined this release procedure months ago, and we are following it.
>
> A stable release that is released due to changing the goal posts is no
> stable release at all.
>
> If there are bajillions of users using ancient KiCad from 10 years ago,
> why can't they upgrade to a recent build and moreover, why can they not
> upgrade to a recent build but cab if someone renamed the file to say
> "stable"?
>
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne
> On Sep 11, 2015 4:00 PM, "timofonic timofonic" <timofonic@xxxxxxxxx>
> 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" <stambaughw@xxxxxxxxx> 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 labels are in many cases not an error.
>>> >> Detecting them can be useful, but this detection have to be
>>> >> enabled/disabled on option.
>>> > In my local working branch, I was able to make this ERC's detecting
>>> > unmatched local labels work as suggested by JP:
>>> > Within the ERC pop-up dialog window, there is an added extra check box
>>> > for detecting unmatched local labels.  By default, the check box is
>>> > "un-checked". When a user clicks to enable it, the ERC is able to
>>> report
>>> > any and all unmatched local labels.
>>> >
>>> > Here is why I think this ERC's detecting unmatched local labels is
>>> > essential:
>>> >
>>> > 1. At work, I am using OrCAD Capture for schematic, and I always use
>>> > OrCAD's local labels as the netlists for track connections, as do other
>>> > designers in the team.
>>> >
>>> > 2. At home, then, when working on my hobby projects, I am using KiCAD
>>> > with the same habit and discipline of using the local labels for intra
>>> > sheet netlists.
>>> >
>>> > 3. When these local labels are either misspelled or forgotten at some
>>> > other ends of the parts, they become unmatched and thus result in
>>> single
>>> > netlist names.
>>> > 4. When current KiCAD does not detect these unmatched local labels,
>>> here
>>> > is a sure worst scenario: the PCB made with this unmatched local labels
>>> > will not have the intended ratnets and thus no copper tracks will be
>>> > laid out.  Ultimately it is rendered a non working PCB.
>>> >
>>> > Let me know if you have any questions,
>>> >
>>> > --Joe
>>> >
>>> >
>>> > _______________________________________________
>>> > Mailing list: https://launchpad.net/~kicad-developers
>>> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~kicad-developers
>>> > More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>

References