On 3/12/13 2:55 AM, Peter Åstrand wrote: > We are positive to most things on that list. The problems has to do with > development style and cooperation. The rfbTightNoZlib patch is a good > example of this. The thread is available here: > http://thread.gmane.org/gmane.network.vnc.tigervnc.devel/2451 . If I > would summarize it, it goes like this: > > We: "How does this work?", "This could be done in a nicer way", "Have > you thought of this?" > > You: "this extension has been in use for 5 years quite successfully in > TurboVNC, so it definitely works correctly." > > We are more used to a "Linux Kernel" community, were you might need to > explain the code, tweak it, and submit it again. We didn't reject the > idea of rfbTightNoZlib; we asked you to remind us later. We want to > understand patches, and make sure they are close to perfect before > commit. This is QA. Thus, we do not like the concept of blindly > comitting patches from another source, even if that code has been used > by a Fortune 500 company.
Oh, what utter BS, Peter. Did you even read the thread you linked to? The cherry-picked comment above that you seem to believe summarized my whole response is the first sentence in a page full of information explaining to you and Pierre in excruciating detail what the patch does and why it was implemented as it was. Further, it was a dead simple patch, and you can see for yourself by looking at the code what it does. It's hilarious to me that you hide behind "QA" as a reason for rejecting or stalling contributed patches, since you and Pierre have on many occasions checked in patches that fundamentally broke something. Of course those resulted in arguments as well, even though it was clearly provable that the patch caused problems. I've come to realize that what it basically boils down to is: you trust only yourselves, regardless of how wrong you might be. And this, more than anything else, is why I can't and won't work with you ever again. And what do you mean you are more "used" to a Linux kernel community? Such a community has never existed within the TigerVNC Project. Who has checked in any significant native code over the past year other than Cendio? Sorry, but if you want TigerVNC to be more of a bazaar than a cathedral, then you need more than one vendor at your bazaar. As it stands, there are zero checks and balances in the project, zero formal QA or release processes, and generally nothing on the open source side that would give anyone any confidence that the project code has any kind of stability at all. Such stability can be gained only in using TigerVNC as part of a product, such as ThinLinc or Red Hat Enterprise. Yes, my development strategies are probably somewhat different from yours, but again, it boils down to trust. If I didn't know what I was doing, then my project wouldn't have a Red Hat Innovator of the Year Award to its credit, and it wouldn't have thousands of seats in corporations, and it wouldn't be the VNC of choice on the TeraGrid and numerous other research supercomputers. My work at Fortune 500 companies taught me skills that I use on a daily basis, and those skills are what make TurboVNC what it is. They are what instill confidence in the companies who pay me as a contractor. They are what prompted you to bring me into the project to begin with. Now, do you want to continue this pointless discussion, or can we get on with our lives? ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
