On Thu, 26 Dec 2002, Ted Husted wrote:
> Ok, I'll update the Roadmap and the B3 plan with the appropriate > queries, and add a box next to the bugs we are swatting to indicate > their status. This will at least make the static list easier to maintain > =:0) I just updated the site with your updated release plan. Given that the plan has changed from what people voted on, do we need to ((re-)re-)vote on the updated release plan? <sigh/> I hope not, but I fear so. FYI, we had 9 +1/+0 responses and no -1/-0 responses, so 9 committers responding out of 14 currently listed. -- Martin Cooper > > Just finished setting a bunch of new equipment, and I'm quite ready to > get back to work now =:0) > > -Ted. > > Craig R. McClanahan wrote: > > > > On Thu, 26 Dec 2002, Ted Husted wrote: > > > > > >>Date: Thu, 26 Dec 2002 16:55:34 -0500 > >>From: Ted Husted <[EMAIL PROTECTED]> > >>Reply-To: Struts Developers List <[EMAIL PROTECTED]> > >>To: Struts Developers List <[EMAIL PROTECTED]> > >>Subject: Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised) > >> > >>Craig's message mentions an "up to the minute" list, which I > >>believe should be a Bugzilla query. > > > > > > I think this is definitely a useful query to have available, but I'm > > somewhat agreeing with Martin that a dynamic query doesn't really > > represent an agreed-upon target for a beta release (1.1) or a milestone > > release (1.2+). I believe that it is useful to have some measure of > > agreement on which subset of the current Bugzilla entries must be > > handled. Leaving the list dynamic means that it will essentially never be > > completed, and that a release will keep getting deferred until "a few more > > bugs" get addressed - which sounds suspiciously like one of the things > > that has delayed beta 3 :-). > > > > > >>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. > > > > > > If we want to get more aggressive about using LATER, the "Target > > Milestone" field in Bugzilla is available for identifying *which* future > > release we think a particular bug report will be resolved in. This will > > be particularly useful in planning work for 1.2.x releases (which > > shouldn't necessarily need to be complete clean sweeps of all the > > outstanding bugs, if we follow the model used for the HTTPD server and > > Tomcat). > > > > > >>I would just like to get out of the habit of dual maintenance of > >>multiple lists. > >> > >>-Ted. > >> > > > > > > Craig > > > > PS: I'm looking at the "convert to commons-resources" issue that we've > > talked about, but not yet done. Among other things, this needs to be done > > (if we're going to) before dealing with 11932. I'm also planning on > > dealing with that one. > > > > > >>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]> > >> > >> > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
