kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/3/20 3:59 PM, Jon Evans wrote:
> Are you talking about temporary churn to project files?
> In my opinion, I think during the 6.0 development cycle it's okay as
> long as we stabilize by the time we cut a RC.

Churn.  But given that it only effects nightly builds, I can live with it.

> 
> Again, in my opinion we should only persist the "ignore" rules, not
> every marker, and if we take that approach, people won't be impacted
> unless they use the ignore feature.

This is going to end up in the project file isn't it?  If so, then I
have no issues with this.

> 
> -Jon
> 
> On Tue, Mar 3, 2020 at 3:56 PM Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     On 3/3/20 8:59 AM, Jon Evans wrote:
>     > Hi Jeff,
>     >
>     > There are several ways to do persistence.  It sounds like you are
>     > planning to implement it as "save the state of all DRC markers", which
>     > is one way.
>     > Another way would be to just save the exceptions (aka waived
>     > violations), so closing and opening a board would not return the
>     markers
>     > to view, but re-running DRC would.
>     >
>     > The choice of approach maybe impacts your questions.  If the goal
>     is to
>     > persist the entire state (i.e. someone can close and re-open
>     PcbNew and
>     > nothing is changed about the DRC markers), you obviously have to
>     save a
>     > lot more data and so the diff churn becomes more of a concern.  If you
>     > only persist the "settings" in the form of waived violations, there
>     > shouldn't really be a churn problem.
>     >
>     > For ERC, I was always thinking that waived violations would have to be
>     > stored in a project-local settings file rather than any one schematic
>     > file, because ERC violations are not tied to a specific sheet.  It
>     seems
>     > fine to me to have this be a difference between ERC and DRC, though.
>     >
>     > I personally do not think that I need the entire DRC state persisted
>     > across runs for my workflow.  I just need DRC to produce the same
>     > results every time it's run, and that includes persisting violations
>     > that I want ignored.
>     > In regards to what ignoring means, the first option seems
>     sufficient to
>     > me.  I'll have to check some commercial tools to see if they actually
>     > store more data, but I suspect not.
>     > Usually when I mark DRC violations as ignored (in Altium, for
>     example),
>     > it's because I know there is a specific situation going on with a
>     > certain item that is easier to ignore than to write a new rule
>     against.
>     > I don't use ignoring as a way of "bookmarking" where I am in a
>     long list
>     > of errors -- for that I just use clearing by type or by
>     > multi-selection.  Clearing (unlike ignoring) is not persisted in
>     Altium.
>     >
>     > @Wayne - If we do decide to put them in project storage rather
>     than the
>     > board file, I'll be moving them out of the project file to a dedicated
>     > file along with everything else.  I'm fine with Jeff temporarily
>     adding
>     > stuff to the project file so as to not block him on the project
>     settings
>     > work I'm doing.
> 
>     I'm just wondering about the impact to CVS users of adding them to the
>     project file.  I'm not sure if it's an issue or not.
> 
>     >
>     > -Jon
>     >
>     > On Tue, Mar 3, 2020 at 8:42 AM Jeff Young <jeff@xxxxxxxxx
>     <mailto:jeff@xxxxxxxxx>
>     > <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>> wrote:
>     >
>     >     Hi Henrik,
>     >
>     >>     On 3 Mar 2020, at 13:33, Henrik Hansen
>     <Henrik.Enggaard@xxxxxxxxx <mailto:Henrik.Enggaard@xxxxxxxxx>
>     >>     <mailto:Henrik.Enggaard@xxxxxxxxx
>     <mailto:Henrik.Enggaard@xxxxxxxxx>>> wrote:
>     >>
>     >>     1) As long as files with markers can be easily shared between
>     >>     people it is good.
>     >>
>     >>     Why isn't "bloated diff" a problem for storing the markers in the
>     >>     project files?
>     >
>     >     I don’t think people diff their project files, but I know some of
>     >     them diff their board files.
>     >
>     >>
>     >>     Would it make sense to have an option to not store the markers?
>     >
>     >     That’s another option.
>     >
>     >>
>     >>     2) The second scenario of marking a specific error is the least
>     >>     surprising. How frequently will there be multiple errors of a
>     >>     certain type between the two same objects? That is a risky
>     >>     scenario, but it is hard to asses without knowing the chance.
>     >
>     >     It’s not for multiple errors, but for running DRC again.  So if I
>     >     mark “ignore pad to pad clearance between pads 1 and 7 of
>     U22”, when
>     >     I run DRC again it will still ignore it.  (The risk is that I
>     might
>     >     have moved them even closer together, and that while the first
>     >     clearance violation was deemed acceptable, the second wouldn’t
>     be. 
>     >     Then again, if you want to check again you can delete your
>     ignore list.)
>     >
>     >     Cheers,
>     >     Jeff.
>     >
>     >
>     >>
>     >>     Best regards,
>     >>     Henrik
>     >>
>     >>     On Tue, Mar 3, 2020 at 11:04 AM Jeff Young <jeff@xxxxxxxxx
>     <mailto:jeff@xxxxxxxxx>
>     >>     <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>> wrote:
>     >>
>     >>         Part of the 6.0 DRC architecture is marker persistence.  This
>     >>         will allow you to work your way through a large set of DRC
>     >>         violations, flagging those that have already been checked as
>     >>         exceptions or some-such.
>     >>
>     >>         Two questions:
>     >>
>     >>         1) Store markers in board file or project file?
>     >>
>     >>         Board file is much easier (in fact currently zero-cost as
>     it’s
>     >>         implemented in my tree), but it may cause heartache in
>     >>         “bloated diff” camp?  (Note that you can always press Delete
>     >>         All Markers when you’re done with DRC, so you can choose to
>     >>         not have them in the board file.)
>     >>
>     >>         2) Should exceptions be of the form “ignore error type X
>     >>         between object Y and object Z”, or “this specific error
>     >>         condition is a false-positive”?
>     >>
>     >>         The first is more like a C++ #pragma.  The second is arguably
>     >>         “safer”, but requires storing hashes of the entire data-state
>     >>         of objects Y and Z.  Likely expensive to calculate on large
>     >>         boards (and somewhat expensive to implement).
>     >>
>     >>         Cheers,
>     >>         Jeff.
>     >>         _______________________________________________
>     >>         Mailing list: https://launchpad.net/~kicad-developers
>     >>         Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >>         <mailto: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>
>     >>     <mailto: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>
>     >     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
>