struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
Date Thu, 26 Dec 2002 22:07:26 GMT


On Thu, 26 Dec 2002, Ted Husted wrote:

> Date: Thu, 26 Dec 2002 16:55:34 -0500
> From: Ted Husted <husted@apache.org>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> To: Struts Developers List <struts-dev@jakarta.apache.org>
> 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 <martinc@apache.org> wrote:
>
> >
> >
> >On Wed, 25 Dec 2002, Ted Husted wrote:
> >
> >> 12/24/2002 6:53:29 PM, Martin Cooper <martinc@apache.org>
> 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-
> dev@jakarta.apache.org&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-
> unsubscribe@jakarta.apache.org>
> >> For additional commands, e-mail: <mailto:struts-dev-
> help@jakarta.apache.org>
> >>
> >>
> >
> >
> >--
> >To unsubscribe, e-mail:   <mailto:struts-dev-
> unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail: <mailto:struts-dev-
> help@jakarta.apache.org>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message