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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
