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" <stambau...@verizon.net> 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@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 >
_______________________________________________ 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
