Craig's message mentions an "up to the minute" list, which I believe should be a Bugzilla query.
If something comes in just before the freeze, and it's not a true show stopper, we can just make it LATER, which we should be doing anyway. I would just like to get out of the habit of dual maintenance of multiple lists. -Ted. 12/26/2002 3:40:43 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > > >On Wed, 25 Dec 2002, Ted Husted wrote: > >> 12/24/2002 6:53:29 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: >> >The plan doesn't say we're committing to fixing the problem, it >> >says the problem report must be resolved before final release of >> >Struts 1.1. I believe we need to do that, even if we have to mark >> >it LATER because we haven't been able to reproduce it or track it >> >down by the time we're otherwise ready for a final release. >> >> Since we already say that under "Release Criteria", I'd suggest we >> drop the "Bugs to be Addressed" section as redundant and replace >> the link to Bugzilla with one that will produce the list we need >> to address. > >There are a couple of reasons I'm reluctant to do that. > >* The bug list was added at Craig's suggestion on the vote for the 1.1-b1 >release plan. It's based on previous experience with Tomcat releases. See: > >http://archives.apache.org/eyebrowse/ReadMsg?listName=struts- [EMAIL PROTECTED]&msgNo=7086 > >* I believe we need a somewhat fixed target to aim at, rather than a >moving one. If we use a link to Bugzilla rather than a list that we agree >upon, then it would presumably mean that if someone submits a new bug >report at 23:55 on the proposed release date, we are no longer ready for >the release, since the link in the release plan now refers to a non-empty >list of bugs that need to be resolved before the release can happen. > >The use of the STATUS file that Craig introduced before might be a good >compromise between using the list in the release plan and using a link to >Bugzilla. This file would get updated as bugs get fixed, and if someone >believes a new bug also needs to be fixed before release, they can add it >to the file. That commit would, as always, be subject to veto if someone >else disagrees, thus using the usual code voting mechanism to control the >list. > >-- >Martin Cooper > > >> Apparently, this is the Bugzilla link on the Roadmap, >> less the enhancement requests. (Edit the query and select >> everything but.) >> >> http://issues.apache.org/bugzilla/buglist.cgi? >> bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_stat >> us=REOPENED&bug_severity=Blocker&bug_severity=Critical&bug_severit >> y=Major&bug_severity=Normal&bug_severity=Minor&email1 =&emailtype1 >> =substring&emailassigned_to1=1&email2=&emailtype2 >> =substring&emailreporter2=1 >> &bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldt >> o=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=all >> wordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc= >> &bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords >> &field0-0-0=noop&type0-0-0=noop&value0-0-0 >> =&cmdtype=doit&newqueryname=&order=%27Importance%27 >> >> >> -T. >> >> >> >> -- >> To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >> For additional commands, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >> >> > > >-- >To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
