You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Brett Porter <br...@gmail.com> on 2006/04/26 05:14:32 UTC
closing and reopening jira issues
Hi,
I've noticed that there have been 1 or 2 mails recently on this list
to reopen and close jira issues. Am I correct in assuming this is to
be able to edit the fix version or other details?
If this will be a regular occurrence, I recommend working with the
jira admins to create a custom workflow. We've done that in Maven and
it allows you to edit issues that are closed with appropriate
permissions. It's a big timesaver if used responsibly.
just my $A0.02
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: tablib tests [was Re: closing and reopening jira issues]
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/27/06, James Mitchell <jm...@apache.org> wrote:
> 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 to discourage you at all from adding additional kinds of tests,
but I'm not quite ready to throw out the Cactus tests for Taglib.
Sandbox them, maybe, though. :)
Those tests worked for me in mid-January under Maven 1. (After Laurie
fixed them, IIRC.) I think something in the code reformatting broke
them, but I haven't had a chance to try reverting to various revisions
to find out what happened. (And the Cactus team does plan to finish
the Maven 2 plugin, at which point running the tests will be easier.
I was over there helping with the Cargo integration recently.)
In any case, I'm all for more automated testing, and I'm willing to
help. I know there are Canoo WebTest files for (at least) Mailreader,
somewhere. (Sandbox?) And last night Don looked at the HtmlUnit
tests I've been using to verify that all of the apps will start and
display the default page, so I'll add those under action/integration.
> 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?
Sounds great to me. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
tablib tests [was Re: closing and reopening jira issues]
Posted by James Mitchell <jm...@apache.org>.
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Don Brown <mr...@twdata.org>.
I agree with everything you said, save the RM difficulty level. All I'm saying is the RM should look over the list of
all fixed tickets ensuring everything is in order. Thanks to Wendy, the RM can roll a release in under a hour with most
of that time taking up waiting for Maven to do its thing. She is even working on a way to automatically deploy the
example applications and run rudimentary tests.
I guess I see the RM as the one responsible for the release. It isn't a bad thing and ideally, they will have no
additional work; I certainly didn't have much when I rolled the release last nite.
Don
Ted Husted wrote:
> On 4/27/06, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Ted Husted <te...@gmail.com>.
On 4/27/06, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Don Brown <mr...@twdata.org>.
Leon Rosenberg wrote:
> On 4/27/06, Craig McClanahan <cr...@apache.org> wrote:
>> On 4/26/06, Don Brown <mr...@twdata.org> wrote:
>>> The resolved/closed question is interesting. I guess they could be
>>> resolved, but reviewed and closed by the release manager. Otherwise,
>>> I'd agree that they seem to function the same for open source projects
>>> anyways.
>>
>> In my day job scenario, we have the developers who commit changes switch an
>> issue to "Resolved", and then QE verifies the result and switches it to
>> "Closed". I'd hate to see us stick all of that responsibility solely on a
>> release manager right before a release (doubt we'd ever get a volunteer to
>> do it twice :-), but maybe we could have the release manager declare a
>> moratorium on changes, and then have all the committers take on the task of
>> verifying the issues that have been purported to be fixed?
>>
>
> Here (in our team) the developers switch the issues to DONE (bugzilla)
> and the reporter of the issue (QA or anyone else) is responsible to
> CLOSE the issue and resolve it as fixed (or reopen it, if it's not
> fixed).
> Could it be a possible scenario for struts-issues too? The reporter of
> an issue whould have a natural interest in checking the fix and
> confirming it.
I like that, and if they don't close it by the release, the release manager will close it.
Don
>
> regards
>
>> Craig
>>
>
> Leon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 4/27/06, Craig McClanahan <cr...@apache.org> wrote:
> On 4/26/06, Don Brown <mr...@twdata.org> wrote:
> >
> > The resolved/closed question is interesting. I guess they could be
> > resolved, but reviewed and closed by the release manager. Otherwise,
> > I'd agree that they seem to function the same for open source projects
> > anyways.
>
>
> In my day job scenario, we have the developers who commit changes switch an
> issue to "Resolved", and then QE verifies the result and switches it to
> "Closed". I'd hate to see us stick all of that responsibility solely on a
> release manager right before a release (doubt we'd ever get a volunteer to
> do it twice :-), but maybe we could have the release manager declare a
> moratorium on changes, and then have all the committers take on the task of
> verifying the issues that have been purported to be fixed?
>
Here (in our team) the developers switch the issues to DONE (bugzilla)
and the reporter of the issue (QA or anyone else) is responsible to
CLOSE the issue and resolve it as fixed (or reopen it, if it's not
fixed).
Could it be a possible scenario for struts-issues too? The reporter of
an issue whould have a natural interest in checking the fix and
confirming it.
regards
> Craig
>
Leon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Don Brown <mr...@twdata.org>.
Craig McClanahan wrote:
> In my day job scenario, we have the developers who commit changes
> switch an
> issue to "Resolved", and then QE verifies the result and switches it to
> "Closed". I'd hate to see us stick all of that responsibility solely on a
> release manager right before a release (doubt we'd ever get a volunteer to
> do it twice :-), but maybe we could have the release manager declare a
> moratorium on changes, and then have all the committers take on the task of
> verifying the issues that have been purported to be fixed?
>
I was thinking more along the lines of a quick spot check to make sure
things are in order, but nothing like testing each fix. These two ideas
are not mutually exclusive though. Having developers test fixed tickets
and a release manager as the final gatekeeper would work, although the
other question is if people would actually do that. We have a hard
enough time getting developers to test the final release build for the
vote :)
Don
> Don
>
>
> Craig
>
>
> Brett Porter wrote:
>
>>> We actually eliminated the resolve step since weren't using it
>>> independantly of resolve, however this doesn't affect the other part.
>>>
>>> I'm not exactly sure of the technical details of how we made editing
>>> possible when it was resolved/closed - but I can find out. It doesn't
>>> actually transition to any different steps in between.
>>>
>>> Cheers,
>>> Brett
>>>
>>> On 4/27/06, Don Brown <mr...@twdata.org> wrote:
>>>
>>>
>>>> What does the end workflow look like? Do you just add a transition to
>>>>
>> resolve to the close step?
>>
>>>> Don
>>>>
>>>> Brett Porter wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I've noticed that there have been 1 or 2 mails recently on this list
>>>>> to reopen and close jira issues. Am I correct in assuming this is to
>>>>> be able to edit the fix version or other details?
>>>>>
>>>>> If this will be a regular occurrence, I recommend working with the
>>>>> jira admins to create a custom workflow. We've done that in Maven and
>>>>> it allows you to edit issues that are closed with appropriate
>>>>> permissions. It's a big timesaver if used responsibly.
>>>>>
>>>>> just my $A0.02
>>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Craig McClanahan <cr...@apache.org>.
On 4/26/06, Don Brown <mr...@twdata.org> wrote:
>
> The resolved/closed question is interesting. I guess they could be
> resolved, but reviewed and closed by the release manager. Otherwise,
> I'd agree that they seem to function the same for open source projects
> anyways.
In my day job scenario, we have the developers who commit changes switch an
issue to "Resolved", and then QE verifies the result and switches it to
"Closed". I'd hate to see us stick all of that responsibility solely on a
release manager right before a release (doubt we'd ever get a volunteer to
do it twice :-), but maybe we could have the release manager declare a
moratorium on changes, and then have all the committers take on the task of
verifying the issues that have been purported to be fixed?
Don
Craig
Brett Porter wrote:
> > We actually eliminated the resolve step since weren't using it
> > independantly of resolve, however this doesn't affect the other part.
> >
> > I'm not exactly sure of the technical details of how we made editing
> > possible when it was resolved/closed - but I can find out. It doesn't
> > actually transition to any different steps in between.
> >
> > Cheers,
> > Brett
> >
> > On 4/27/06, Don Brown <mr...@twdata.org> wrote:
> >
> >> What does the end workflow look like? Do you just add a transition to
> resolve to the close step?
> >>
> >> Don
> >>
> >> Brett Porter wrote:
> >>
> >>> Hi,
> >>>
> >>> I've noticed that there have been 1 or 2 mails recently on this list
> >>> to reopen and close jira issues. Am I correct in assuming this is to
> >>> be able to edit the fix version or other details?
> >>>
> >>> If this will be a regular occurrence, I recommend working with the
> >>> jira admins to create a custom workflow. We've done that in Maven and
> >>> it allows you to edit issues that are closed with appropriate
> >>> permissions. It's a big timesaver if used responsibly.
> >>>
> >>> just my $A0.02
> >>>
> >>> Cheers,
> >>> Brett
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: closing and reopening jira issues
Posted by Don Brown <mr...@twdata.org>.
The resolved/closed question is interesting. I guess they could be
resolved, but reviewed and closed by the release manager. Otherwise,
I'd agree that they seem to function the same for open source projects
anyways.
Don
Brett Porter wrote:
> We actually eliminated the resolve step since weren't using it
> independantly of resolve, however this doesn't affect the other part.
>
> I'm not exactly sure of the technical details of how we made editing
> possible when it was resolved/closed - but I can find out. It doesn't
> actually transition to any different steps in between.
>
> Cheers,
> Brett
>
> On 4/27/06, Don Brown <mr...@twdata.org> wrote:
>
>> What does the end workflow look like? Do you just add a transition to resolve to the close step?
>>
>> Don
>>
>> Brett Porter wrote:
>>
>>> Hi,
>>>
>>> I've noticed that there have been 1 or 2 mails recently on this list
>>> to reopen and close jira issues. Am I correct in assuming this is to
>>> be able to edit the fix version or other details?
>>>
>>> If this will be a regular occurrence, I recommend working with the
>>> jira admins to create a custom workflow. We've done that in Maven and
>>> it allows you to edit issues that are closed with appropriate
>>> permissions. It's a big timesaver if used responsibly.
>>>
>>> just my $A0.02
>>>
>>> Cheers,
>>> Brett
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Brett Porter <br...@gmail.com>.
We actually eliminated the resolve step since weren't using it
independantly of resolve, however this doesn't affect the other part.
I'm not exactly sure of the technical details of how we made editing
possible when it was resolved/closed - but I can find out. It doesn't
actually transition to any different steps in between.
Cheers,
Brett
On 4/27/06, Don Brown <mr...@twdata.org> wrote:
> What does the end workflow look like? Do you just add a transition to resolve to the close step?
>
> Don
>
> Brett Porter wrote:
> > Hi,
> >
> > I've noticed that there have been 1 or 2 mails recently on this list
> > to reopen and close jira issues. Am I correct in assuming this is to
> > be able to edit the fix version or other details?
> >
> > If this will be a regular occurrence, I recommend working with the
> > jira admins to create a custom workflow. We've done that in Maven and
> > it allows you to edit issues that are closed with appropriate
> > permissions. It's a big timesaver if used responsibly.
> >
> > just my $A0.02
> >
> > Cheers,
> > Brett
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: closing and reopening jira issues
Posted by Don Brown <mr...@twdata.org>.
What does the end workflow look like? Do you just add a transition to resolve to the close step?
Don
Brett Porter wrote:
> Hi,
>
> I've noticed that there have been 1 or 2 mails recently on this list
> to reopen and close jira issues. Am I correct in assuming this is to
> be able to edit the fix version or other details?
>
> If this will be a regular occurrence, I recommend working with the
> jira admins to create a custom workflow. We've done that in Maven and
> it allows you to edit issues that are closed with appropriate
> permissions. It's a big timesaver if used responsibly.
>
> just my $A0.02
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org