Andrea Aime wrote: > Chris Holmes ha scritto: >> I personally think the full week of QA _before_ a release is overkill. >> The point of putting out an RC is to get QA. We've gotten a bunch of QA >> on RC 1. Put out RC2 as soon as possible, and unless there are true >> major blockers (meaning _major_ regressions) turn it in to 2.0.0. And >> then just be on hand to fix any major thing that went undiscovered and >> do a 2.0.1 as soon as possible. It won't be perfect, but it will be >> _far_ better overall than anything else we've put out. > > Chris, you're a member of the PSC and the testing GSIP has been out > for over a week and received four positive votes. > It was part of your powers to vote with a -1 if you wanted. > I realize that. And if I felt strongly I would vote -1. I'd like to see if it could possibly work. Right now I'm -0 on it. I guess it actually makes a lot more sense to me _after_ a .0 release. Before a .0 release I'd just put out a new RC each time.
> The one week is a compromise between who wanted less and who wanted > more, if we see it does not work we can try out an agreement to > reduce it. The week is mostly there to allow tester to find time > to give it a shot within their already busy schedule, it's not like > we think each tester will hammer it for a week long. > > Testers, speak up: if the window was only 3 days, and it was announced > some time before (one/two weeks) would it be good enough for you? > > The QA is not there to make a perfect product, but to avoid releasing > something with obvious major issues. GS 2.0 RC1 and GS 1.7.5 were > both released with major problems. The process is there to identify > regressions, not to fix any random bug we may find, and try to release > at least stable version that are actually stable (with glitches, but > not crashing and not eating the user configurations). > > What we're trying to avoid is something we've seen in the 1.7.x > series were certain users could not use 1.7.3 due to issue A, > 1.7.4 due to issue B, 1.7.5 due to issue C and had to wait 2 more > months before 1.7.6 was actually out and usable (but still plagued > with a memory leak that would kill it within days, > http://jira.codehaus.org/browse/GEOS-3407) Understood. I think that's great in non RC/beta releases. I just see RC as an indicator for people to test. I'd put out an RC once a week if each one got new issues. Ideally the 'testers' would be the first to jump at an RC and report the issues right away. Each RC would be a freeze, just fixing the regressions reported by testers and other users. > >> I'm not sure how 'the community' makes this decision. It requires >> someone to say 'we're not going to wait for X', which is harder to do >> as a community. Other projects designate a release manager to make >> that call. But please let's make this call. It's been almost 7 weeks >> since any GeoServer release, which is longer than we've gone for >> awhile. And it's been over 11 months since the last .0 release. I >> really do fear for GeoServer if we keep waiting for just 1 more >> thing. Those things can come in later releases. > > Since the roadmapping thing is not moving much due to lack of votes, > tomorrow I'll turn it into a GSIP. One thing that I want to add in the > proposal is the definition of two people, one that is responsible of > keeping up the roadmap until the next release, one that is responsible > to package the release. > Cool. Chris > Cheers > Andrea > > -- Chris Holmes OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
