kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/03/2013 05:02 PM, Adam Wolf wrote:
> Thanks.
> 
> My company has a little money and a little time to help out a Free and
> Open Source ECAD tool.  So far, we've chosen Kicad.  We spend time
> every week doing things like maintaining build servers (time *and*
> money), working on the Mac packaging scripts, answering people's
> questions about the PPAs, writing Kicad tutorials, teaching Kicad
> classes, and adding tests to Kicad.  A friend of ours runs a board
> order.  At one point, and maybe still, Kicad was the single largest
> source of files for his order.  We was hoping to give him a little
> functionality that Eagle has, by using the Kicad Python scripting
> support.
> 
> I didn't realize there were large architectural changes that would
> have to precede adding a file to the SWIG interface.  If I would have,
> I certainly wouldn't have approached this feature.
> 
> I've been polite and gracious, but to be completely honest, I feel
> discouraged by both the tone and the content of some of the responses
> in this thread.  Is there a different way you would suggest that I
> should have approached this?
> 
> Adam Wolf
> Wayne and Layne, LLC


Hi Adam,

Some things simply take time.  Miguel and I both expressed a desire to honour any
scripting API we put out there.  And I think you want stability too, especially if your
work is based on it.

There was a patch recently that took 1.5 years to get in, and I just committed it this
week.  It required 6 hours of my time to get it the way I wanted it.

So I don't find any fault in any of your comments or in your approach.  In fact, I would
say you have been very professional.

One of the key postings in this thread was Miguels "rereading" posting, when he expressed
concern.  That should have perhaps lowered your expectations at that point.
Disappointment is almost by definition, "when expectations exceed reality".

Don't be discouraged, we appreciate what you do for KiCad.

Also please understand one important last point.  It is the discerning scrutiny on inbound
patches that have led to the gradual increase in quality of KiCad over time.  Please check
out revision 1, sometime.  Most patches don't go in without modification.  Most don't get
looked at in the first week.

I don't know what else to tell you, other than that I think you are a class guy, with
talent, and I personally enjoy my interactions with you.

Dick




