I am also -1 because on #2 that's not how I understand the voting process to work. It's cut a version, publish it out as beta for developers to use, vote later on it. I model my thoughts after what I've seen on Tomcat.
-- Paul --- Ted Husted <[EMAIL PROTECTED]> wrote: > On 5/16/06, Don Brown <[EMAIL PROTECTED]> wrote: > > I think the solution is to: > > 1. Make betas publicly available and widely known like our 1.1 betas were > > +1 > > I think the notion that we can't announce and mirrors Betas is a > misunderstanding. We can mirror an announce *any* release, even an > Alpha. > > After distribution as an Alpha or a Beta, we can upgrade the release > quality to GA, if appropriate. When a release series is very mature, > like 1.2.x is now, we might go straight to GA, but that's not > realistic for a new minor series. > > > 2. Do all testing and even the vote _before_ a code freeze and > > subsequent release. I personally won't waste my time doing a release > > if people will only test it after the fact. > > -1 > > I won't cast a quality vote on anything but a tagged and rolled, > downloadable distribution. Many of the problems we've had in the past > (not just this time, but with other series too) appear in the final > product and are not evident in a checkout. > > The nature of the beast is that it takes anywhere from three to five > Betas before we hit a GA release. That's not just Apache Struts, but > all the ASF projects I've ever followed. > > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
