For completeness...
An IP Log review is not required for service releases. A service
release can, however, contain additional IP or leverage new third
party libraries (the sorts of things that might result in a changed
IP Log). The only real restriction is that service releases should
not contain any new functionality. A service release can contain bug
fixes for existing functionality only.
HTH,
Wayne
On 04/23/2014 10:33 AM, David M
Williams wrote:
I'll give a couple of
answers to make sure
I cover all the basis ... but, in general, you're right, what
ever is reasonable
for your project AND adopters is fine, for service releases.
(The key being
that only "service field" is changing, and that no changes to
IP Log is required).
So, answer 1? Is the
question based
on exact timing of bugs found/fixed and the release review? If
so, you
can change exact content of the "release" pretty much any time
before the literal review, just keep everyone informed and be
explicit
if it effects "IP Log". If does not, it is pretty much up to
you. If does effect IP log, then you can still tweak that, up to
"last
minute", but that's more up to Eclipse IP staff if they can
accommodate
last minute change (this could happen for example, if the fix
for that
critical bug came from existing committer, or was a patch
provided by non-committer.
Even then, if its a matter of "adding a name", that's usually
fine ... but if its something large, then that's the point it
might require
some delay so that they can do their usual analysis to make sure
it is
IP Clean.).
Answer 2: You (obviously?) don't
want
to do a service release every time you fix any 'ol bug, so its
sort of
a trade off: if "critical" enough that any/every user/adopter
should pick up the fix, then service release would be best, OR
if merely
important, but not critical, you can sometimes simply provide a
"patch"
.... and often just attached to a bugzilla is fine ... with a
statement
that the fix/patch will be included in the next release or
service release.
Keep in mind, too, that its usually best to "make fix available"
as a "service release candidate" for a month or so, and make
sure it really fixes the problem for real adopters/users without
having
some unanticipated side-effect.
From my (little) understanding of
your
project, I think it's reasonable that a component can have its
own "service
release" independent of the rest of the larger project, but also
remember,
its conceptually equivalent, and often easier for adopters/users
to understand
what to do, if you call or package "the whole project" as a
service
release, even though, only one component has actually changed.
This just
makes it easier to communicate things like "use release .91 of
Paho"
rather than (imagine this over time, several months from now)
use .90 of
base Paho, plus .91 of this component, plus .92 of this other
component,
.... etc. That gets confusing quicker than you might imagine.
I hope this brief summary gives
you
the general guidance you need. I'm sure there is "exceptions to
every
rule" so don't be afraid to ask, in future, if you think you
have
an exception to any of the general guidelines, and as long as
you communicate
well to your users and adopters and make it easy for them to
"keep
things straight", then I think Eclipse and staff can accommodate
just
about any thing you need. Make sense?
HTH
From:
Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To:
paho-dev@xxxxxxxxxxx,
Date:
04/23/2014 05:05 AM
Subject:
Re: [paho-dev]
Paho Release 0.9 Review Documentation (for review)
Sent by:
paho-dev-bounces@xxxxxxxxxxx
Hi Roger,
good question. The Eclipse docs say that Service Releases do
not
need a
review. For practical reasons, it would be good if we only
had to
synchronize all the components on non-service releases. In
fact,
I
don't see any other way being reasonable. We should get some
input
from
the project mentors on this.
Ian
On 04/22/2014 11:11 PM, Roger Light wrote:
> Hi Ian,
>
> Great, that makes sense.
>
> My final questions (hopefully) - should I upload 0.9 to
PyPi now or
not?
>
> Do we need to do 0.9.x releases as a project or not? So
if I discover
> an important bug in a few weeks and would like to release
an update,
> does the Java etc. client have to make a 0.9.1 release as
well?
>
> Cheers,
>
> Roger
>
> On Tue, Apr 22, 2014 at 10:01 PM, Ian Craggs
> <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> Hi Roger,
>>
>> thanks for the info. I realize that the Python
client has
support for 3.1.1
>> (so do the Java and C clients in the development
streams), I didn't
want to
>> put that goal into this release without having all
the clients
at the same
>> level. Leaving it for 1.0 in June seemed better.
>>
>> I'll pick and choose some of the other uses and links
- I didn't
want to
>> overload any particular section, and I want to save
some items
for next time
>> :-)
>>
>> Iam
>>
>>
>> On 04/22/2014 06:20 PM, Roger Light wrote:
>>> Hi Ian,
>>>
>>> A couple of comments:
>>>
>>> The Python client has support for 3.1.1, although
it is less
well
>>> tested than 3.1 of course.
>>>
>>> It also indirectly makes use of OpenSSL because
that is what
Python
>>> uses in the back end. The same comments about the
user choosing
the
>>> version of OpenSSL applies here.
>>>
>>> There are now 92 resolved and 31 unresolved bugs
overall,
and 0 listed
>>> bugs for the Python client :)
>>>
>>> I've found some talks and other applications that
make use
of the Python
>>> client.
>>>
>>> https://github.com/jpmens/mqttwarn
>>>
>>> http://jpmens.net/2014/02/17/introducing-mqttwarn-a-pluggable-mqtt-notifier/
>>>
>>> https://speakerdeck.com/jpmens/mqtt-for-sysadmins
>>> https://www.youtube.com/watch?v=iIZMHJSU13E
>>>
>>>
>>> https://ep2013.europython.eu/media/conference/slides/messaging-for-the-internet-of-things.pdf
>>> <- references the Python client back when it
was still
mosquitto.py.
>>> Don't know if that counts :)
>>>
>>> The owntracks (google latitude replacement based
on MQTT)
android app
>>> is based on Paho Java. http://owntracks.org/
Yes, Jan-Piet Mens is
>>> involved with that as well...
>>>
>>> Flukso https://www.flukso.net/
uses Paho Python:
>>> https://github.com/wouterh/flukso-mqtt-client
>>>
>>> There are 79 results when you search for "paho"
on stackoverflow (I've
>>> just added the 'paho' tag as well, so anybody can
tag questions
for
>>> paho).
>>>
>>> Cheers,
>>>
>>> Roger
>>>
>>>
>>>
>>> On Tue, Apr 22, 2014 at 5:14 PM, Ian Craggs
>>> <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>> All,
>>>>
>>>> I have put together the review information
for Paho release
0.9, here:
>>>>
>>>> https://projects.eclipse.org/projects/technology.paho/releases/0.9.0/review.
>>>>
>>>> Please let me know of any updates or changes
you would
like to be made.
>>>>
>>>> My aim is to get the review doc approved by
the PMC and
submitted by COB
>>>> on
>>>> 24th (Thursday).
>>>>
>>>> --
>>>> Ian Craggs
>>>> icraggs@xxxxxxxxxx
IBM United Kingdom
>>>> Committer on Paho, Mosquitto
>>>>
>>>>
_______________________________________________
>>>> paho-dev mailing list
>>>> paho-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/paho-dev
>>> _______________________________________________
>>> paho-dev mailing list
>>> paho-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/paho-dev
>>
>> --
>> Ian Craggs
>> icraggs@xxxxxxxxxx
IBM United Kingdom
>> Committer on Paho, Mosquitto
>>
>> _______________________________________________
>> paho-dev mailing list
>> paho-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/paho-dev
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx
IBM United Kingdom
Committer on Paho, Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
|
