Hi Rajith, > Since we are striving hard to get into a habit of doing > quarterly releases, we will at some point need to make some > *hard" decisions in order to stick to our timelines. > Therefore I think it's important we discuss how we make some > of those decisions.
Good idea - thanks for bringing it up. > A good example is QPID-3214 & QPID-3216 which are fairly > serious regressions but perhaps not blockers in the current > scheme of things. If we do not have another release coming in > 2 months, I would updated their status as "blockers" and > insist that we fix them. But if we do that for this release > our dates would slip by another 2 weeks or so. And that may > end up causing us to miss our goal of doing 4 release this > year. I think as a project it's far more important for us to > hit that goal compared to these two issues missing the 0.10 release. (Devil's advocate...) why is it so important to do 4 releases per year? Would it really hurt to bump 0.10 out and include these fixes? > On the hand these issues can cause problems for our users, > therefore we should also look at possible ways of fixing them > between two major releases. One way of doing this is to make > an errata release between two major releases. Again the > questions would be, > > 1. Do we have enough time and resources to do this kind of > thing ? 2. Will the errata release eat into our next release > cycle ? 3. What if the next release gets delayed ? is that > fair from a users pov ? > > I'd like to hear some thoughts about this from the community. > My personal preference is to do an errata release for > QPID-3214 & QPID-3216 (and any other serious issues like > that). What do you guys think ? I tend to view errata/hotfix as services that downstream support providers handle. You can use up a lot of time and effort going down that road. If QPID-3214 and 3216 are serious issues I would prefer to hold 0.10 for the fixes. The word "deadlock" in the jira subject seems serious, but I'm wondering how likely it is a user will hit it if it hasn't been found before. -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
