I agree on looking at these items, though I think the underlying questions are actually about: - testing (our coverage) - what constitutes a regression when the final RC vote is underway -> the change for QPID-3214 was completed in Aug 2010 I believe, and was present in 0.8
I believe the logic here is complex and will likely represent a significant effort to fix. I'm fairly ambivalent about waiting to fix it or pressing ahead with the 0.10 release. I'm definitely -1 for errata releases, better to have a shorter release cycle and release more frequently. Regards, Marnie On Tue, Apr 19, 2011 at 5:26 PM, Rajith Attapattu <rajit...@gmail.com>wrote: > Based on the comments so far it seems that delaying the 0.10 release > is probably a better idea. > I agree with Carl and Steve that erratas can be time consuming and may > actually be detrimental to our overall goals. > > For now lets hold on to the release a bit and see what needs to be > done to fix QPID-3214 & QPID-3216. > Based on that we can make a call to just release note it and fix it in > 0.12 or whether we can safely fix them for 0.10 > > Thanks again for the input. > > Rajith > > On Tue, Apr 19, 2011 at 12:10 PM, Steve Huston <shus...@riverace.com> > wrote: > > 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 > > > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