> 
> On Fri, May 3, 2013 at 4:39 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>> I haven't even had time to read what Lorenzo is thinking yet.  And as I said, I would not
>> do anything this big without talking to the key share holders, excuse me, lead developers,
>> JP and Wayne.
>>
>> So at some point, providing I can catch up in time to satisfy you, by me executing those
>> steps, that would be something I can do, yes, provide you with a quote.
>>
>> The consultative decision process, ahem, involves consultation.  And believe it or not,
>> consulting your patch would be on that list also.  I haven't even looked at it yet.
>>
>> But then, yes, the functionality is needed, and I am delighted you are open to funding the
>> balance of work, and providing a portion of it possibly, as already written.
>>
>> Thanks for asking.
>>
>> Dick
>>
>>
>>
>>
>> On 05/03/2013 04:23 PM, Adam Wolf wrote:
>>> Hi Dick,
>>>
>>> I appreciate the 1187 commits.  If I didn't, I would have simply
>>> created another PPA and maintained a testing branch, selling this
>>> functionality to board houses.
>>>
>>> Can you tell me (privately if need be) how much Wayne and Layne would
>>> have to pay to have you implement enough of your desired changes so
>>> something providing this functionality is acceptable and can be
>>> committed in core?
>>>
>>> Adam Wolf
>>> Wayne and Layne, LLC
>>>
>>> On Fri, May 3, 2013 at 4:05 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>>>> On 05/03/2013 03:07 PM, Adam Wolf wrote:
>>>>> Hi folks,
>>>>>
>>>>> Can I selfishly suggest something?
>>>>>
>>>>> Since Dick has a plan for where this goes and how the future interface
>>>>> works, can we do the minor changes in my patch so that folks that
>>>>> choose to use the experimental Python features can get to the drill
>>>>> calls?
>>>>>
>>>>> I tried to propose a solution to create drill and plot files from the
>>>>> command line that has (hopefully) minimal changes to Kicad.  If the
>>>>> team agrees that those minimal changes probably won't hurt anyone, is
>>>>> it ok that they get committed?  I like Dick's vision and how nicely it
>>>>> aligns with the dll/dso future.
>>>>
>>>>
>>>> You can push to your own branch, and they can get it from there.
>>>>
>>>> We're having a discussion now.
>>>>
>>>> (I'm beginning to wonder if open source software development is a spectator sport after
>>>> all.  This is why a lot of stuff happens off list.)
>>>>
>>>> This is a reasonably significant architectural decision, and having folks become dependent
>>>> on some temporary feature is not prudent, and I don't want it to lock us in to honour some
>>>> previous API, or form of obligations.
>>>>
>>>> So I think its best that the testing branch be done correctly.  I would want to consult
>>>> with Jean-Pierre and Wayne, probably in private.
>>>>
>>>>
>>>> The GPL says you get to use my code.  It does not say I have to accept yours.  The process
>>>> here is not democratic.  It is evolution by consultation.
>>>>
>>>> Folks are free to publish their own branches, and you can vote on those branches.  In
>>>> branch testing, I am a key shareholder, and I have trusted people that I consult to make
>>>> important decisions.
>>>>
>>>>
>>>> $ bzr log | grep 'ickelbeck\|ollenbeck' | wc -l
>>>> 1187
>>>>
>>>> The 1187 commits.... should mean something to you and should explain why every now and
>>>> then I perk up and assert more control.  Actually I am in control *all* the time, it only
>>>> looks like I am not, because the consultative decision process is happening without you
>>>> knowing it apparently.  This is not to say I have to or want to control everything,
>>>> precisely not.  But exposing APIs means people become dependent on them, that is a form of
>>>> an obligation.  Obligations are somewhat binding, so I perk up.  Other stuff is not as
>>>> important.
>>>>
>>>> So no, we're not committing your patch.  At least not at this time.  But I said that in so
>>>> many words yesterday.
>>>>
>>>>
>>>> Dick
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Adam Wolf
>>>>> Wayne and Layne, LlC
>>>>>
>>>>> On Fri, May 3, 2013 at 2:45 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>>>>>> On 05/03/2013 02:23 PM, Lorenzo Marcantonio wrote:
>>>>>>> On Fri, May 03, 2013 at 02:02:01PM -0500, Dick Hollenbeck wrote:
>>>>>>>> What about what I think Lorenzo?  Is that important to you in any way?
>>>>>>>
>>>>>>> I reread this:
>>>>>>> https://lists.launchpad.net/kicad-developers/msg07515.html
>>>>>>> (is this what you were talking about, right?)
>>>>>>>
>>>>>>> Quote your message:
>>>>>>>
>>>>>>>> We also talked about moving the non-UI member functions that are now in
>>>>>>>> PCB_BASE_FRAME, PCB_EDIT_FRAME, into a class which is purely for
>>>>>>>> significant actions but with NO UI, like plotting, annotating, etc.  The
>>>>>>>> UI portion (meaning the preceding dialog invocation) would stay out of
>>>>>>>> this class.  conceptually lets call this class BOARD_ACTIONS.  All the
>>>>>>>> functions in BOARD_ACTIONS take enough parameters to operation *without
>>>>>>>> any UI*, by definition.
>>>>>>>
>>>>>>> Well, what I call 'procedural code' could be fit inside your
>>>>>>> BOARD_ACTION stuff. In substance I completely agree with your plan.
>>>>>>> The whole print controller is more or less 'a piece' of the board
>>>>>>> action. Since it's somewhat hypotetical I'd say that the plot
>>>>>>> controllers and the drill controllers are part of the board actions
>>>>>>> interface (not necessarily everything should be put in one class)
>>>>>>
>>>>>>
>>>>>> If they are not in one class, this makes the mix-in tougher back up at the PCB_BASE_FRAME.
>>>>>> You end up with 2,3,4 classes, each holding a BOARD*, and each being mixed in via multiple
>>>>>> inheritance?  Instead of one class.
>>>>>>
>>>>>> In that posting, which was nearly a year ago, I said I had been thinking about it for over
>>>>>> a year.  When you add that up, this is two years, at least.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> In the message before I intended to say that probably there is no need
>>>>>>> to 'deeply integrate' it with the frame since most probably it could
>>>>>>> live by itself (a BOARD* probably would be sufficient for doing the
>>>>>>> work).
>>>>>>
>>>>>> I am thinking that multiple inheritance at the FRAME level is one line of code to do the
>>>>>> mixin.  And yes, of course it can live detached as well.  One class, two living
>>>>>> environments.  If instantiated stand alone, then it is an interface for python.  If
>>>>>> instantiated as part of frame, it augments a frame.
>>>>>>
>>>>>> Since it is ONLY actions, i.e. procedural calls, then the integration happens in the
>>>>>> frame, no that is already done.  Just move *procedural* functions into BOARD_ACTIONS, no
>>>>>> event handling, no dialogs, no UI.
>>>>>>
>>>>>> What am I missing?
>>>>>>
>>>>>> The dialogs can stuff something like the PLUGIN PROPERTIES object, which could be renamed
>>>>>> to say, OPTIONS.  Then OPTIONS can be passed to some of the functions in BOARD_ACTIONS.
>>>>>> Or python can stuff OPTIONS, and do the same.
>>>>>>
>>>>>> This has been my vision for 2 years.  Just saying you don't like it or that it is not
>>>>>> necessary, is actually an insufficient argument.  Will it work, and what is better if
>>>>>> anything, and why?
>>>>>>
>>>>>>
>>>>>> Dick
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was referring to the following paragraphs where you say:
>>>>>>>
>>>>>>>> BOARD_ACTIONS could then be transported into two realms:
>>>>>>>>
>>>>>>>> a) back into PCB_*_FRAME by multiple inheritance, so you are back to
>>>>>>>> where you started from with respect to PCB_EDIT_FRAME.
>>>>>>>>
>>>>>>>> b) into the top of a scripting entry point DLL/DSO.
>>>>>>>
>>>>>>> Since these are 'new' interfaces and not adaptations they can simply use
>>>>>>> the public interfaces without needing to be mixed in.
>>>>>>>
>>>>>>> So, two use cases
>>>>>>> 1) Plot from UI: PCB_FRAME creates the dialog, dialog uses a controller,
>>>>>>> controller does stuff using the board public interface
>>>>>>>
>>>>>>> 2) Plot from script: python creates the controller with a board,
>>>>>>> controller does stuff using the board public interface
>>>>>>>
>>>>>>> I guess it can't be neater than that...
>>>>>>>
>>>>>>> In short, I substantially agree with your whole idea. Otherwise I don't
>>>>>>> get what is different in your plan.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>
>>
>