kicad-developers team mailing list archive

[Joseph Chen <joseph.chen59@xxxxxxxxx>]

@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" <stambaughw@xxxxxxxxx
> > <mailto: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
> >      <mailto: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
> >      <mailto: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