kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

One of my least favorite tasks as project leader is to deal with issues
like this.  But if I don't they will fester and become problematic which
can set the project back.  I also like to take the time to think issues
like this through so I can respond to them in a calm and rational manner
rather than a knee jerk reaction so that is why I did not repond sooner.
 I view these issues as opportunities for personal and project growth.
I'm not naive enough to believe that this will necessarily happen but
that doesn't mean I shouldn't try.  It also gives me a chance to inform
new developers what my expectations are for the development team.  This
is not directed a Chris per se but his email has elements in it that I
feel I must address.

On 1/13/2016 12:54 PM, Chris Pavlina wrote:
> I concur. I probably shouldn't be inflammatory esp considering I just 
> became part of the commit team, but suggestions like this really are 
> just /stupid/ and detract from attempts to make KiCad actually usable. 
> Someone really needs to just bite the bullet, tell him the whole nginx 
> crap and half the design of the github plugin in general is awful, and 
> do this properly. We cannot go telling our users, many of whom are more 
> firmly experienced in engineering than networking, to go setting up a 
> bloody local web server to make their EDA software work.

I do not understand this visceral response to a suggestion to help users
who are having issues.  Just because you don't like it does not make it
stupid.  Calling this suggestion stupid neither helps the user nor does
it move the project forward in any meaningful way.  If you really wanted
to be useful in this case, provide you own suggestion so that users can
resolve their footprint download issues.  In the past I've suggested
that users the clone the github footprint library repos on their hard
drive if they are having github access issues.  Given that this requires
some technical skill to use git, it's probably not obvious to many users
how to do this.  Does this make me stupid for suggesting it?  I don't
think so nor do I think setting up a caching proxy server is stupid.
They both have their strengths and weaknesses as solutions.  I consider
these kinds of responses immature, disrespectful, and disappointing.  I
expect better from the KiCad dev team.  I know there are a few new devs
who have not been around for previous comments of this nature so you now
know where I stand on this kind of behavior and should consider this
carefully in the future.

> 
> This whole thing has been handled rather poorly. When bugs were first 
> found, Dick should have just notified Mark of what the problems actually 
> were, and one of the committers could have reverted the patch until the 
> bugs were fixed. Instead he kept going at it in private, only 
> communicating with a lucky few, replacing half the code with what looks 
> to me no better than the original. We're statically linking "the 
> required portions of" openssl now? Really? What about the license issues 
> that were mentioned before? And even ignoring that, I've never seen any 
> other programs that do that, surely we could figure this out just like 
> they did and not resort to horrors like static linkage.

I did pass the issues that Dick found to Mark on the mailing list.  I
heard nothing from Mark to indicate that he was working on fixing it.
Maybe I missed it (if so I apologize) but I didn't get that impression
from the conversation.  I'll give Dick credit for fixing the issue.  We
broke the GitHub plugin that he wrote.  Whether you like it or not, I
never had any issues with it until I committed Mark's patch.  I will
take full responsibility for that mistake and using the static linking
because I asked Dick to do it that way.  That issue has been addressed
in the latest patch along with the thread locking issue when libcurl is
linked against openssl.

> 
> What happens when a critical security bug is found in openssl, and kicad 
> is still using the old version because due to static linkage it's not 
> receiving system updates to that library?
> 
> Personally I think we need to slow down, take a step back - maybe revert 
> the original patch to get things working properly in the devel branch 
> again, then let someone like Mark who can do this properly without 
> introducing a bunch of security and maintainability issues. When Dick 
> finds a bug, he can file a bug report like the rest of us, communicate 
> with the rest of us like the team player I was told we're supposed to 
> be, and perhaps help fix problems without just taking over development 
> and kludging together a fix.

You are correct.  I'm going to put brakes on things as I feel they are
getting away from me which I am not comfortable with.  This may not suit
everyone but I'm not scaling very well so it is what it is.  In the
future, I will only allow bug and build fixes for the github plugin as
it stands it it's current form.  Rather than allow changes to the github
plugin, I will make it the policy to create a new plugin so that they
can be used side by side for comparison purposes.  This is what I should
have asked Mark to do rather than replace the avhttp version with his
patch.  This way we could have used the stable avhttp variant of the
github plugin while the new libcurl variant of the github plugin is
being developed.  Why I didn't think of this before I don't know.  It
would have been a much better solution.  I apologize to all parties
concerned for that lack of insight and the grief it caused.

> 
> On Wed, Jan 13, 2016 at 12:36:56PM -0500, Mark Roszko wrote:
>>> I still would never use the plugin without nginx, and I think that should be made more clear to those who wine about speed.
>>> There is an awful lot of whining, and none of these people even seem to know about nginx.  nginx + github plugin is even faster than the PCB_IO plugin.
> 
> Final mini-rant: ***Stop the silly micro-optimizations!!*** Who cares if 
> it's marginally faster, if he did the UI properly so it didn't totally 
> freeze up and gave some indication of its progress, nobody would mind 
> waiting a few seconds.

Once again, the rant serves no purpose and does nothing to solve the
problem at hand.  The conversation should be what are we going to do to
resolve this issue?  We do need to add some type of indicator to cvpcb
to keep the user informed that the footprint libraries are being loaded
when they have slow or unreliable connections.

Thank you for your time and patience as we work through these issues.
There is nothing here that cannot be overcome with a bit of calm and
self reflection.

Cheers,

Wayne

> 
> 
>> I give up, suggestions like these are ridiculous. Feel free to
>> rollback to avhttp. I just literally give up. o7
>>
>> _______________________________________________
>> 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
>