kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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.

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.

-Jon

On Tue, Mar 3, 2020 at 3:56 PM Wayne Stambaugh <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>> wrote:
> >
> >     Hi Henrik,
> >
> >>     On 3 Mar 2020, at 13:33, Henrik Hansen <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>> 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>
> >>         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
> >
> >
> > _______________________________________________
> > 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
>