Re: Cleaning up JIRA
Hi guys. There are still issues that affect versions up to 5.3.6 ( https://issues.apache.org/jira/browse/TAP5-2025). Maybe we can bulk close all the issues prior tapestry 5.3 version (Notifying users to upgrade to a newer version and check if the issue still exists) and have a manual one by one look on whats left. Zenios On Tue, Dec 18, 2012 at 10:07 PM, Ulrich Stärk wrote: > That's exactly what I'm trying to avoid. I don't want us to manually go > through the list because I > fear that we'll tend to be rather inclusive and won't let go of the old > stuff. > > If someone wants to pick up an issue, they can just assign it to > themselves and the issue > automatically disappears from the list. > > Uli > > On 18.12.2012 20:44, Howard Lewis Ship wrote: > > We should define some tags that can be used to mark issues that are > either > > likely to be picked up, or likely to be closed. > > > > > > On Tue, Dec 18, 2012 at 11:30 AM, Ulrich Stärk wrote: > > > >> On 18.12.2012 18:29, Kalle Korhonen wrote: > >>> Uli, let's not make this a religious argument. If we all compromise a > bit > >> > >> I'm not making this a religious argument. I simply don't see why we > should > >> delay cleaning the list > >> any longer or put any of our valuable energy in outdated stuff. That's > >> simply not economical. Half > >> of these issues were last updated more than 2 years ago, almost all were > >> updated more than a year > >> ago. The last 5.0 (5.0.19) was released in 2009-12. 5.1.0.7 (last 5.1 > >> release) was done in 2010-01. > >> We are talking about issues affecting 3 year old and even older versions > >> of our software. That > >> simply doesn't make any sense to me. > >> > >>> we'll see that everyone wants the same thing, a smaller open bug count. > >> Can > >>> we just wait a bit for bulk closing anything, and in the meanwhile keep > >> > >> That's exactly what I wrote: > >> > If Robert wants to spend the time on it, I'm all for it. But I really > >> want > to see the list of open > issues significantly reduced in the near future and I believe that the > >> > >> To rephrase: I'm OK with giving everybody a bit time to look at their > >> favorite issues, assign them, > >> update them, etc. But I want us to agree on a deadline when we will just > >> close them. > >> > >> Can we agree on the following: > >> > >> 1. we compile a list of issues that we think can be closed for reasons > of > >> lacking interest, > >> affecting outdated versions, being of low quality, or other reasons > >> 2. we bulk-comment on those issues asking reporters and watchers to > update > >> them with more > >> information by 2013-02-28 > >> 3. on 2013-03-01 we bulk-close those that are still open and haven't > been > >> updated > >> > >> Uli > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: dev-h...@tapestry.apache.org > >> > >> > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: Cleaning up JIRA
That's exactly what I'm trying to avoid. I don't want us to manually go through the list because I fear that we'll tend to be rather inclusive and won't let go of the old stuff. If someone wants to pick up an issue, they can just assign it to themselves and the issue automatically disappears from the list. Uli On 18.12.2012 20:44, Howard Lewis Ship wrote: > We should define some tags that can be used to mark issues that are either > likely to be picked up, or likely to be closed. > > > On Tue, Dec 18, 2012 at 11:30 AM, Ulrich Stärk wrote: > >> On 18.12.2012 18:29, Kalle Korhonen wrote: >>> Uli, let's not make this a religious argument. If we all compromise a bit >> >> I'm not making this a religious argument. I simply don't see why we should >> delay cleaning the list >> any longer or put any of our valuable energy in outdated stuff. That's >> simply not economical. Half >> of these issues were last updated more than 2 years ago, almost all were >> updated more than a year >> ago. The last 5.0 (5.0.19) was released in 2009-12. 5.1.0.7 (last 5.1 >> release) was done in 2010-01. >> We are talking about issues affecting 3 year old and even older versions >> of our software. That >> simply doesn't make any sense to me. >> >>> we'll see that everyone wants the same thing, a smaller open bug count. >> Can >>> we just wait a bit for bulk closing anything, and in the meanwhile keep >> >> That's exactly what I wrote: >> If Robert wants to spend the time on it, I'm all for it. But I really >> want to see the list of open issues significantly reduced in the near future and I believe that the >> >> To rephrase: I'm OK with giving everybody a bit time to look at their >> favorite issues, assign them, >> update them, etc. But I want us to agree on a deadline when we will just >> close them. >> >> Can we agree on the following: >> >> 1. we compile a list of issues that we think can be closed for reasons of >> lacking interest, >> affecting outdated versions, being of low quality, or other reasons >> 2. we bulk-comment on those issues asking reporters and watchers to update >> them with more >> information by 2013-02-28 >> 3. on 2013-03-01 we bulk-close those that are still open and haven't been >> updated >> >> Uli >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Cleaning up JIRA
We should define some tags that can be used to mark issues that are either likely to be picked up, or likely to be closed. On Tue, Dec 18, 2012 at 11:30 AM, Ulrich Stärk wrote: > On 18.12.2012 18:29, Kalle Korhonen wrote: > > Uli, let's not make this a religious argument. If we all compromise a bit > > I'm not making this a religious argument. I simply don't see why we should > delay cleaning the list > any longer or put any of our valuable energy in outdated stuff. That's > simply not economical. Half > of these issues were last updated more than 2 years ago, almost all were > updated more than a year > ago. The last 5.0 (5.0.19) was released in 2009-12. 5.1.0.7 (last 5.1 > release) was done in 2010-01. > We are talking about issues affecting 3 year old and even older versions > of our software. That > simply doesn't make any sense to me. > > > we'll see that everyone wants the same thing, a smaller open bug count. > Can > > we just wait a bit for bulk closing anything, and in the meanwhile keep > > That's exactly what I wrote: > > >> If Robert wants to spend the time on it, I'm all for it. But I really > want > >> to see the list of open > >> issues significantly reduced in the near future and I believe that the > > To rephrase: I'm OK with giving everybody a bit time to look at their > favorite issues, assign them, > update them, etc. But I want us to agree on a deadline when we will just > close them. > > Can we agree on the following: > > 1. we compile a list of issues that we think can be closed for reasons of > lacking interest, > affecting outdated versions, being of low quality, or other reasons > 2. we bulk-comment on those issues asking reporters and watchers to update > them with more > information by 2013-02-28 > 3. on 2013-03-01 we bulk-close those that are still open and haven't been > updated > > Uli > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Cleaning up JIRA
On 18.12.2012 18:29, Kalle Korhonen wrote: > Uli, let's not make this a religious argument. If we all compromise a bit I'm not making this a religious argument. I simply don't see why we should delay cleaning the list any longer or put any of our valuable energy in outdated stuff. That's simply not economical. Half of these issues were last updated more than 2 years ago, almost all were updated more than a year ago. The last 5.0 (5.0.19) was released in 2009-12. 5.1.0.7 (last 5.1 release) was done in 2010-01. We are talking about issues affecting 3 year old and even older versions of our software. That simply doesn't make any sense to me. > we'll see that everyone wants the same thing, a smaller open bug count. Can > we just wait a bit for bulk closing anything, and in the meanwhile keep That's exactly what I wrote: >> If Robert wants to spend the time on it, I'm all for it. But I really want >> to see the list of open >> issues significantly reduced in the near future and I believe that the To rephrase: I'm OK with giving everybody a bit time to look at their favorite issues, assign them, update them, etc. But I want us to agree on a deadline when we will just close them. Can we agree on the following: 1. we compile a list of issues that we think can be closed for reasons of lacking interest, affecting outdated versions, being of low quality, or other reasons 2. we bulk-comment on those issues asking reporters and watchers to update them with more information by 2013-02-28 3. on 2013-03-01 we bulk-close those that are still open and haven't been updated Uli - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Cleaning up JIRA
Agreed. I think that if after owner notification and about a month waiting period, the issue can be closed. On Dec 18, 2012, at 12:29 PM, Kalle Korhonen wrote: > Uli, let's not make this a religious argument. If we all compromise a bit > we'll see that everyone wants the same thing, a smaller open bug count. Can > we just wait a bit for bulk closing anything, and in the meanwhile keep > sending a message that the time to take a look at the open issues is right > now; we'll be bulk closing, say after 5.4. is in beta. I know I have a few > ones I've been scrambling to find some time to work on. > > Kalle > > > On Tue, Dec 18, 2012 at 7:14 AM, Ulrich Stärk wrote: > >> And my objection is to wasting resources on going through every issue and >> in the end still closing >> most of them. >> >> If Robert wants to spend the time on it, I'm all for it. But I really want >> to see the list of open >> issues significantly reduced in the near future and I believe that the >> mose time effective solution >> is simply to close old ones as won't fix. >> >> Uli >> >> On 18.12.2012 12:55, Bob Harner wrote: >>> Uli, my only objection is to bulk closing the issues. >>> On Dec 18, 2012 6:52 AM, "Ulrich Stärk" wrote: >>> Ok, so we keep piling them up because we don't want to hurt people's feelings? Don't you think that people deserve to be told the truth: "Guys, we are sorry, but this stuff is old, we most likely won't look at it ever because we have a lot of other tasks with higher priorities, but if you feel this is still an issue please confirm with a newer version of Tapestry"? Same goes for feature requests. If we really cared we could have implemented those old >> requests by now, but we don't. So let's be honest and tell our users that we might find the ideas interesting but lack time to implement them. Everything else is just lying to ourselves and our users that we will someday - maybe - look at it. So let's be honest and tell them what they know anyway: "Won't fix". Uli On 18.12.2012 12:38, Bob Harner wrote: > Robert Z. has volunteered to prune the list manually. I think we should see > where that gets us. > > Let's not forget that every bug report represents a significant investment > of time by a Tapestry user who earnestly wants to make the framework > better, and we definitely want to encourage that. A few of the bugs are > pure junk, but many are well-described, with good proposed solutions, > patches and, yes, even tests in some cases. > > I know if I were to submit a thoughtful bug report or patch to an open > source project and it got casually rejected by an automated process >> (and I > was told not to reopen it), I would be greatly discouraged from making any > further contributions. > > > > > On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk >> wrote: > >> Folks, there is no sense in hording issues that we know will never be >> addressed and that do nothing >> else but clutter our issue tracker and block our view on the really useful >> ones. Please overcome the >> gatherer in you. Even the best idea won't help us if there is nobody >> interested in implementing it >> and it only contributes to obstrucing our view on important issues. >> Besides, those tickets aren't >> gone. They are simply closed. >> >> Below is a draft of a text that I'm going to attach to the issues that >> will be bulk closed. It makes >> clear that the reporter is free to reopen the issue if it still >> persists >> or he feels strongly about >> it. In case of a feature request they are required to discuss it on >> the >> dev mailing list first. I >> hope that this will increase the chances of having only well >> thought-out >> ideas that are also >> supported by the development community in our tracker. >> >> And I really recommend reading [1]. >> >> Cheers, >> >> Uli >> >> [1] http://www.joelonsoftware.com/items/2012/07/09.html >> >> >> This issue has been closed because it affects an old version of >> Tapestry >> or has no affected version >> number set, and is not currently assigned to any developer. >> >> This ticket will most likely never be resolved or already has been >> resolved as a side-effect of a >> newer version of Tapestry. >> >> >> DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! >> >> >> If you feel that the issue still persists, do the following: >> >> 1. Try again with the most recent version of Apache Tapestry >> >> 2a. If you still find a bug, open a new bug report, specify the exact >> version of Tapestry and those >> of any components you are using, describe exp
Re: Cleaning up JIRA
Uli, let's not make this a religious argument. If we all compromise a bit we'll see that everyone wants the same thing, a smaller open bug count. Can we just wait a bit for bulk closing anything, and in the meanwhile keep sending a message that the time to take a look at the open issues is right now; we'll be bulk closing, say after 5.4. is in beta. I know I have a few ones I've been scrambling to find some time to work on. Kalle On Tue, Dec 18, 2012 at 7:14 AM, Ulrich Stärk wrote: > And my objection is to wasting resources on going through every issue and > in the end still closing > most of them. > > If Robert wants to spend the time on it, I'm all for it. But I really want > to see the list of open > issues significantly reduced in the near future and I believe that the > mose time effective solution > is simply to close old ones as won't fix. > > Uli > > On 18.12.2012 12:55, Bob Harner wrote: > > Uli, my only objection is to bulk closing the issues. > > On Dec 18, 2012 6:52 AM, "Ulrich Stärk" wrote: > > > >> Ok, so we keep piling them up because we don't want to hurt people's > >> feelings? Don't you think that > >> people deserve to be told the truth: "Guys, we are sorry, but this stuff > >> is old, we most likely > >> won't look at it ever because we have a lot of other tasks with higher > >> priorities, but if you feel > >> this is still an issue please confirm with a newer version of Tapestry"? > >> Same goes for feature > >> requests. If we really cared we could have implemented those old > requests > >> by now, but we don't. So > >> let's be honest and tell our users that we might find the ideas > >> interesting but lack time to > >> implement them. > >> > >> Everything else is just lying to ourselves and our users that we will > >> someday - maybe - look at it. > >> > >> So let's be honest and tell them what they know anyway: "Won't fix". > >> > >> Uli > >> > >> On 18.12.2012 12:38, Bob Harner wrote: > >>> Robert Z. has volunteered to prune the list manually. I think we should > >> see > >>> where that gets us. > >>> > >>> Let's not forget that every bug report represents a significant > >> investment > >>> of time by a Tapestry user who earnestly wants to make the framework > >>> better, and we definitely want to encourage that. A few of the bugs are > >>> pure junk, but many are well-described, with good proposed solutions, > >>> patches and, yes, even tests in some cases. > >>> > >>> I know if I were to submit a thoughtful bug report or patch to an open > >>> source project and it got casually rejected by an automated process > (and > >> I > >>> was told not to reopen it), I would be greatly discouraged from making > >> any > >>> further contributions. > >>> > >>> > >>> > >>> > >>> On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk > wrote: > >>> > Folks, there is no sense in hording issues that we know will never be > addressed and that do nothing > else but clutter our issue tracker and block our view on the really > >> useful > ones. Please overcome the > gatherer in you. Even the best idea won't help us if there is nobody > interested in implementing it > and it only contributes to obstrucing our view on important issues. > Besides, those tickets aren't > gone. They are simply closed. > > Below is a draft of a text that I'm going to attach to the issues that > will be bulk closed. It makes > clear that the reporter is free to reopen the issue if it still > persists > or he feels strongly about > it. In case of a feature request they are required to discuss it on > the > dev mailing list first. I > hope that this will increase the chances of having only well > thought-out > ideas that are also > supported by the development community in our tracker. > > And I really recommend reading [1]. > > Cheers, > > Uli > > [1] http://www.joelonsoftware.com/items/2012/07/09.html > > > This issue has been closed because it affects an old version of > Tapestry > or has no affected version > number set, and is not currently assigned to any developer. > > This ticket will most likely never be resolved or already has been > resolved as a side-effect of a > newer version of Tapestry. > > > DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! > > > If you feel that the issue still persists, do the following: > > 1. Try again with the most recent version of Apache Tapestry > > 2a. If you still find a bug, open a new bug report, specify the exact > version of Tapestry and those > of any components you are using, describe expected and observed > >> behavior, > and attach a minimal test > case demonstrating the issue. You will earn additional merit by > >> attaching > an automated test and/or a > fix for the issue. > > 2b. If you
Re: Cleaning up JIRA
And my objection is to wasting resources on going through every issue and in the end still closing most of them. If Robert wants to spend the time on it, I'm all for it. But I really want to see the list of open issues significantly reduced in the near future and I believe that the mose time effective solution is simply to close old ones as won't fix. Uli On 18.12.2012 12:55, Bob Harner wrote: > Uli, my only objection is to bulk closing the issues. > On Dec 18, 2012 6:52 AM, "Ulrich Stärk" wrote: > >> Ok, so we keep piling them up because we don't want to hurt people's >> feelings? Don't you think that >> people deserve to be told the truth: "Guys, we are sorry, but this stuff >> is old, we most likely >> won't look at it ever because we have a lot of other tasks with higher >> priorities, but if you feel >> this is still an issue please confirm with a newer version of Tapestry"? >> Same goes for feature >> requests. If we really cared we could have implemented those old requests >> by now, but we don't. So >> let's be honest and tell our users that we might find the ideas >> interesting but lack time to >> implement them. >> >> Everything else is just lying to ourselves and our users that we will >> someday - maybe - look at it. >> >> So let's be honest and tell them what they know anyway: "Won't fix". >> >> Uli >> >> On 18.12.2012 12:38, Bob Harner wrote: >>> Robert Z. has volunteered to prune the list manually. I think we should >> see >>> where that gets us. >>> >>> Let's not forget that every bug report represents a significant >> investment >>> of time by a Tapestry user who earnestly wants to make the framework >>> better, and we definitely want to encourage that. A few of the bugs are >>> pure junk, but many are well-described, with good proposed solutions, >>> patches and, yes, even tests in some cases. >>> >>> I know if I were to submit a thoughtful bug report or patch to an open >>> source project and it got casually rejected by an automated process (and >> I >>> was told not to reopen it), I would be greatly discouraged from making >> any >>> further contributions. >>> >>> >>> >>> >>> On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk wrote: >>> Folks, there is no sense in hording issues that we know will never be addressed and that do nothing else but clutter our issue tracker and block our view on the really >> useful ones. Please overcome the gatherer in you. Even the best idea won't help us if there is nobody interested in implementing it and it only contributes to obstrucing our view on important issues. Besides, those tickets aren't gone. They are simply closed. Below is a draft of a text that I'm going to attach to the issues that will be bulk closed. It makes clear that the reporter is free to reopen the issue if it still persists or he feels strongly about it. In case of a feature request they are required to discuss it on the dev mailing list first. I hope that this will increase the chances of having only well thought-out ideas that are also supported by the development community in our tracker. And I really recommend reading [1]. Cheers, Uli [1] http://www.joelonsoftware.com/items/2012/07/09.html This issue has been closed because it affects an old version of Tapestry or has no affected version number set, and is not currently assigned to any developer. This ticket will most likely never be resolved or already has been resolved as a side-effect of a newer version of Tapestry. DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! If you feel that the issue still persists, do the following: 1. Try again with the most recent version of Apache Tapestry 2a. If you still find a bug, open a new bug report, specify the exact version of Tapestry and those of any components you are using, describe expected and observed >> behavior, and attach a minimal test case demonstrating the issue. You will earn additional merit by >> attaching an automated test and/or a fix for the issue. 2b. If you want to request a new feature, you are expected to discuss it with the Tapestry developer community on the dev@tapestry.apache.org mailing list first. Include a link to the discussion in the mail archives in your ticket. If you don't, chances are that your ticket will be closed right away. On 18.12.2012 03:33, Robert Zeigler wrote: > I think I can find some time over the course of this week to go through the list of tickets. > > Robert > > On Dec 17, 2012, at 12/178:31 PM , Howard Lewis Ship wrote: > >> Well, we need some plan to tame the list. It's so cluttered that its hard >> to find important things to work on. There's lots of duplicates
Re: Cleaning up JIRA
This is not directly related, but: I would love to help by submitting patches (at least for my bug report: https://issues.apache.org/jira/browse/TAP5-1941), but it's really hard to get tapestry running from source in eclipse (and i work with eclipse and java based projects every day). I will open another thread with my experience in trying to get the current tapestry head running in my dev environment. If one is volunteering to clean up Jira by hand i would think this is the best idea. Antother approach would be to: 1) put all tickets to status "On Hold" and add a comment, that the bug reporter is asked to confirm, that the bug/feature request is still valid. 2) After 4 weeks close the tickets with status "on hold" with resolution "wont fix" felix On Tue, Dec 18, 2012 at 12:55 PM, Bob Harner wrote: > Uli, my only objection is to bulk closing the issues. > On Dec 18, 2012 6:52 AM, "Ulrich Stärk" wrote: > > > Ok, so we keep piling them up because we don't want to hurt people's > > feelings? Don't you think that > > people deserve to be told the truth: "Guys, we are sorry, but this stuff > > is old, we most likely > > won't look at it ever because we have a lot of other tasks with higher > > priorities, but if you feel > > this is still an issue please confirm with a newer version of Tapestry"? > > Same goes for feature > > requests. If we really cared we could have implemented those old requests > > by now, but we don't. So > > let's be honest and tell our users that we might find the ideas > > interesting but lack time to > > implement them. > > > > Everything else is just lying to ourselves and our users that we will > > someday - maybe - look at it. > > > > So let's be honest and tell them what they know anyway: "Won't fix". > > > > Uli > > > > On 18.12.2012 12:38, Bob Harner wrote: > > > Robert Z. has volunteered to prune the list manually. I think we should > > see > > > where that gets us. > > > > > > Let's not forget that every bug report represents a significant > > investment > > > of time by a Tapestry user who earnestly wants to make the framework > > > better, and we definitely want to encourage that. A few of the bugs are > > > pure junk, but many are well-described, with good proposed solutions, > > > patches and, yes, even tests in some cases. > > > > > > I know if I were to submit a thoughtful bug report or patch to an open > > > source project and it got casually rejected by an automated process > (and > > I > > > was told not to reopen it), I would be greatly discouraged from making > > any > > > further contributions. > > > > > > > > > > > > > > > On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk > wrote: > > > > > >> Folks, there is no sense in hording issues that we know will never be > > >> addressed and that do nothing > > >> else but clutter our issue tracker and block our view on the really > > useful > > >> ones. Please overcome the > > >> gatherer in you. Even the best idea won't help us if there is nobody > > >> interested in implementing it > > >> and it only contributes to obstrucing our view on important issues. > > >> Besides, those tickets aren't > > >> gone. They are simply closed. > > >> > > >> Below is a draft of a text that I'm going to attach to the issues that > > >> will be bulk closed. It makes > > >> clear that the reporter is free to reopen the issue if it still > persists > > >> or he feels strongly about > > >> it. In case of a feature request they are required to discuss it on > the > > >> dev mailing list first. I > > >> hope that this will increase the chances of having only well > thought-out > > >> ideas that are also > > >> supported by the development community in our tracker. > > >> > > >> And I really recommend reading [1]. > > >> > > >> Cheers, > > >> > > >> Uli > > >> > > >> [1] http://www.joelonsoftware.com/items/2012/07/09.html > > >> > > >> > > >> This issue has been closed because it affects an old version of > Tapestry > > >> or has no affected version > > >> number set, and is not currently assigned to any developer. > > >> > > >> This ticket will most likely never be resolved or already has been > > >> resolved as a side-effect of a > > >> newer version of Tapestry. > > >> > > >> > > >> DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! > > >> > > >> > > >> If you feel that the issue still persists, do the following: > > >> > > >> 1. Try again with the most recent version of Apache Tapestry > > >> > > >> 2a. If you still find a bug, open a new bug report, specify the exact > > >> version of Tapestry and those > > >> of any components you are using, describe expected and observed > > behavior, > > >> and attach a minimal test > > >> case demonstrating the issue. You will earn additional merit by > > attaching > > >> an automated test and/or a > > >> fix for the issue. > > >> > > >> 2b. If you want to request a new feature, you are expected to discuss > it > > >> with the Tapestry developer > > >> community on the dev@tapes
Re: Cleaning up JIRA
Uli, my only objection is to bulk closing the issues. On Dec 18, 2012 6:52 AM, "Ulrich Stärk" wrote: > Ok, so we keep piling them up because we don't want to hurt people's > feelings? Don't you think that > people deserve to be told the truth: "Guys, we are sorry, but this stuff > is old, we most likely > won't look at it ever because we have a lot of other tasks with higher > priorities, but if you feel > this is still an issue please confirm with a newer version of Tapestry"? > Same goes for feature > requests. If we really cared we could have implemented those old requests > by now, but we don't. So > let's be honest and tell our users that we might find the ideas > interesting but lack time to > implement them. > > Everything else is just lying to ourselves and our users that we will > someday - maybe - look at it. > > So let's be honest and tell them what they know anyway: "Won't fix". > > Uli > > On 18.12.2012 12:38, Bob Harner wrote: > > Robert Z. has volunteered to prune the list manually. I think we should > see > > where that gets us. > > > > Let's not forget that every bug report represents a significant > investment > > of time by a Tapestry user who earnestly wants to make the framework > > better, and we definitely want to encourage that. A few of the bugs are > > pure junk, but many are well-described, with good proposed solutions, > > patches and, yes, even tests in some cases. > > > > I know if I were to submit a thoughtful bug report or patch to an open > > source project and it got casually rejected by an automated process (and > I > > was told not to reopen it), I would be greatly discouraged from making > any > > further contributions. > > > > > > > > > > On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk wrote: > > > >> Folks, there is no sense in hording issues that we know will never be > >> addressed and that do nothing > >> else but clutter our issue tracker and block our view on the really > useful > >> ones. Please overcome the > >> gatherer in you. Even the best idea won't help us if there is nobody > >> interested in implementing it > >> and it only contributes to obstrucing our view on important issues. > >> Besides, those tickets aren't > >> gone. They are simply closed. > >> > >> Below is a draft of a text that I'm going to attach to the issues that > >> will be bulk closed. It makes > >> clear that the reporter is free to reopen the issue if it still persists > >> or he feels strongly about > >> it. In case of a feature request they are required to discuss it on the > >> dev mailing list first. I > >> hope that this will increase the chances of having only well thought-out > >> ideas that are also > >> supported by the development community in our tracker. > >> > >> And I really recommend reading [1]. > >> > >> Cheers, > >> > >> Uli > >> > >> [1] http://www.joelonsoftware.com/items/2012/07/09.html > >> > >> > >> This issue has been closed because it affects an old version of Tapestry > >> or has no affected version > >> number set, and is not currently assigned to any developer. > >> > >> This ticket will most likely never be resolved or already has been > >> resolved as a side-effect of a > >> newer version of Tapestry. > >> > >> > >> DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! > >> > >> > >> If you feel that the issue still persists, do the following: > >> > >> 1. Try again with the most recent version of Apache Tapestry > >> > >> 2a. If you still find a bug, open a new bug report, specify the exact > >> version of Tapestry and those > >> of any components you are using, describe expected and observed > behavior, > >> and attach a minimal test > >> case demonstrating the issue. You will earn additional merit by > attaching > >> an automated test and/or a > >> fix for the issue. > >> > >> 2b. If you want to request a new feature, you are expected to discuss it > >> with the Tapestry developer > >> community on the dev@tapestry.apache.org mailing list first. Include a > >> link to the discussion in the > >> mail archives in your ticket. If you don't, chances are that your ticket > >> will be closed right away. > >> > >> > >> On 18.12.2012 03:33, Robert Zeigler wrote: > >>> I think I can find some time over the course of this week to go through > >> the list of tickets. > >>> > >>> Robert > >>> > >>> On Dec 17, 2012, at 12/178:31 PM , Howard Lewis Ship wrote: > >>> > Well, we need some plan to tame the list. It's so cluttered that its > >> hard > to find important things to work on. There's lots of duplicates, and > >> lots > of things that I think can be closed as lacking sufficient detail to > proceed. > > This is also one of those areas that can be addressed by someone who > >> can't > take on the commitment right now to do some serious lifting on the > code > base. Volunteers welcome! > > > On Mon, Dec 17, 2012 at 5:33 PM, Bob Harner > >> wrote: > > > I'd be more cautious. Some o
Re: Cleaning up JIRA
Ok, so we keep piling them up because we don't want to hurt people's feelings? Don't you think that people deserve to be told the truth: "Guys, we are sorry, but this stuff is old, we most likely won't look at it ever because we have a lot of other tasks with higher priorities, but if you feel this is still an issue please confirm with a newer version of Tapestry"? Same goes for feature requests. If we really cared we could have implemented those old requests by now, but we don't. So let's be honest and tell our users that we might find the ideas interesting but lack time to implement them. Everything else is just lying to ourselves and our users that we will someday - maybe - look at it. So let's be honest and tell them what they know anyway: "Won't fix". Uli On 18.12.2012 12:38, Bob Harner wrote: > Robert Z. has volunteered to prune the list manually. I think we should see > where that gets us. > > Let's not forget that every bug report represents a significant investment > of time by a Tapestry user who earnestly wants to make the framework > better, and we definitely want to encourage that. A few of the bugs are > pure junk, but many are well-described, with good proposed solutions, > patches and, yes, even tests in some cases. > > I know if I were to submit a thoughtful bug report or patch to an open > source project and it got casually rejected by an automated process (and I > was told not to reopen it), I would be greatly discouraged from making any > further contributions. > > > > > On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk wrote: > >> Folks, there is no sense in hording issues that we know will never be >> addressed and that do nothing >> else but clutter our issue tracker and block our view on the really useful >> ones. Please overcome the >> gatherer in you. Even the best idea won't help us if there is nobody >> interested in implementing it >> and it only contributes to obstrucing our view on important issues. >> Besides, those tickets aren't >> gone. They are simply closed. >> >> Below is a draft of a text that I'm going to attach to the issues that >> will be bulk closed. It makes >> clear that the reporter is free to reopen the issue if it still persists >> or he feels strongly about >> it. In case of a feature request they are required to discuss it on the >> dev mailing list first. I >> hope that this will increase the chances of having only well thought-out >> ideas that are also >> supported by the development community in our tracker. >> >> And I really recommend reading [1]. >> >> Cheers, >> >> Uli >> >> [1] http://www.joelonsoftware.com/items/2012/07/09.html >> >> >> This issue has been closed because it affects an old version of Tapestry >> or has no affected version >> number set, and is not currently assigned to any developer. >> >> This ticket will most likely never be resolved or already has been >> resolved as a side-effect of a >> newer version of Tapestry. >> >> >> DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! >> >> >> If you feel that the issue still persists, do the following: >> >> 1. Try again with the most recent version of Apache Tapestry >> >> 2a. If you still find a bug, open a new bug report, specify the exact >> version of Tapestry and those >> of any components you are using, describe expected and observed behavior, >> and attach a minimal test >> case demonstrating the issue. You will earn additional merit by attaching >> an automated test and/or a >> fix for the issue. >> >> 2b. If you want to request a new feature, you are expected to discuss it >> with the Tapestry developer >> community on the dev@tapestry.apache.org mailing list first. Include a >> link to the discussion in the >> mail archives in your ticket. If you don't, chances are that your ticket >> will be closed right away. >> >> >> On 18.12.2012 03:33, Robert Zeigler wrote: >>> I think I can find some time over the course of this week to go through >> the list of tickets. >>> >>> Robert >>> >>> On Dec 17, 2012, at 12/178:31 PM , Howard Lewis Ship wrote: >>> Well, we need some plan to tame the list. It's so cluttered that its >> hard to find important things to work on. There's lots of duplicates, and >> lots of things that I think can be closed as lacking sufficient detail to proceed. This is also one of those areas that can be addressed by someone who >> can't take on the commitment right now to do some serious lifting on the code base. Volunteers welcome! On Mon, Dec 17, 2012 at 5:33 PM, Bob Harner >> wrote: > I'd be more cautious. Some of the open issues contain good ideas that > simply lack an interested committer. I agree that most should be >> closed, > but a blind bulk action seems unwise. > On Dec 17, 2012 1:20 PM, "Howard Lewis Ship" wrote: > >> +1 >> >> I think we can get away with this approach ; so much it no longer > relevant >> in 5.4. >>
Re: Cleaning up JIRA
Robert Z. has volunteered to prune the list manually. I think we should see where that gets us. Let's not forget that every bug report represents a significant investment of time by a Tapestry user who earnestly wants to make the framework better, and we definitely want to encourage that. A few of the bugs are pure junk, but many are well-described, with good proposed solutions, patches and, yes, even tests in some cases. I know if I were to submit a thoughtful bug report or patch to an open source project and it got casually rejected by an automated process (and I was told not to reopen it), I would be greatly discouraged from making any further contributions. On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk wrote: > Folks, there is no sense in hording issues that we know will never be > addressed and that do nothing > else but clutter our issue tracker and block our view on the really useful > ones. Please overcome the > gatherer in you. Even the best idea won't help us if there is nobody > interested in implementing it > and it only contributes to obstrucing our view on important issues. > Besides, those tickets aren't > gone. They are simply closed. > > Below is a draft of a text that I'm going to attach to the issues that > will be bulk closed. It makes > clear that the reporter is free to reopen the issue if it still persists > or he feels strongly about > it. In case of a feature request they are required to discuss it on the > dev mailing list first. I > hope that this will increase the chances of having only well thought-out > ideas that are also > supported by the development community in our tracker. > > And I really recommend reading [1]. > > Cheers, > > Uli > > [1] http://www.joelonsoftware.com/items/2012/07/09.html > > > This issue has been closed because it affects an old version of Tapestry > or has no affected version > number set, and is not currently assigned to any developer. > > This ticket will most likely never be resolved or already has been > resolved as a side-effect of a > newer version of Tapestry. > > > DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! > > > If you feel that the issue still persists, do the following: > > 1. Try again with the most recent version of Apache Tapestry > > 2a. If you still find a bug, open a new bug report, specify the exact > version of Tapestry and those > of any components you are using, describe expected and observed behavior, > and attach a minimal test > case demonstrating the issue. You will earn additional merit by attaching > an automated test and/or a > fix for the issue. > > 2b. If you want to request a new feature, you are expected to discuss it > with the Tapestry developer > community on the dev@tapestry.apache.org mailing list first. Include a > link to the discussion in the > mail archives in your ticket. If you don't, chances are that your ticket > will be closed right away. > > > On 18.12.2012 03:33, Robert Zeigler wrote: > > I think I can find some time over the course of this week to go through > the list of tickets. > > > > Robert > > > > On Dec 17, 2012, at 12/178:31 PM , Howard Lewis Ship wrote: > > > >> Well, we need some plan to tame the list. It's so cluttered that its > hard > >> to find important things to work on. There's lots of duplicates, and > lots > >> of things that I think can be closed as lacking sufficient detail to > >> proceed. > >> > >> This is also one of those areas that can be addressed by someone who > can't > >> take on the commitment right now to do some serious lifting on the code > >> base. Volunteers welcome! > >> > >> > >> On Mon, Dec 17, 2012 at 5:33 PM, Bob Harner > wrote: > >> > >>> I'd be more cautious. Some of the open issues contain good ideas that > >>> simply lack an interested committer. I agree that most should be > closed, > >>> but a blind bulk action seems unwise. > >>> On Dec 17, 2012 1:20 PM, "Howard Lewis Ship" wrote: > >>> > +1 > > I think we can get away with this approach ; so much it no longer > >>> relevant > in 5.4. > > > On Mon, Dec 17, 2012 at 6:05 AM, Massimo Lusetti > wrote: > > > On Mon, Dec 17, 2012 at 2:42 PM, Ulrich Stärk > >>> wrote: > > > > > >> I am inclined to bulk close these with a message that the reporter > is > > free > >> to check if the issue > >> still persists with a more recent version of the framework. > >> > >> Thoughts? > >> > > > > > > I do agree, totally. Plus thanks for taking care. > > > > -- > > Massimo > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > >>> > >> > >> > >> > >> -- > >> Howard M. Lewis Ship > >> > >> Creator of Apache
Re: Cleaning up JIRA
Folks, there is no sense in hording issues that we know will never be addressed and that do nothing else but clutter our issue tracker and block our view on the really useful ones. Please overcome the gatherer in you. Even the best idea won't help us if there is nobody interested in implementing it and it only contributes to obstrucing our view on important issues. Besides, those tickets aren't gone. They are simply closed. Below is a draft of a text that I'm going to attach to the issues that will be bulk closed. It makes clear that the reporter is free to reopen the issue if it still persists or he feels strongly about it. In case of a feature request they are required to discuss it on the dev mailing list first. I hope that this will increase the chances of having only well thought-out ideas that are also supported by the development community in our tracker. And I really recommend reading [1]. Cheers, Uli [1] http://www.joelonsoftware.com/items/2012/07/09.html This issue has been closed because it affects an old version of Tapestry or has no affected version number set, and is not currently assigned to any developer. This ticket will most likely never be resolved or already has been resolved as a side-effect of a newer version of Tapestry. DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! If you feel that the issue still persists, do the following: 1. Try again with the most recent version of Apache Tapestry 2a. If you still find a bug, open a new bug report, specify the exact version of Tapestry and those of any components you are using, describe expected and observed behavior, and attach a minimal test case demonstrating the issue. You will earn additional merit by attaching an automated test and/or a fix for the issue. 2b. If you want to request a new feature, you are expected to discuss it with the Tapestry developer community on the dev@tapestry.apache.org mailing list first. Include a link to the discussion in the mail archives in your ticket. If you don't, chances are that your ticket will be closed right away. On 18.12.2012 03:33, Robert Zeigler wrote: > I think I can find some time over the course of this week to go through the > list of tickets. > > Robert > > On Dec 17, 2012, at 12/178:31 PM , Howard Lewis Ship wrote: > >> Well, we need some plan to tame the list. It's so cluttered that its hard >> to find important things to work on. There's lots of duplicates, and lots >> of things that I think can be closed as lacking sufficient detail to >> proceed. >> >> This is also one of those areas that can be addressed by someone who can't >> take on the commitment right now to do some serious lifting on the code >> base. Volunteers welcome! >> >> >> On Mon, Dec 17, 2012 at 5:33 PM, Bob Harner wrote: >> >>> I'd be more cautious. Some of the open issues contain good ideas that >>> simply lack an interested committer. I agree that most should be closed, >>> but a blind bulk action seems unwise. >>> On Dec 17, 2012 1:20 PM, "Howard Lewis Ship" wrote: >>> +1 I think we can get away with this approach ; so much it no longer >>> relevant in 5.4. On Mon, Dec 17, 2012 at 6:05 AM, Massimo Lusetti wrote: > On Mon, Dec 17, 2012 at 2:42 PM, Ulrich Stärk >>> wrote: > > >> I am inclined to bulk close these with a message that the reporter is > free >> to check if the issue >> still persists with a more recent version of the framework. >> >> Thoughts? >> > > > I do agree, totally. Plus thanks for taking care. > > -- > Massimo > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Cleaning up JIRA
I think I can find some time over the course of this week to go through the list of tickets. Robert On Dec 17, 2012, at 12/178:31 PM , Howard Lewis Ship wrote: > Well, we need some plan to tame the list. It's so cluttered that its hard > to find important things to work on. There's lots of duplicates, and lots > of things that I think can be closed as lacking sufficient detail to > proceed. > > This is also one of those areas that can be addressed by someone who can't > take on the commitment right now to do some serious lifting on the code > base. Volunteers welcome! > > > On Mon, Dec 17, 2012 at 5:33 PM, Bob Harner wrote: > >> I'd be more cautious. Some of the open issues contain good ideas that >> simply lack an interested committer. I agree that most should be closed, >> but a blind bulk action seems unwise. >> On Dec 17, 2012 1:20 PM, "Howard Lewis Ship" wrote: >> >>> +1 >>> >>> I think we can get away with this approach ; so much it no longer >> relevant >>> in 5.4. >>> >>> >>> On Mon, Dec 17, 2012 at 6:05 AM, Massimo Lusetti >>> wrote: >>> On Mon, Dec 17, 2012 at 2:42 PM, Ulrich Stärk >> wrote: > I am inclined to bulk close these with a message that the reporter is free > to check if the issue > still persists with a more recent version of the framework. > > Thoughts? > I do agree, totally. Plus thanks for taking care. -- Massimo >>> >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator of Apache Tapestry >>> >>> The source for Tapestry training, mentoring and support. Contact me to >>> learn how I can get you up and productive in Tapestry fast! >>> >>> (971) 678-5210 >>> http://howardlewisship.com >>> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Cleaning up JIRA
Well, we need some plan to tame the list. It's so cluttered that its hard to find important things to work on. There's lots of duplicates, and lots of things that I think can be closed as lacking sufficient detail to proceed. This is also one of those areas that can be addressed by someone who can't take on the commitment right now to do some serious lifting on the code base. Volunteers welcome! On Mon, Dec 17, 2012 at 5:33 PM, Bob Harner wrote: > I'd be more cautious. Some of the open issues contain good ideas that > simply lack an interested committer. I agree that most should be closed, > but a blind bulk action seems unwise. > On Dec 17, 2012 1:20 PM, "Howard Lewis Ship" wrote: > > > +1 > > > > I think we can get away with this approach ; so much it no longer > relevant > > in 5.4. > > > > > > On Mon, Dec 17, 2012 at 6:05 AM, Massimo Lusetti > > wrote: > > > > > On Mon, Dec 17, 2012 at 2:42 PM, Ulrich Stärk > wrote: > > > > > > > > > > I am inclined to bulk close these with a message that the reporter is > > > free > > > > to check if the issue > > > > still persists with a more recent version of the framework. > > > > > > > > Thoughts? > > > > > > > > > > > > > I do agree, totally. Plus thanks for taking care. > > > > > > -- > > > Massimo > > > > > > > > > > > -- > > Howard M. Lewis Ship > > > > Creator of Apache Tapestry > > > > The source for Tapestry training, mentoring and support. Contact me to > > learn how I can get you up and productive in Tapestry fast! > > > > (971) 678-5210 > > http://howardlewisship.com > > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Cleaning up JIRA
I'd be more cautious. Some of the open issues contain good ideas that simply lack an interested committer. I agree that most should be closed, but a blind bulk action seems unwise. On Dec 17, 2012 1:20 PM, "Howard Lewis Ship" wrote: > +1 > > I think we can get away with this approach ; so much it no longer relevant > in 5.4. > > > On Mon, Dec 17, 2012 at 6:05 AM, Massimo Lusetti > wrote: > > > On Mon, Dec 17, 2012 at 2:42 PM, Ulrich Stärk wrote: > > > > > > > I am inclined to bulk close these with a message that the reporter is > > free > > > to check if the issue > > > still persists with a more recent version of the framework. > > > > > > Thoughts? > > > > > > > > > I do agree, totally. Plus thanks for taking care. > > > > -- > > Massimo > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com >
Re: Cleaning up JIRA
+1 I think we can get away with this approach ; so much it no longer relevant in 5.4. On Mon, Dec 17, 2012 at 6:05 AM, Massimo Lusetti wrote: > On Mon, Dec 17, 2012 at 2:42 PM, Ulrich Stärk wrote: > > > > I am inclined to bulk close these with a message that the reporter is > free > > to check if the issue > > still persists with a more recent version of the framework. > > > > Thoughts? > > > > > I do agree, totally. Plus thanks for taking care. > > -- > Massimo > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Cleaning up JIRA
On Mon, Dec 17, 2012 at 2:42 PM, Ulrich Stärk wrote: > I am inclined to bulk close these with a message that the reporter is free > to check if the issue > still persists with a more recent version of the framework. > > Thoughts? > I do agree, totally. Plus thanks for taking care. -- Massimo
Cleaning up JIRA
Reading [1] a while back made me think of the status of our own bug database. According to [2] we have 114 open, unassigned bugs in our tracker for Tapestry 5.1 and 5.0 and even 172 when I include those where no version number has been specified. Those bugs are unlikely to get resolved, many of them may even be fixed by changes we did for later versions of Tapestry. I am inclined to bulk close these with a message that the reporter is free to check if the issue still persists with a more recent version of the framework. Thoughts? Uli [1] http://www.joelonsoftware.com/items/2012/07/09.html [2] http://s.apache.org/5bp - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
