| Re: [iot-pmc] Paho CQs ... The next generation ... lessons learned?! |
Hello Ian, I don't think you should apologize! I should! I do think that as PMC I and we have messed this one up. True, this would probably have gone smoother it is were less requests at a time. But it were all reasonable requests and I do think that we should be able to handle it! But I also do think that we should learn something from this: a) We agreed now that Python, Golang, et al. are "valid tools". Since these are prominent components I would like to see a list somewhere where these tools are featured and a short explanation guides future users how to make a piggy back CQ. I think this could be a static HTML page, beside the other IP related pages. b) I agree that the number of requests and their complexity caused the hiccup. However we need to be able to handle this. I do think that voting in the mailing list is a simple solution. But personally I am missing some overview. It is easy to miss a mail. And voting messages are more important than others. But I am not sure what the improvement could be here. Since, beside voting, there is the process of deciding works-with or pre-req. So building a simple web based voting tool will kill the decision making process. c) Next time post your CQs, go on vacation, come back, problem solved ;-) Jens On 04/06/2016 06:48 PM, Ian Craggs wrote: > Jens, > > (and Kai and other members of the PMC). Thank you very much for your > work on these CQs, it is much appreciated. No need to apologize, I > realize the complexity of the task, and the fact that I submitted a > number at the same time. I was on vacation when this email was sent, > and I missed it amongst all the others, which is the reason for the > late reply. > > I hope that at least some of these CQs will be useful to other > projects - that we have reduced at least some future work for the PMC > and those projects. > > I fully agree about the questions of C runtimes and networking > libraries for different operating systems. That is, there are some > things to be clarified, but that needs to be done beyond the scope of > just Paho. I hope that the current CQs are sufficient to allow the > next release (1.2). > > On the subject of the Web Browsers CQ for JavaScript, it is true that > the requirements are for JavaScript and WebSockets. And yes, the > WebSocket API is required for Paho to work. I called it Web Browsers > because I know that the Paho client will not work in Node.js for > instance, and that it was intended to be used in Web Browsers. And I > know that the Web Browsers have WebSocket support integrated with > JavaScript. I'm not sure how you would get the WebSocket API outside > of a web browser environment. > > A CQ for JavaScript should be exempt prereq, but what would the > WebSockets library be? I'm hoping also prereq, as it is supplied by > the Web Browser in the case of Paho. I'll open the CQs for discussion. > > The only other CQ outstanding then is: > > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10814 OpenSSL for > the C client. > > If you want to use TLS/SSL communications then you have to use this > library. You can use the library without TLS of course. We don't > distribute OpenSSL, but we do distribute binaries that link to it. > There are previous OpenSSL CQs such as > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8766, but I wanted a > more open ended one to include future versions. All the existing CQs > are works-with requests. > > Ian > > > On 03/16/2016 10:30 AM, Jens Reimann wrote: >> I really do have to apologize to Ian for the time it takes! Sorry! >> >> So, Kai already provided a nice list and the idea of doing a combined >> vote. However it somehow got stuck in the middle. And want to re-try his >> approach and wrap it up as I see the current state. Following this >> e-mail I will send out a few e-mail which I would like to use for >> voting, since I also do think that we have a few simple CQs and a few >> not-so-simple ones. Getting rid if the simpler ones will shorten the >> list! >> >> == We have two pretty simple ones: >> >> * https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10821 - lua -> +1 >> already >> * https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10698 - Test and >> Build dependencies for Paho >> >> "Lua" seemed like a piggyback and Julien already gave a +1 after the IP >> requested. Done. Nothing to do. >> >> The build and test dependencies seem fine for me as well. -> Should be a >> vote for works with in a separate mail thread. >> >> == C/C++ based >> >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10815 - Visual C++ >> Redistributable >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10697 - libstdc++ >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10656 - glibc >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10817 - TI cc3200 SDK >> and firmware >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10699 - ARM mbed tools >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10820 - FreeRTOS + TCP >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10695 - arduino >> >> I would consider the following all C/C++ based. As Kai, Ian and Roger >> stated before, I also do think that the actual dependency is the C >> runtime, C++ runtime and may use libstdc++, glibc or the platform >> specific SDKs as its implementation. That would make "C runtime" a >> pre-requisite dependency, and glibc a works-with as well as the other >> embedded device specific SDKs. >> >> Unless ... You are using some Microsoft specific API from the Visual C++ >> redistributable API. As an example, opening a file with "fopen" would be >> the ANSI C standard function. Using the "OpenFile" function would be a >> Microsoft specific API. Now we could look at this from a more abstract >> point: As long as Paho can open file either way, "ANSI C" could be the >> pre-requisite and any other function could be "workswith". >> >> So from the point that Paho is a networking component, I guess that >> "ANSI C", "C++ standard library" and "BSD sockets" would be sufficient. >> >> But all those assumptions are only true if Paho only provides the source >> code! And never any binaries which contain parts of the linked SDKs. >> >> To be formally correct, we would need to have generic CQs for "ANSI C", >> ... but on the other hand how could be have Java without those? There is >> no formal CQ for Java either. And I think this has to be improved, but >> this should not be part of this discussion. >> >> So I would suggest to proceed with all of them as "workswith". >> >> == Language based >> >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10904 - .Net Framework >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10818 - Golang >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10696 - Python Version: >> 2 and 3 >> >> Those are all based on different programming languages. As was the lua >> one. Since there is no real alternative for Golang, these all seem like >> "pre-requisite" and possibly exempt. But this latter decision is made by >> EMO AFAIR. >> >> And: >> >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10819 - go.net >> >> Would then be a simple dependency like an other JAR. >> >> == The special one >> >> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10816 - Web browsers >> >> My first though was that we were talking about web browser ... however >> the request actually is for JavaScript and the WebSocket API. I would >> suggest to close those and re-open this as a dependency on "JavaScript" >> ... which is the same scenario as with the other languages, and in fact >> I know so many Eclipse projects which already depend on this but never >> formally requested a dependency. And the same goes for the WebSocket >> API. However this part of Paho won't work without it, as far as I >> understood. >> >> == Conclusion/Suggestion >> >> One vote thread for -> Test and Build dependencies for Paho (possibly >> works with) >> One vote thread for -> C/C++ core runtimes (possibly works with) >> One vote thread for -> Languages (possibly pre-requisite) >> Normal CQ for go.net -> No vote >> Split up web browser CQ to -> JavaScript + WebSocket API >> >> Let me know what you think ... possibly with a simple +1 or -1 ... If >> you have objections to my suggestions on workswith or pre-requisite we >> can do this in the vote, since we are actually voting "pre-requisite" or >> "works-with" instead of +1 or -1. >> >> Jens >> > -- IBH SYSTEMS GmbH D-85235 Pfaffenhofen an der Glonn Läutenring 43 Geschäftsführer / CEO: Dr. Thomas Heitzig Amtsgericht München Handelsregister Nummer HRB 197959 USt ID: DE267945175 Office Munich D 80992 München Agnes-Pockels-Bogen 1 T +49 89 18 9 17 49 0 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or pivileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Attachment:
signature.asc
Description: OpenPGP digital signature