Speaking of taglib tests......Ted, I was chatting with Don yesterday
and I mentioned an idea that someone had brought up a while back, and
so I wanted to float it by you.
Do you remember the discussions about the taglib tests where it was
proposed (sorry, don't remember who) that we use the taglib exercise
web app both as a helpful tutorial and also as a way of testing?
(reuse is always a good thing;)
With the move to Maven, the taglib tests were pretty much broken and
neglected. They were not neglected due to a lack of interest, but
more for technical reasons (translated -- I didn't know how to force
Maven to do what I wanted).
So, now here we are with Maven 2, and cactus testing doesn't seem to
be any easier that with Maven 1 and so I am wondering if it isn't
worth taking a look at that idea again. I'd be willing (as I was
back when I wrote the 1,000s of taglib tests) to do all the work on
this.
Not sure which approach would be best, maybe I'll put together a
proof of concept and send it around for comments.
What do you think?
--
James Mitchell
On Apr 27, 2006, at 1:18 PM, Ted Husted wrote:
On 4/27/06, Don Brown <[EMAIL PROTECTED]> wrote:
I like that, and if they don't close it by the release, the
release manager will close it.
I don't understand why we should set this up so every ticket has to be
closed twice. The tickets are already subject to peer-review by the
PMC and all the subscribers to dev@ (or issues@). We have nightly
builds going out every day that reflect the changes made by the
tickets.
If the problem is fixed, then the release testing should prove that it
is fixed. I don't believe that we should be turing the release manager
into some type of clerical assistant or gatekeeper for the rest of us.
If the RM wants to review the tickets that have been closed since the
last relesae, that's fine. But I would suggest that we not try to dump
any additional responsibility on this role. It's a hard enough job as
it is.
My suggestion would be that whoever applies the patch should also
supply a test that proves the issue is resolved, and then closes the
ticket as fixed, until shown otherwise. It doesn't have to be a fancy
test. In the case of a taglib, it could just be a use case in the
taglib exercise application.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
