Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)

[Ted Husted]

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)

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]>