Hmm...we definately need to look at automating this stuff - way too much manual
effort. What about writing a little webapp to manage this info?
Regarding connecting commits and bugs, if we were consistent how we referred to
bugs in our commit messages, we could perodically run 'svn log' then parse it
for changesets and bugs. I could add this to my roadmap app.
Bottom line is we need a more automated and consistent process. Having all
these bits of information everywhere that have to be manually updated just isn't
going to work when all these Struts subprojects start taking lives of their own.
Don
Hubert Rabago wrote:
Ted proposed before that we collect them into a "wish list" type of
page on the wiki. I don't know if it still makes sense now if we'll
be adopting WW anyway. If it does, though, we could start with
http://issues.apache.org/bugzilla/show_bug.cgi?id=5739, maybe devote
one section (or page) to it, to keep track of specific instances that
need attention, and get them checked off one by one.
Hubert
On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote:
Personally, I agree, although I know there are those that see them still as a
valuable source of ideas. By emphasizing Milestones, though, they will fade
into the background.
I'd be in favor of a "Probably Never" resolution though :)
Don
Niall Pemberton wrote:
On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote:
JIRA is already on Apache servers.
But back to the topic, what do folks think of the proposal to target tickets to
milestones and use them for release planning? I think we should start
immediately by creating upcoming milestones, and going through all our old
tickets and assigning them to the new milestones. This would go a long way to
folks wondering what exactly was in 1.3.0.
+1, but what we could probably do with is closing down tickets that
have been open too long and are never going to be realistically done -
can we have a "Probably Never" target?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
