Proton 0.11 alpha

[Justin Ross <ju...@gmail.com>]

Hi, folks.  I propose to start work on another Proton release soon.

In order to work out any dist issues (and to get myself familiar with the
process), I'm going to produce an alpha at the end of next week.

If things go well, I'll produce a beta a week later, and our first RC a
week after that, near the end of October.

I'm also thinking of introducing a time-based release cadence to Proton,
with new releases falling in October, January, April, and July.

Please let me know what you think.

Thanks!
Justin

Re: Proton 0.11 alpha

[Gordon Sim <gs...@redhat.com>]

On 10/05/2015 09:34 PM, Justin Ross wrote:
> Hi, folks.  I propose to start work on another Proton release soon.
>
> In order to work out any dist issues (and to get myself familiar with the
> process), I'm going to produce an alpha at the end of next week.
>
> If things go well, I'll produce a beta a week later, and our first RC a
> week after that, near the end of October.
>
> I'm also thinking of introducing a time-based release cadence to Proton,
> with new releases falling in October, January, April, and July.
>
> Please let me know what you think.

Sounds good to me!


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proton 0.11 alpha

[Robbie Gemmell <ro...@gmail.com>]

On 6 October 2015 at 12:22, Gordon Sim <gs...@redhat.com> wrote:
> On 10/06/2015 11:39 AM, Robbie Gemmell wrote:
>>
>> I'm all for ensuring we do more releases which this would do, so that
>> would be good. I'll admit I'm not a huge fan of the time-based cadance
>> on its own though, perhaps the ideal for me would be a similar maximum
>> bounding time on more features-based releases, plus point releases
>> with fixes as appropriate.
>>
>> To quote myself from a semi related thread some months ago:
>>
>> "I think we tend to be guilty of putting everything in together,
>> resulting in a big release that can then drag on a bit, making it more
>> difficult to respond quickly if the need arises, which in turn makes
>> us want to complete the cycle by including yet more stuff into the
>> release just to avoid it having to wait around for a while until the
>> following release happens."
>
>
> Proton has not had a time-based cadence to-date, yet the situation you
> describe has very much been a feature of that component, so I don't think it
> is the cadence that is the issue there.
>

No it hasnt, its has generally drifted until some point a release
actually happened (for whatever reason). That can be fine if it is
frequent enough, much less so if it isnt (which it often hasn't been).

The time based release should clearly help avoid the 'not frequent
enough' case, however I think the same issues I have in mind generally
apply with the defined time schedule too, only with reduced impact
since the kick off points should be better known in advance. We have
missed many of our other timed-based release dates to some degree for
largely the same reasons. A general cadence is always there, so it
does still have the effect of prompting periodic releases, which is
obviously very good, but I still find most of those releases
frustrating too.

> The most important criteria is that the release plan is clear and open to
> anyone interested.
>
> Personally, I think a time-based approach is a very good and simple way of
> achieving that. The alternative is much more open communication around the
> work targeted for each release, estimates of the time needed and frequent
> updates on status.
>
>

That can certainly be true. While none of that would really be a bad
thing, I'm not suggesting that we would attempt to manage things that
closely, because I don't honestly think it would actually happen if we
did.

Really all I'm thinking of is being a bit more adaptive. If after say
2 months of an expected 3 month time box there was a whole load of
finished work on master, and someone was about to begin ripping things
apart to make 'unrelated major change X', I'd rather we just consider
shipping master then, as theres a whole load of finished work only
likely to be held up by stuff coming later. If someone were to
recognise such a state, perhaps that did the finished work or is about
to start the new major work, they might send an email saying 'hey
folks, would it make sense to release this existing stuff sooner on
its own, then perhaps another release a couple months later with this
new stuff', then we could at least have a discussion about doing it.
Otherwise, what has tended to happen is that the work goes in,
possibly isnt quite happen ready when the time is up, and the release
process then drags on as this becomes clearer and things get
addressed. Doing more point releases would help too in some regards,
less penalty to users waiting for the next release to get fixes to
things that werent quite 100% due to hitting a date they probably
shouldnt have.

If releases are frequent enough or flexible enough that missing them
doesnt impose massive penalty, such as neeeding to wait 3 months for
the next one, there is much less reason for folks to be concerned
about what release their bits actualy go into. The main issue might
then be if certain changes need to go in the same release, e.g
considering a 'fix/break these things together' grouping, which in the
earlier scenario might mean we still decided not to release the
earlier stuff yet.

Robbie

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proton 0.11 alpha

[Gordon Sim <gs...@redhat.com>]

On 10/06/2015 11:39 AM, Robbie Gemmell wrote:
> I'm all for ensuring we do more releases which this would do, so that
> would be good. I'll admit I'm not a huge fan of the time-based cadance
> on its own though, perhaps the ideal for me would be a similar maximum
> bounding time on more features-based releases, plus point releases
> with fixes as appropriate.
>
> To quote myself from a semi related thread some months ago:
>
> "I think we tend to be guilty of putting everything in together,
> resulting in a big release that can then drag on a bit, making it more
> difficult to respond quickly if the need arises, which in turn makes
> us want to complete the cycle by including yet more stuff into the
> release just to avoid it having to wait around for a while until the
> following release happens."

Proton has not had a time-based cadence to-date, yet the situation you 
describe has very much been a feature of that component, so I don't 
think it is the cadence that is the issue there.

The most important criteria is that the release plan is clear and open 
to anyone interested.

Personally, I think a time-based approach is a very good and simple way 
of achieving that. The alternative is much more open communication 
around the work targeted for each release, estimates of the time needed 
and frequent updates on status.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Proton 0.11 alpha

[Robbie Gemmell <ro...@gmail.com>]

On 5 October 2015 at 21:34, Justin Ross <ju...@gmail.com> wrote:
> Hi, folks.  I propose to start work on another Proton release soon.
>
> In order to work out any dist issues (and to get myself familiar with the
> process), I'm going to produce an alpha at the end of next week.
>
> If things go well, I'll produce a beta a week later, and our first RC a
> week after that, near the end of October.
>

Sounds good to me.

I'd like to encourage folks to more fully test the alpha and beta if
they are going to exist, and so would suggest that the first RC
proceeds immediately to vote and we are more agressive in rejecting
further respins, instead doing more point releases and picking up such
fixes as appropriate.

I had fully intended/expected to do a 0.10.1 before now, but didn't
get to it due to unexpected non-code issues of late diverting my
attention. It may be past the time if 0.11 is due this soon and
largely has new components (e.g C++ binding) in it?

> I'm also thinking of introducing a time-based release cadence to Proton,
> with new releases falling in October, January, April, and July.
>

I'm all for ensuring we do more releases which this would do, so that
would be good. I'll admit I'm not a huge fan of the time-based cadance
on its own though, perhaps the ideal for me would be a similar maximum
bounding time on more features-based releases, plus point releases
with fixes as appropriate.

To quote myself from a semi related thread some months ago:

"I think we tend to be guilty of putting everything in together,
resulting in a big release that can then drag on a bit, making it more
difficult to respond quickly if the need arises, which in turn makes
us want to complete the cycle by including yet more stuff into the
release just to avoid it having to wait around for a while until the
following release happens."

> Please let me know what you think.
>
> Thanks!
> Justin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org