kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey David,

Thanks.  Being concise is a matter of necessity.  I don't have enough
free time to write long responses and I don't want anyone on the
development to have to guess what I'm thinking.

Cheers,

Wayne

On 4/11/2016 8:40 PM, David Godfrey wrote:
> Hi Wayne,
> 
> Nice concise response and good direction, exactly what is needed from a
> Project Leader.
> 
> Regards
> David G
> 
> On 12/04/16 07:32, Wayne Stambaugh wrote:
>> I'm going to put on my project leader hat and try to respond to all of
>> the issues discussed thus far rather than reply to each concern
>> individually.  I'll start off by saying that many of you are going to
>> disagree with me but I'm OK with that.  At the end of the day, I'm
>> responsible for the code that ends up in KiCad so my opinion counts just
>> a little so here it goes.
>>
>> As for providing the ability to save older file versions, I have very
>> little interest in asking any of our developers to provide this given
>> the project's limited manpower.  Comparing KiCad to LibreOffice shows a
>> lack of understanding in just how few developers contribute to KiCad.
>> There are many paid full time developers working on LO, and hundreds of
>> volunteers.  KiCad has two very part time paid developers, a couple of
>> regular contributors, and a handful of occasional contributors.  This
>> does not mean that I do not care about our users.  On the contrary, I
>> prefer to use our limited manpower resources to get the most bang for
>> our buck.  I believe we have much bigger issues to resolve than being
>> able to save to old file formats.
>>
>> Any changes to the file format, parser, and output formatter will be
>> heavily scrutinized to ensure they meet the following criteria: the file
>> format must be human readable without being overly verbose and the file
>> parser and output formatter code must well designed, easy to understand,
>> and easy to extend.  Everything I have seen discussed thus far runs
>> counter to these design goals.  I am not saying that I will not allow
>> any changes but these design goals are in play.  This means you should
>> assume that the bar is going to be very high for any changes to this
>> code and/or the file format.
>>
>> That being said, we should attempt to provide some type of file version
>> information to help the user figure out what to do when they have file
>> version issues so I propose we do the follow:
>>
>> * Use Chris' time stamp version number patch.
>>
>> * Allow the file to be parsed as is.
>>
>> * If the file fails to parse and the file header information is valid
>> use the version number to determine if the file is corrupt (<= build
>> file version) or the file may have failed because it contains features
>> not available ( > build file version).
>>
>> * If the header was not successfully read, warn the user that the file
>> does not appear to be a kicad board file.  If the file does parse
>> successfully and the file version is > than the current build version,
>> warn the user that the file was created with a newer version of KiCad
>> which may result in data corruption and/or loss and see if they want to
>> continue.
>>
>> * If the file version is <= the build file version than all is well.
>> This should cover most of the file parsing cases and give the user some
>> useful information on what steps they may or may not want to take to
>> resolve their file version issues.
>>
>> This may not satisfy everyone's goal but it's far better than what we
>> are doing currently without making a mess of our file format, parser,
>> and output formatter.
>>
>> Cheers,
>>
>> Wayne
>>
>>
>> On 4/11/2016 12:00 AM, David Godfrey wrote:
>>> Hi All,
>>>
>>> On 11/04/16 07:37, Wayne Stambaugh wrote:
>>>> Let's slow down and think about this a bit.  I'm not sure that this is
>>>> the best way to resolve this.  Let me chew on it a bit and I will get
>>>> back to you.  I've been busy today so hopefully by tomorrow I'll have an
>>>> answer.
>>> Wayne,
>>> Off the cuff I'd propose a single "used features" block in the file format.
>>> This would purely be a list of features that are used by this file. then
>>> it's easy for the loading software to confirm what it supports
>>> eg: roundrect-1, angletext-33
>>> the appended number can be used to differentiate between non backwards
>>> compatible versions of a feature
>>>
>>> This would be fairly easy to implement, and trivial to test at file load
>>> The hardest part would be spending the time to go through and define the
>>> struct to the project that records every feature we care about.
>>> Although that could be done by only adding features to that struct when
>>> a change is made from now on.
>>>
>>> Regards
>>> David G
>>>> Thanks,
>>>>
>>>> Wayne
>>>>
>>>> On 4/10/2016 12:36 PM, jp charras wrote:
>>>>> Le 10/04/2016 16:11, Chris Pavlina a écrit :
>>>>>> I like the idea. It'll take some work to implement properly, though. I can
>>>>>> start working on it, but it will likely be at least a week before I have
>>>>>> anything.
>>>>> Thanks you to make me very happy ...
>>>>>
>>>>>> On Sun, Apr 10, 2016 at 04:05:42PM +0200, jp charras wrote:
>>>>>>> Le 10/04/2016 15:31, Chris Pavlina a écrit :
>>>>>>>> So - would you be happy with me just changing that to a warning that can be
>>>>>>>> clicked through instead of an error, and rewriting the message a bit to agree?
>>>>>>>>
>>>>>>> I'll be more happy.
>>>>>>>
>>>>>>> But I'll be really very happy if a dynamic version numbering is also added, rather a fixed arbitrary
>>>>>>> number.
>>>>>>>
>>>>>>> Currently the version is 4.
>>>>>>> If a method is added (something like GetMinimalVersionNumber()) to all board items (tracks, texts
>>>>>>> footprints, pads...), each item can return the needed minimal version to be read in file.
>>>>>>> Currently they could return 4, but for a pad, if its type is rounded rect it will return 20160410,
>>>>>>> and therefore its footprint parent returns 20160410 (or 4 if no rounded rect pad is found)
>>>>>>>
>>>>>>> Before writing the file, just run BOARD::GetMinimalVersionNumber() to know the actual needed version.
>>>>>>>
>>>>>>> -- 
>>>>>>> Jean-Pierre CHARRAS
>>>> _______________________________________________
>>>> 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
>>
> 
> 
> _______________________________________________
> 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
>