I agree with this. The current pad parsing code should not be open ended even if there are plans for future expansion.
On 3/27/2018 1:51 PM, Seth Hillbrand wrote: > Hi Jeff- > > Can we split this patch? I think the addition of strict checking for > the pads should be in 5. > > -S > > 2018-03-27 10:34 GMT-07:00 Jeff Young <[email protected] > <mailto:[email protected]>>: > > 5.0, 6.0 or abandon? > > >> On 20 Mar 2018, at 16:47, Jeff Young <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Wayne, >> >> This solution /*is*/ pretty much “property” tokens except that: >> >> 1) it’s more flexible (properties can be arbitrary s-expressions) >> 2) it handles 3rd-party-needs and our own with a single infrastructure >> >> I was going to add (3) it requires name-spacing, but “property” >> tokens will require name spacing anyway (to keep 2 different 3rd >> parties from colliding). The only difference is that we get the >> default name-space to ourselves. >> >> In fact, I think the “property” angle is a much better angle to >> look at it from. Rather than think of it as a file-format issue, >> think of it as s-expression meta-data for BOARD_ITEMS. If we >> later decide that "(hole-to-hole-clearance 0.25)" should define a >> distance used by DRC, then great. Until then, it’s just an opaque >> s-expression. >> >> I also think it demonstrates that the risk of wiping out stuff >> editing a future board with an older version isn’t really there. >> Just like “properties”, we’ll round-trip whatever meta-data was in >> the board. Sure, new BOARD_ITEMS that you add won’t have the >> future data, but why would they? >> >> (And if we remain concerned José’s force-save-as solution is an >> excellent idea.) >> >> The code complexity it adds to the parser is tiny. It turned out >> to be far easier to implement than anticipated. >> >> Cheers, >> Jeff. >> >> >>> On 20 Mar 2018, at 14:48, Wayne Stambaugh <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Jeff, >>> >>> I wanted some time to think about this. It has been discussed >>> before. >>> While I'm not completely opposed to it, I still haven't found a more >>> compelling argument to convince me that it is a better idea than >>> using >>> strict parsing. As a user, it does have a certain appeal. As a >>> developer, it opens a Pandora's box of issues that once they are in >>> play, could be extremely difficult to reverse. Please see my >>> responses >>> below. >>> >>> On 3/20/2018 9:40 AM, Jeff Young wrote: >>>> @Wayne, did you have any thoughts on this iteration? >>>> >>>>> On 20 Mar 2018, at 10:22, Jeff Young <[email protected] >>>>> <mailto:[email protected]> >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Oh, and I don’t think this materially alters the support >>>>> equation: we >>>>> already have to deal with hand-edited boards, so what’s in the >>>>> file is >>>>> never guaranteed to be something Kicad put there. >>> >>> True, but this is one of the reasons that the board parser is strict. >>> It is immediately obvious what doesn't belong in the file. Also, >>> in the >>> past users have tricked eeschema and pcbnew into a feature that >>> didn't >>> technically exist by taking advantage of the loose file parsing. >>> Then >>> when something changed internally and their clever hacks were >>> broken, we >>> ended up with bug reports. I do not want to repeat this again. >>> >>>>> >>>>>> On 20 Mar 2018, at 10:19, Jeff Young <[email protected] >>>>>> <mailto:[email protected]> >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Hi Seth, >>>>>> >>>>>> The original version spit out log entries for skipped >>>>>> elements. This >>>>>> version follows the XML/browser convention of silently ignoring. >>>>>> Even though this isn’t an XML format, I think we need to >>>>>> recognise >>>>>> that we live in an XML world and XML processing conventions set >>>>>> expectations. >>> >>> After reading this, I am even more thankful that we didn't choose XML >>> for our file format. Gleefully ignoring file syntax that the parser >>> doesn't understand IMO is a bad idea. This flies in the face of the >>> basic premise that we control the format of our files not someone >>> else. >>> As soon as you allow others to dictate your file format, you are >>> in trouble. >>> >>>>>> >>>>>> The patch strictly checks everything for round-tripping so >>>>>> that there >>>>>> is no data loss. The pad stuff is really a separate issue: it was >>>>>> meant to be loose only during development and then tightened >>>>>> up, but >>>>>> the tightening step was forgotten. Since we don’t store pad >>>>>> stuff we >>>>>> don’t understand, it has to be tightened. In short: if you >>>>>> can round >>>>>> trip stuff you don’t understand then do so; otherwise throw. >>> >>> The round tripping is fine and makes sense but it also adds to >>> the code >>> complexity of the parser. The pad issue is different. I don't know >>> when that was slipped into the parser but it should not be there. If >>> there is an unexpected token, that should flag a file load error. >>> >>>>>> >>>>>> Certainly one use case is opening boards from future versions. If >>>>>> you edit them, then you’re at your own peril. This behaviour is >>>>>> common enough that I believe it is well understood (although we >>>>>> should obviously mention it in a version-check dialog). >>> >>> Perhaps, but I just see this ending badly. Maybe I'm being paranoid >>> here but it's so easy to imagine a scenario where someone did a >>> lot of >>> editing in a newer version of kicad then makes the fatal mistake of >>> opening the board in an older version of kicad and wipes out a lot of >>> work. Technically not kicad's fault but I'm not so sure the user >>> will >>> see it that way. >>> >>>>>> >>>>>> Another use case is 3rd-party tools (which might even be >>>>>> written as >>>>>> Python plugins) that want to carry their own stuff around in the >>>>>> board. These might even be processing/manufacturing instructions >>>>>> that don’t have any visual expression in Kicad anyway. >>> >>> This is one of the primary reasons that I do not like ignoring >>> unknown >>> file formatting. It creates the potential for name space >>> pollution that >>> could cause issues down the road. The eventual goal is to >>> implement the >>> "property" token to define key/value pairs for third party >>> applications >>> to add user specific information to any board object without >>> polluting >>> the controlled part of the file format. The beauty of this is >>> that we >>> do not have to coordinate with 3rd party developers to ensure we >>> are not >>> clashing with anything the are working on. They are free to add >>> whatever properties they would like while we still maintain >>> strict file >>> parsing. This was always part of the grand plan for the board file >>> format that kind of got lost in the noise and me becoming project >>> leader. >>> >>> Cheers, >>> >>> Wayne >>> >>>>>> >>>>>> Cheers, >>>>>> Jeff. >>>>>> >>>>>> >>>>>>> On 19 Mar 2018, at 22:51, Seth Hillbrand >>>>>>> <[email protected] <mailto:[email protected]> >>>>>>> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>> wrote: >>>>>>> >>>>>>> Hi Jeff- >>>>>>> >>>>>>> A few questions on how you are implementing this: >>>>>>> >>>>>>> 1) How does the user know what was skipped? I can imagine team >>>>>>> members with different versions getting into difficulty, >>>>>>> especially >>>>>>> if the features being skipped change the board layout. >>>>>>> >>>>>>> 2) You are removing strict checking for most of the board but you >>>>>>> are adding strict checking for pad options. What's the >>>>>>> difference? >>>>>>> >>>>>>> 3) If we keep these options around but don't allow >>>>>>> editing/removing, >>>>>>> don't we run into a risk of generating a really wonk-y board that >>>>>>> only looks wonky in a newer version of KiCad but looks fine in an >>>>>>> older version? For example, imagine we implement rounded >>>>>>> corners as >>>>>>> a parameter and then a user with an older version of KiCad >>>>>>> edits and >>>>>>> saves the board. The rounded corner is only visible in KiCad >>>>>>> 6 but >>>>>>> the user in KiCad 5 can edit the board to look right to her >>>>>>> only to >>>>>>> have her colleague use KiCad 6 and see the track violating >>>>>>> DRC. I >>>>>>> think that might be counter-intuitive for users but maybe >>>>>>> there's a >>>>>>> way around it. >>>>>>> >>>>>>> In general, if I understand the use-case, this is to allow >>>>>>> users to >>>>>>> open newer boards in older KiCad versions? Is there another >>>>>>> use case? >>>>>>> >>>>>>> I think I can see clear to this for options like the 3d-model >>>>>>> offset >>>>>>> where it could be either inches or mm but there isn't a >>>>>>> difference >>>>>>> in the actual layout. Allowing general unrecognized options >>>>>>> would >>>>>>> seem to open up a worm can in terms of support as in "Please post >>>>>>> the KiCad version and the file version in order to figure out the >>>>>>> problem." >>>>>>> >>>>>>> -S >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2018-03-18 9:46 GMT-07:00 Jeff Young <[email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[email protected]>>: >>>>>>> >>>>>>> OK, for your guys’ (re)viewing pleasure, a patch which >>>>>>> losslessly round-trips stuff it doesn’t understand. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 16 Mar 2018, at 19:15, hauptmech <[email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> While i would still like to see this (my) shim go in, I agree >>>>>>>> with wayne. Until/unless a less brittle approach is used for >>>>>>>> the parser, it's better to signal a problem painfully and >>>>>>>> maintain the integrity of the file. >>>>>>>> >>>>>>>> I have to admit that when i first heard the s-expressions >>>>>>>> idea >>>>>>>> I assumed that the intention was to use a lisp like virtual >>>>>>>> machine for loading and maintaining design data. I've >>>>>>>> used vm's >>>>>>>> for data storage before (lua and python), and it's great. >>>>>>>> Parsing is free and you can jam in functions and other data >>>>>>>> when needed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 17 Mar 2018 07:17, "Jeff Young" <[email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Hi Wayne, >>>>>>>> >>>>>>>> Patch reverted. >>>>>>>> >>>>>>>> However, I think your concern is misplaced. If we >>>>>>>> want to >>>>>>>> prevent dataloss (ie: from reading a 6.0 file into 5.0), >>>>>>>> then we should warn the user based on the version string >>>>>>>> (and give them a chance to say “I still want to open”). >>>>>>>> >>>>>>>> But either way, actually failing to read the file leaves >>>>>>>> the user in a pickle (especially when it’s easy >>>>>>>> enough for >>>>>>>> them to try out a nightly that may very well be ahead of >>>>>>>> their stable). >>>>>>>> >>>>>>>> (And for that reason I think it’s important to put it >>>>>>>> into >>>>>>>> 5.0, as otherwise it won’t help until we start making 7.0 >>>>>>>> file format changes.) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jeff. >>>>>>>> >>>>>>>>> On 16 Mar 2018, at 18:00, Wayne Stambaugh >>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> Jeff, >>>>>>>>> >>>>>>>>> Please revert this patch. Any changes to the board file >>>>>>>> parser and/or >>>>>>>>> formatter need to be discussed before the changes are >>>>>>>> committed. It has >>>>>>>>> been the intention that the board parser be pendantic by >>>>>>>> design to >>>>>>>>> prevent data loss by ignoring unknown formatting. >>>>>>>> Allowing anything >>>>>>>>> outside of the expected formatting in the board file is >>>>>>>> not something >>>>>>>>> that I want to introduce without some discussion. Even >>>>>>>> should we decide >>>>>>>>> to accept this patch, I would prefer we put it off until v6. >>>>>>>>> >>>>>>>>> That being said, the patch fails to build on windows with >>>>>>>> following error: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp: >>>>>>>> In >>>>>>>>> member function 'void PCB_PARSER::parseUnknown()': >>>>>>>>> >>>>>>>> >>>>>>>> C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp:1269:12: >>>>>>>>> error: request for member 'LogText' in >>>>>>>> '__acrt_iob_func(2)', which is of >>>>>>>>> pointer type FILE* {aka _iobuf*}' (maybe you meant to >>>>>>>> use '->' ?) >>>>>>>>> stderr.LogText( msg ); >>>>>>>>> ^~~~~~~ >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Wayne >>>>>>>>> >>>>>>>>> On 3/16/2018 1:08 PM, Jeff Young wrote: >>>>>>>>>> Perhaps somewhat germane to this discussion I have >>>>>>>> removed the strict-format nags from the PCB parser. >>>>>>>> It now >>>>>>>> logs warnings to stderr but otherwise ignores >>>>>>>> structures it >>>>>>>> doesn’t understand. >>>>>>>>>> >>>>>>>>>> I’m not sure that helps hauptmech much as if the file is >>>>>>>> subsequently written the unknown markup will be lost, >>>>>>>> but I >>>>>>>> thought I’d mention it. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Jeff. >>>>>>>>>> >>>>>>>>>>> On 7 Mar 2018, at 20:12, hauptmech <[email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected] >>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Thomasz, >>>>>>>>>>> >>>>>>>>>>> I hope I'm able to address you concerns. I'm stuck >>>>>>>> using kicad stable in many situations. I brought >>>>>>>> clearances >>>>>>>> up for discussion last July but no one moved on it, >>>>>>>> nor are >>>>>>>> they required to. Clearance management is a major pain >>>>>>>> point for me so I wrote a fix. This patch will let us (me >>>>>>>> and the people I collaborate with) work using version 5, >>>>>>>> but open and close files written with a version patched >>>>>>>> with clearance handling code. >>>>>>>>>>> >>>>>>>>>>> I believe that code exactly like this will go into >>>>>>>> version 6. Getting it in earlier makes a huge >>>>>>>> difference to >>>>>>>> me, so I'm submitting it. >>>>>>>>>>> >>>>>>>>>>> On 07/03/18 23:30, Tomasz Wlostowski wrote: >>>>>>>>>>>> Hi hauptmech, >>>>>>>>>>>> >>>>>>>>>>>> I'm sorry but IMHO we can't accept your patch: >>>>>>>>>>>> - it changes the file format while we are already in >>>>>>>> feature freeze. >>>>>>>>>>>> This is a way too big change to accept for the V5. >>>>>>>>>>> >>>>>>>>>>> This patch simply adds tokens to the file format. No >>>>>>>> clearance data is saved for files that use the netclass >>>>>>>> only. Files without clearance tokens continue to remain >>>>>>>> without them. >>>>>>>>>>> >>>>>>>>>>> Yes it is a backward compatible file format change, but >>>>>>>> it does no harm to V5 files already in the wild. >>>>>>>>>>> >>>>>>>>>>>> - we are planning to overhaul the clearance/design >>>>>>>> rules system in V6. >>>>>>>>>>>> Storing the clearance *DIRECTLY* for each track >>>>>>>> segment/via will >>>>>>>>>>>> conflict with any more sophisticated design rule >>>>>>>> management system. >>>>>>>>>>>> >>>>>>>>>>> I'm glad you are planning this. I am sure that >>>>>>>> regardless of the sophistication of the rule system, you >>>>>>>> will store clearance directly for exactly the same reason >>>>>>>> that track width is stored directly now. There are always >>>>>>>> exceptions to the rules. >>>>>>>>>>> >>>>>>>>>>> If kicad choose a direction that does not store >>>>>>>> clearances per item, then it is easy to rip these few >>>>>>>> lines >>>>>>>> back out. >>>>>>>>>>> >>>>>>>>>>> Did this answer your existing concerns about this >>>>>>>> patch? Are there any other concerns you have about >>>>>>>> this patch? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>>>>> Post to : [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>> <https://help.launchpad.net/ListHelp> >>>>>>>> <https://help.launchpad.net/ListHelp >>>>>>>> <https://help.launchpad.net/ListHelp>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>>>> Post to : [email protected] >>>>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>> <https://help.launchpad.net/ListHelp> >>>>>>>> <https://help.launchpad.net/ListHelp >>>>>>>> <https://help.launchpad.net/ListHelp>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>>> Post to : [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>> <https://help.launchpad.net/ListHelp> >>>>>>>> <https://help.launchpad.net/ListHelp >>>>>>>> <https://help.launchpad.net/ListHelp>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>> Post to : [email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>> <https://launchpad.net/~kicad-developers >>>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> <https://help.launchpad.net/ListHelp> >>>>>>>> <https://help.launchpad.net/ListHelp >>>>>>>> <https://help.launchpad.net/ListHelp>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>> <https://launchpad.net/~kicad-developers >>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>> Post to : [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>> <https://launchpad.net/~kicad-developers >>>>>>> <https://launchpad.net/~kicad-developers>> >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> <https://help.launchpad.net/ListHelp> >>>>>>> <https://help.launchpad.net/ListHelp >>>>>>> <https://help.launchpad.net/ListHelp>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>> <https://launchpad.net/~kicad-developers> >>>>>> Post to : [email protected] >>>>>> <mailto:[email protected]> >>>>>> <mailto:[email protected] >>>>>> <mailto:[email protected]>> >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> <https://launchpad.net/~kicad-developers> >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> <https://help.launchpad.net/ListHelp> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> <https://launchpad.net/~kicad-developers> >>>>> Post to : [email protected] >>>>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>>>> <mailto:[email protected]>> >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> <https://launchpad.net/~kicad-developers> >>>>> More help : https://help.launchpad.net/ListHelp >>>>> <https://help.launchpad.net/ListHelp> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> <https://launchpad.net/~kicad-developers> >>>> Post to : [email protected] >>>> <mailto:[email protected]> >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> <https://launchpad.net/~kicad-developers> >>>> More help : https://help.launchpad.net/ListHelp >>>> <https://help.launchpad.net/ListHelp> >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> Post to : [email protected] >>> <mailto:[email protected]> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> More help : https://help.launchpad.net/ListHelp >>> <https://help.launchpad.net/ListHelp> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> Post to : [email protected] >> <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> More help : https://help.launchpad.net/ListHelp >> <https://help.launchpad.net/ListHelp> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp> > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
