|
Hi Ian,
a) Across the Foundation, this should be the same for all
b) Maybe. Maybe, a dedicated mailing list for votes?
Jens
On 04/08/2016 09:35 PM, Ian Craggs wrote:
Hi Jens,
I was apologizing because we (Paho) should have submitted many of
these CQs a long time ago, and I am partly to blame for that, for
not understanding the 3rd party dependency requirements
properly. But the important thing now is that we have a better
understanding for the future.
a) I agree. Across the whole of the Eclipse Foundation, or just
IoT?
b) Some votes are carried out on the CQ itself - would that be
better?
c) :-)
Ian
On 04/08/2016 09:36 AM, Jens Reimann
wrote:
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
_______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
--
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.
|
