kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

With regards to etiquette and constructiveness, I don't have anything to
say - I either agree with you, or already made clear where I don't, and I
don't think continuing it would be particularly, well, constructive to keep
going.

However, since you asked me directly - no, you suggesting users clone the
repositories locally isn't stupid, it's the minimum required to get what
they need. It's unfortunate that it's necessary, but it is.

I still think setting up a local server is a massively hackish "solution",
and there's a difference between a user suggesting this to another user,
and a developer (in fact, the one who created the need to do this)
suggesting it. Personally, I don't think it's a good look for the project.
Perhaps "stupid" was a bit much, though I am led to believe that the person
who suggested it has not met the average PCB designer and KiCad user.
They're not system/network admin types. :P
On Jan 18, 2016 09:45, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx> wrote:

> 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
> >
>
>
> _______________________________________________
> 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
>