You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2005/11/30 07:41:04 UTC
[PROPOSAL] Target tickets to milestones and use as roadmap
I propose we use an automated, easy to understand roadmap that relies on
Bugzilla tickets marked against Milestones.
With all the action in the Struts project lately, it is hard to see what
is going on where, and specifically, qualitatively how much work remains
before a Milestone will be reached. We need a system that makes it easy
to see at a glance the roadmap of each Struts subproject, and guide new
contributions.
I see the solution involving the following:
1. All tickets, bugs and enhancements, should be marked against a
Milestone if accepted
2. Any major feature or bug fix committed to svn should have a ticket
and be assigned to a milestone.
3. A ticket should only be marked against a Milestone if a developer
has committed to work on it
4. Once all the all the tickets against a Milestone have been
resolved, the release is ready to be rolled.
The public face of this solution will be automated roadmap pages, which
will be generated from Bugzilla reports. These pages will show, at a
glance, the status of each subproject, its milestones, and current
progress toward reaching them.
I've developed a Java console app, driven by a cron, which screen
scrapes Bugzilla reports to generate a roadmap [1]. As you can see from
the demo, we don't currently use milestones much at all. The roadmap is
an idea taken from Trac [2] and I've personally have had great success
with this approach of organizing Milestones.
Comments?
Don
[1] http://www.twdata.org/dakine/roadmap/action.html
[2] http://www.edgewall.com/trac/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by James Mitchell <jm...@apache.org>.
> JIRA is already on Apache servers.
Outstanding!
+1
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
678.910.8017
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Wednesday, November 30, 2005 12:21 PM
Subject: Re: [PROPOSAL] Target tickets to milestones and use as roadmap
> 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.
>
> Don
>
> James Mitchell wrote:
>> I know we've had the Jira vs. Bugzilla discussion before, but given the
>> size and momentum of our product(s)/community, I think the driving
>> reasons for staying on Bugzilla are not as valid as they once were.
>>
>> I've had the fortune of using both on paying gigs and while Jira
>> definitely has perks over bugzilla wrt user/project management and
>> administration, I agree with Don that it should exist on Apache hardware.
>> I'm not sure if things have changed, but I believe infrastructure won't
>> do this for any project, but then, we could always do like the Geronimo
>> folks do ;)
>>
>>
>> --
>> James Mitchell
>> Software Engineer / Open Source Evangelist
>> Consulting / Mentoring / Freelance
>> 678.910.8017
>>
>> ----- Original Message ----- From: "Don Brown" <mr...@twdata.org>
>> To: "Struts Developers List" <de...@struts.apache.org>
>> Sent: Wednesday, November 30, 2005 11:21 AM
>> Subject: Re: [PROPOSAL] Target tickets to milestones and use as roadmap
>>
>>
>>> Sure, moving to JIRA would also be fine. The thrust of this proposal is
>>> that we start using Milestones and targetting tickets towards them. The
>>> roadmap tool we use is a minor point. Even if we switched with JIRA,
>>> we'd still have to change how we use the ticketing system.
>>>
>>> As for switching, I think we should either switch all or none.
>>> Personally, I find it confusing when for a single project, some
>>> materials are on one one site, and others on another. This applies to
>>> the wiki thread as well. If we want to move to Confluence, then let's
>>> get it installed on our Apache servers and move our all the wiki pages
>>> to it. Especially as Struts expands, it is important we keep a tight
>>> discipline of consistency for how we manage the projects.
>>>
>>> Don
>>>
>>> Ted Husted wrote:
>>>
>>>> Or, we could JIRA for the new projects, which supports Roadmaps
>>>> directly.
>>>>
>>>> * http://tinyurl.com/8m4d6
>>>>
>>>> -Ted.
>>>>
>>>> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>>>>
>>>>> I propose we use an automated, easy to understand roadmap that relies
>>>>> on
>>>>> Bugzilla tickets marked against Milestones.
>>>>>
>>>>> With all the action in the Struts project lately, it is hard to see
>>>>> what
>>>>> is going on where, and specifically, qualitatively how much work
>>>>> remains
>>>>> before a Milestone will be reached. We need a system that makes it
>>>>> easy
>>>>> to see at a glance the roadmap of each Struts subproject, and guide
>>>>> new
>>>>> contributions.
>>>>>
>>>>> I see the solution involving the following:
>>>>> 1. All tickets, bugs and enhancements, should be marked against a
>>>>> Milestone if accepted
>>>>> 2. Any major feature or bug fix committed to svn should have a ticket
>>>>> and be assigned to a milestone.
>>>>> 3. A ticket should only be marked against a Milestone if a developer
>>>>> has committed to work on it
>>>>> 4. Once all the all the tickets against a Milestone have been
>>>>> resolved, the release is ready to be rolled.
>>>>>
>>>>> The public face of this solution will be automated roadmap pages,
>>>>> which
>>>>> will be generated from Bugzilla reports. These pages will show, at a
>>>>> glance, the status of each subproject, its milestones, and current
>>>>> progress toward reaching them.
>>>>>
>>>>> I've developed a Java console app, driven by a cron, which screen
>>>>> scrapes Bugzilla reports to generate a roadmap [1]. As you can see
>>>>> from
>>>>> the demo, we don't currently use milestones much at all. The roadmap
>>>>> is
>>>>> an idea taken from Trac [2] and I've personally have had great success
>>>>> with this approach of organizing Milestones.
>>>>>
>>>>> Comments?
>>>>>
>>>>> Don
>>>>>
>>>>> [1] http://www.twdata.org/dakine/roadmap/action.html
>>>>> [2] http://www.edgewall.com/trac/
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)
Posted by Martin Cooper <ma...@apache.org>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
>
>
> Niall Pemberton wrote:
> > generated is a better approach to commit generated. I've started
> > getting into the habit of pasting the commit url into the bug ticket
> > when I close something as fixed. Thats another good way of keeping a
> > link.
>
> OT, but Trac does that for you automatically :)
As does JIRA.
--
Martin Cooper
Don
>
> >
> > Niall
> >
> >
> >>Don
> >>
> >>>Thanks,
> >>>Greg
> >
> >
> > ---------------------------------------------------------------------
> > 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: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)
Posted by Craig McClanahan <cr...@apache.org>.
On 12/1/05, Don Brown <mr...@twdata.org> wrote:
>
> Sure, but my only concern is many svn log analysis tools will only display
> the
> first line of a commit message, so I think it should contain some sort of
> summary. As for Contributed By, I was thinking only to put that there if
> there
> was a patch, because otherwise, it is easy to scrape the reporter from the
> ticket itself.
On my day job development, we often encode the bugzilla ticket number in
the first line of the commit message, to make sure it shows up in the mail
message subject, and is easy to snarf by an analysis tool. Something like:
http://svn.apache.org/viewcvs.cgi?rev=344322&view=rev
Craig
Re: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)
Posted by Niall Pemberton <ni...@gmail.com>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> Hubert Rabago wrote:
> > On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> >
> >>Yeah, I've been using that changes thing with stxx for years now. I believe it
> >>started with Forrest. Anyways, sure, that would work too, although I'd prefer
> >>even the xml to be automatically generated. What if we went back to having a
> >>commit message template that could be parsed for info like this?
> >
> >
> > I wouldn't mind that. "went back" - I didn't know there was one before.
>
> There was in the CVS days, and I don't believe I've seen it since. I'm thinking
> something simple like:
> Adding this new feature
> PR: 234
> Type: (fix, add, update, documentation)
> Contributed By: Sarah Jones
I just had a look at TortoiseSVN (my svn client) - it has a
tsvn:logtemplate property for setting a template for the commit
message.
> And really, even the contributed by could be scraped from the ticket.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Commit template (was [PROPOSAL] Target tickets to milestones
and use as roadmap)
Posted by Don Brown <mr...@twdata.org>.
Sure, but my only concern is many svn log analysis tools will only display the
first line of a commit message, so I think it should contain some sort of
summary. As for Contributed By, I was thinking only to put that there if there
was a patch, because otherwise, it is easy to scrape the reporter from the
ticket itself.
BTW, +1 for using a format that JIRA can understand for bugs, even if we aren't
using it currently.
Don
Ted Husted wrote:
> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
>>There was in the CVS days, and I don't believe I've seen it since. I'm thinking
>>something simple like:
>>Adding this new feature
>>PR: 234
>>Type: (fix, add, update, documentation)
>>Contributed By: Sarah Jones
>
>
> I'd suggest somthing like this:
>
> ----
> Bug 5739
> * Struts fails silently in too many places
> * Reporter: Frank Lawlor
> * Add error messages for ..
> * ...
> ----
>
> This format follows the text on the bugzilla screen, and it's
> compatible with the way JIRA hooks up issues to Subversion commits, in
> case we ever go there. Following the way JIRA/Subversion works, f a
> commit applies to multiple tickets, all the IDs should be listed
> first.
>
> ---
> Bug 5739
> Bug 9616
> * Struts fails silently in too many places
> * Make error keys more specific
> * Reporter: Frank Lawlor, David M. Karr
> * Add error messages for ..
> * ...
> ----
>
> I would suggest not making the words "Contributed by" part of a
> standard template, because sometimes "contributed" might be too strong
> a word for the reporter's role. There are many cases where someone
> might report an issue or request a feature, but we still do the actual
> coding.
>
> -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: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)
Posted by Ted Husted <te...@gmail.com>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> There was in the CVS days, and I don't believe I've seen it since. I'm thinking
> something simple like:
> Adding this new feature
> PR: 234
> Type: (fix, add, update, documentation)
> Contributed By: Sarah Jones
I'd suggest somthing like this:
----
Bug 5739
* Struts fails silently in too many places
* Reporter: Frank Lawlor
* Add error messages for ..
* ...
----
This format follows the text on the bugzilla screen, and it's
compatible with the way JIRA hooks up issues to Subversion commits, in
case we ever go there. Following the way JIRA/Subversion works, f a
commit applies to multiple tickets, all the IDs should be listed
first.
---
Bug 5739
Bug 9616
* Struts fails silently in too many places
* Make error keys more specific
* Reporter: Frank Lawlor, David M. Karr
* Add error messages for ..
* ...
----
I would suggest not making the words "Contributed by" part of a
standard template, because sometimes "contributed" might be too strong
a word for the reporter's role. There are many cases where someone
might report an issue or request a feature, but we still do the actual
coding.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Commit template (was [PROPOSAL] Target tickets to milestones
and use as roadmap)
Posted by Don Brown <mr...@twdata.org>.
Niall Pemberton wrote:
> generated is a better approach to commit generated. I've started
> getting into the habit of pasting the commit url into the bug ticket
> when I close something as fixed. Thats another good way of keeping a
> link.
OT, but Trac does that for you automatically :)
Don
>
> Niall
>
>
>>Don
>>
>>>Thanks,
>>>Greg
>
>
> ---------------------------------------------------------------------
> 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: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)
Posted by Niall Pemberton <ni...@gmail.com>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> Greg Reddin wrote:
> >
> > On Nov 30, 2005, at 1:49 PM, Don Brown wrote:
> >
> >> There was in the CVS days, and I don't believe I've seen it since.
> >> I'm thinking something simple like:
> >> Adding this new feature
> >> PR: 234
> >> Type: (fix, add, update, documentation)
> >> Contributed By: Sarah Jones
> >
> >
> > Just a clarification: Are we saying every commit should have a ticket
> > attached to it or will there be room for commits without that?
>
> The PR will be optional, however if it is a major feature, it should really have
> a ticket. I think forcing a ticket is a bit extreme :)
I agree although probably at the moment when its stuff we originate
(rather than prompted by a ticket), its too much the other way. Mail
threads get lost and IMO its better creating a ticket and putting
feedback into that.
I also like what Patrick showed from Confluence - having a combination
of hand written and generated release notes. Thats what I did for
Struts 1.2.7 (except it was all hand written) - have a summary to give
people a flavour and then detail list of tickets. The only thing
missing from Patricks was a link to the commit message.
Where this breaks down (i.e. commit generated release notes) is when
you have several commits for the same thing, which quite often happens
as things evolve or an issue in the change comes up. Also there are
alot of commits which you really don't want to publish (changing the
build system, site documentation, re-organising the repository, svn
properties etc) which would have to be filtered out. Maybe bug
generated is a better approach to commit generated. I've started
getting into the habit of pasting the commit url into the bug ticket
when I close something as fixed. Thats another good way of keeping a
link.
Niall
> Don
> >
> > Thanks,
> > Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Commit template (was [PROPOSAL] Target tickets to milestones
and use as roadmap)
Posted by Don Brown <mr...@twdata.org>.
Greg Reddin wrote:
>
> On Nov 30, 2005, at 1:49 PM, Don Brown wrote:
>
>> There was in the CVS days, and I don't believe I've seen it since.
>> I'm thinking something simple like:
>> Adding this new feature
>> PR: 234
>> Type: (fix, add, update, documentation)
>> Contributed By: Sarah Jones
>
>
> Just a clarification: Are we saying every commit should have a ticket
> attached to it or will there be room for commits without that?
The PR will be optional, however if it is a major feature, it should really have
a ticket. I think forcing a ticket is a bit extreme :)
Don
>
> Thanks,
> Greg
>
>
> ---------------------------------------------------------------------
> 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: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)
Posted by Greg Reddin <gr...@apache.org>.
On Nov 30, 2005, at 1:49 PM, Don Brown wrote:
> There was in the CVS days, and I don't believe I've seen it since.
> I'm thinking something simple like:
> Adding this new feature
> PR: 234
> Type: (fix, add, update, documentation)
> Contributed By: Sarah Jones
Just a clarification: Are we saying every commit should have a
ticket attached to it or will there be room for commits without that?
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Commit template (was [PROPOSAL] Target tickets to milestones and
use as roadmap)
Posted by Don Brown <mr...@twdata.org>.
Hubert Rabago wrote:
> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
>>Yeah, I've been using that changes thing with stxx for years now. I believe it
>>started with Forrest. Anyways, sure, that would work too, although I'd prefer
>>even the xml to be automatically generated. What if we went back to having a
>>commit message template that could be parsed for info like this?
>
>
> I wouldn't mind that. "went back" - I didn't know there was one before.
There was in the CVS days, and I don't believe I've seen it since. I'm thinking
something simple like:
Adding this new feature
PR: 234
Type: (fix, add, update, documentation)
Contributed By: Sarah Jones
And really, even the contributed by could be scraped from the ticket.
Don
>
> Hubert
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Patrick Lightbody <pl...@gmail.com>.
What we have done with WebWork is use Confluence to generate all our
documentation. Then we use the JIRA macro plugin to include all the
issues. We also have a standard Confluence template for release notes,
making each release consistent:
http://wiki.opensymphony.com/display/WW/Previous+releases
For a specific release, see:
http://wiki.opensymphony.com/display/WW/WebWork+2.2
Note that while we show all the issues, we also have a high level
description of the key changes for the release that is written by
hand. We also do some other neat tricks you guys might be interested
in, like generating documentation based on code in CVS using a
"snippet" macro that we borrowed from CodeHaus and extended.
For example, see the ActionMapper reference docs:
http://wiki.opensymphony.com/display/WW/ActionMapper
All the "yellow content" comes from the source files directly.When the
content is exported, the yellow background and "refresh link" are not
rendered.
Patrick
On 11/30/05, Hubert Rabago <hr...@gmail.com> wrote:
> On 11/30/05, Niall Pemberton <ni...@gmail.com> wrote:
> > Maybe jira has something smarter, but I found a maven feature recently
> > working on Commons Resources - you can specify an "issue" number in
> > the change log and attribute credit ("due-to") and as long as you have
> > the issue tracking *format* configured in your project.properties it
> > will automatically generate a link and "thanks to" text.
> >
> > This is what it looks like:
> > http://tinyurl.com/9qjq5
> >
> > This is what it generates:
> > http://jakarta.apache.org/commons/resources/changes-report.html
> >
> > Niall
>
> Oh that's right. I remember seeing you use those in the commit
> messages, but I didn't follow through to figure out where they ended
> up.
>
>
> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> > Yeah, I've been using that changes thing with stxx for years now. I believe it
> > started with Forrest. Anyways, sure, that would work too, although I'd prefer
> > even the xml to be automatically generated. What if we went back to having a
> > commit message template that could be parsed for info like this?
>
> I wouldn't mind that. "went back" - I didn't know there was one before.
>
> Hubert
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Hubert Rabago <hr...@gmail.com>.
On 11/30/05, Niall Pemberton <ni...@gmail.com> wrote:
> Maybe jira has something smarter, but I found a maven feature recently
> working on Commons Resources - you can specify an "issue" number in
> the change log and attribute credit ("due-to") and as long as you have
> the issue tracking *format* configured in your project.properties it
> will automatically generate a link and "thanks to" text.
>
> This is what it looks like:
> http://tinyurl.com/9qjq5
>
> This is what it generates:
> http://jakarta.apache.org/commons/resources/changes-report.html
>
> Niall
Oh that's right. I remember seeing you use those in the commit
messages, but I didn't follow through to figure out where they ended
up.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> Yeah, I've been using that changes thing with stxx for years now. I believe it
> started with Forrest. Anyways, sure, that would work too, although I'd prefer
> even the xml to be automatically generated. What if we went back to having a
> commit message template that could be parsed for info like this?
I wouldn't mind that. "went back" - I didn't know there was one before.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Don Brown <mr...@twdata.org>.
Side note: I'd really like to start recognizing contributions more visibly and
consistently than we do today, and I like that feature of the changes doc. I
know I always have a warm fuzzy when my little patch is mentioned in a project's
release notes somewhere. :)
Don
Don Brown wrote:
> Yeah, I've been using that changes thing with stxx for years now. I
> believe it started with Forrest. Anyways, sure, that would work too,
> although I'd prefer even the xml to be automatically generated. What if
> we went back to having a commit message template that could be parsed
> for info like this?
>
> Don
>
> Niall Pemberton wrote:
>
>> On 11/30/05, Hubert Rabago <hr...@gmail.com> wrote:
>>
>>> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>>>
>>>> And a big thank you for the +1's :) Any more?
>>>>
>>>> Don
>>>>
>>>
>>> +1.
>>>
>>> Any chance we can come up with a way to automatically collect the
>>> information that we've started to put in the release notes as well?
>>> The table consisting of SVN revision # and bugzilla (jira?) ticket
>>> number, shown here
>>> http://struts.apache.org/struts-action/userGuide/release-notes-1.2.8.html
>>>
>>> . I'm not familiar with Jira to know if they have a field for a VCS
>>> revision #, but in any case maybe your screen scraper can collect this
>>> info somehow.
>>
>>
>>
>> Maybe jira has something smarter, but I found a maven feature recently
>> working on Commons Resources - you can specify an "issue" number in
>> the change log and attribute credit ("due-to") and as long as you have
>> the issue tracking *format* configured in your project.properties it
>> will automatically generate a link and "thanks to" text.
>>
>> This is what it looks like:
>> http://tinyurl.com/9qjq5
>>
>> This is what it generates:
>> http://jakarta.apache.org/commons/resources/changes-report.html
>>
>> Niall
>>
>>
>>> Hubert
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Don Brown <mr...@twdata.org>.
Yeah, I've been using that changes thing with stxx for years now. I believe it
started with Forrest. Anyways, sure, that would work too, although I'd prefer
even the xml to be automatically generated. What if we went back to having a
commit message template that could be parsed for info like this?
Don
Niall Pemberton wrote:
> On 11/30/05, Hubert Rabago <hr...@gmail.com> wrote:
>
>>On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>>
>>>And a big thank you for the +1's :) Any more?
>>>
>>>Don
>>>
>>
>>+1.
>>
>>Any chance we can come up with a way to automatically collect the
>>information that we've started to put in the release notes as well?
>>The table consisting of SVN revision # and bugzilla (jira?) ticket
>>number, shown here
>>http://struts.apache.org/struts-action/userGuide/release-notes-1.2.8.html
>>. I'm not familiar with Jira to know if they have a field for a VCS
>>revision #, but in any case maybe your screen scraper can collect this
>>info somehow.
>
>
> Maybe jira has something smarter, but I found a maven feature recently
> working on Commons Resources - you can specify an "issue" number in
> the change log and attribute credit ("due-to") and as long as you have
> the issue tracking *format* configured in your project.properties it
> will automatically generate a link and "thanks to" text.
>
> This is what it looks like:
> http://tinyurl.com/9qjq5
>
> This is what it generates:
> http://jakarta.apache.org/commons/resources/changes-report.html
>
> Niall
>
>
>>Hubert
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Niall Pemberton <ni...@gmail.com>.
On 11/30/05, Hubert Rabago <hr...@gmail.com> wrote:
> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> >
> > And a big thank you for the +1's :) Any more?
> >
> > Don
> >
>
> +1.
>
> Any chance we can come up with a way to automatically collect the
> information that we've started to put in the release notes as well?
> The table consisting of SVN revision # and bugzilla (jira?) ticket
> number, shown here
> http://struts.apache.org/struts-action/userGuide/release-notes-1.2.8.html
> . I'm not familiar with Jira to know if they have a field for a VCS
> revision #, but in any case maybe your screen scraper can collect this
> info somehow.
Maybe jira has something smarter, but I found a maven feature recently
working on Commons Resources - you can specify an "issue" number in
the change log and attribute credit ("due-to") and as long as you have
the issue tracking *format* configured in your project.properties it
will automatically generate a link and "thanks to" text.
This is what it looks like:
http://tinyurl.com/9qjq5
This is what it generates:
http://jakarta.apache.org/commons/resources/changes-report.html
Niall
> Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Sean Schofield <se...@gmail.com>.
+1 for JIRA. I was going to suggest it right off the bat when the
WebWorks merger was proposed but I decided to hold back since nobody
seemed to like the suggestion the last time I made it ;-)
Martin is right about the SVN integration. You get some nice linkage
between issues and SVN revisions automatically if you mention the
issue number in your SVN comments.
+1 for milestones
sean
On 11/30/05, Martin Cooper <ma...@apache.org> wrote:
> On 11/30/05, Hubert Rabago <hr...@gmail.com> wrote:
> >
> > On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> > >
> > > And a big thank you for the +1's :) Any more?
> > >
> > > Don
> > >
> >
> > +1.
> >
> > Any chance we can come up with a way to automatically collect the
> > information that we've started to put in the release notes as well?
> > The table consisting of SVN revision # and bugzilla (jira?) ticket
> > number, shown here
> > http://struts.apache.org/struts-action/userGuide/release-notes-1.2.8.html
> > . I'm not familiar with Jira to know if they have a field for a VCS
> > revision #, but in any case maybe your screen scraper can collect this
> > info somehow.
>
>
> JIRA has SVN integration that automatically links commits and bug reports.
> For an example, see:
>
> http://issues.apache.org/jira/browse/GERONIMO-1252?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
>
> (The SVN bit is all the way at the bottom.)
>
> And +1 on Don's original proposal!
>
> --
> Martin Cooper
>
>
> Hubert
> >
> > ---------------------------------------------------------------------
> > 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Martin Cooper <ma...@apache.org>.
On 11/30/05, Hubert Rabago <hr...@gmail.com> wrote:
>
> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> >
> > And a big thank you for the +1's :) Any more?
> >
> > Don
> >
>
> +1.
>
> Any chance we can come up with a way to automatically collect the
> information that we've started to put in the release notes as well?
> The table consisting of SVN revision # and bugzilla (jira?) ticket
> number, shown here
> http://struts.apache.org/struts-action/userGuide/release-notes-1.2.8.html
> . I'm not familiar with Jira to know if they have a field for a VCS
> revision #, but in any case maybe your screen scraper can collect this
> info somehow.
JIRA has SVN integration that automatically links commits and bug reports.
For an example, see:
http://issues.apache.org/jira/browse/GERONIMO-1252?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
(The SVN bit is all the way at the bottom.)
And +1 on Don's original proposal!
--
Martin Cooper
Hubert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Hubert Rabago <hr...@gmail.com>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
> And a big thank you for the +1's :) Any more?
>
> Don
>
+1.
Any chance we can come up with a way to automatically collect the
information that we've started to put in the release notes as well?
The table consisting of SVN revision # and bugzilla (jira?) ticket
number, shown here
http://struts.apache.org/struts-action/userGuide/release-notes-1.2.8.html
. I'm not familiar with Jira to know if they have a field for a VCS
revision #, but in any case maybe your screen scraper can collect this
info somehow.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Joe Germuska <Jo...@Germuska.com>.
>And a big thank you for the +1's :) Any more?
+1
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> And a big thank you for the +1's :) Any more?
+1
(And for automating release notes/change logs as much as possible.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Rich Feit <ri...@gmail.com>.
Here's my (advisory-only) +1. As someone who's been working on a
project (Beehive) that's always had a dependency on Struts, I think this
would really help increase the transparency of the release process.
Rich
Patrick Lightbody wrote:
>I don't think I get to vote just yet, but I'd be a big +1. JIRA tends
>to encourage you to do this anyway, and I find it it is a great way to
>manage a project a at a low level.
>
>On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
>
>>Greg Reddin wrote:
>>
>>
>>>On Nov 30, 2005, at 11:21 AM, Don Brown wrote:
>>>
>>>
>>>
>>>>But back to the topic, what do folks think of the proposal to target
>>>>tickets to milestones and use them for release planning?
>>>>
>>>>
>>>+1. It's basically just a formalization of what we do on the wiki now,
>>>right?
>>>
>>>
>>Kinda. When we get close to a release, we take the open bugs from bugzilla and
>>try to close or resolve them. This approach would supersede the need for this
>>by providing a list of open bugs at any stage in the cycle. Furthermore, our
>>release plan only covers outstanding bugs, and not enhancements. When we want
>>to declare we won't address a bug in this release, we mark it as later. I'd
>>much prefer we mark even bugs against a milestone to know 1) what we are
>>committed to fixing and 2) when it will be fixed.
>>
>>And a big thank you for the +1's :) Any more?
>>
>>Don
>>
>>
>>
>>>>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
>>>
>>>Greg
>>>
>>>
>>>---------------------------------------------------------------------
>>>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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Patrick Lightbody <pl...@gmail.com>.
I don't think I get to vote just yet, but I'd be a big +1. JIRA tends
to encourage you to do this anyway, and I find it it is a great way to
manage a project a at a low level.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> Greg Reddin wrote:
> >
> > On Nov 30, 2005, at 11:21 AM, Don Brown wrote:
> >
> >> But back to the topic, what do folks think of the proposal to target
> >> tickets to milestones and use them for release planning?
> >
> >
> > +1. It's basically just a formalization of what we do on the wiki now,
> > right?
>
> Kinda. When we get close to a release, we take the open bugs from bugzilla and
> try to close or resolve them. This approach would supersede the need for this
> by providing a list of open bugs at any stage in the cycle. Furthermore, our
> release plan only covers outstanding bugs, and not enhancements. When we want
> to declare we won't address a bug in this release, we mark it as later. I'd
> much prefer we mark even bugs against a milestone to know 1) what we are
> committed to fixing and 2) when it will be fixed.
>
> And a big thank you for the +1's :) Any more?
>
> Don
>
> >
> >> 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
> >
> > Greg
> >
> >
> > ---------------------------------------------------------------------
> > 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Don Brown <mr...@twdata.org>.
Greg Reddin wrote:
>
> On Nov 30, 2005, at 11:21 AM, Don Brown wrote:
>
>> But back to the topic, what do folks think of the proposal to target
>> tickets to milestones and use them for release planning?
>
>
> +1. It's basically just a formalization of what we do on the wiki now,
> right?
Kinda. When we get close to a release, we take the open bugs from bugzilla and
try to close or resolve them. This approach would supersede the need for this
by providing a list of open bugs at any stage in the cycle. Furthermore, our
release plan only covers outstanding bugs, and not enhancements. When we want
to declare we won't address a bug in this release, we mark it as later. I'd
much prefer we mark even bugs against a milestone to know 1) what we are
committed to fixing and 2) when it will be fixed.
And a big thank you for the +1's :) Any more?
Don
>
>> 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
>
> Greg
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Greg Reddin <gr...@apache.org>.
On Nov 30, 2005, at 11:21 AM, Don Brown wrote:
> But back to the topic, what do folks think of the proposal to
> target tickets to milestones and use them for release planning?
+1. It's basically just a formalization of what we do on the wiki
now, right?
> 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
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Sean Schofield <se...@gmail.com>.
> We also create an artificial milestone called "Future" that we assign
> things that are of the wish-list variety. We always schedule it after
> all of the other versions so that it doesn't bog down the roadmap displays.
Same here. We use TBD.
> -Paul
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Paul Speed <ps...@progeeks.com>.
From the peanut gallery...
How we do this stuff at my day job is that we create versions in Jira
for each of the milestones (which I think is what you guys are talking
about) which lets us use the roadmap feature, etc..
We also create an artificial milestone called "Future" that we assign
things that are of the wish-list variety. We always schedule it after
all of the other versions so that it doesn't bog down the roadmap displays.
-Paul
Don Brown 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 <mr...@twdata.org> 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: 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Don Brown <mr...@twdata.org>.
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 <mr...@twdata.org> 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 <mr...@twdata.org> 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: 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Hubert Rabago <hr...@gmail.com>.
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 <mr...@twdata.org> 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 <mr...@twdata.org> 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: 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Don Brown <mr...@twdata.org>.
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 <mr...@twdata.org> 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: 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Niall Pemberton <ni...@gmail.com>.
On 11/30/05, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Don Brown <mr...@twdata.org>.
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.
Don
James Mitchell wrote:
> I know we've had the Jira vs. Bugzilla discussion before, but given the
> size and momentum of our product(s)/community, I think the driving
> reasons for staying on Bugzilla are not as valid as they once were.
>
> I've had the fortune of using both on paying gigs and while Jira
> definitely has perks over bugzilla wrt user/project management and
> administration, I agree with Don that it should exist on Apache
> hardware. I'm not sure if things have changed, but I believe
> infrastructure won't do this for any project, but then, we could always
> do like the Geronimo folks do ;)
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> 678.910.8017
>
> ----- Original Message ----- From: "Don Brown" <mr...@twdata.org>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Wednesday, November 30, 2005 11:21 AM
> Subject: Re: [PROPOSAL] Target tickets to milestones and use as roadmap
>
>
>> Sure, moving to JIRA would also be fine. The thrust of this proposal
>> is that we start using Milestones and targetting tickets towards
>> them. The roadmap tool we use is a minor point. Even if we switched
>> with JIRA, we'd still have to change how we use the ticketing system.
>>
>> As for switching, I think we should either switch all or none.
>> Personally, I find it confusing when for a single project, some
>> materials are on one one site, and others on another. This applies to
>> the wiki thread as well. If we want to move to Confluence, then let's
>> get it installed on our Apache servers and move our all the wiki pages
>> to it. Especially as Struts expands, it is important we keep a tight
>> discipline of consistency for how we manage the projects.
>>
>> Don
>>
>> Ted Husted wrote:
>>
>>> Or, we could JIRA for the new projects, which supports Roadmaps
>>> directly.
>>>
>>> * http://tinyurl.com/8m4d6
>>>
>>> -Ted.
>>>
>>> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>>>
>>>> I propose we use an automated, easy to understand roadmap that
>>>> relies on
>>>> Bugzilla tickets marked against Milestones.
>>>>
>>>> With all the action in the Struts project lately, it is hard to see
>>>> what
>>>> is going on where, and specifically, qualitatively how much work
>>>> remains
>>>> before a Milestone will be reached. We need a system that makes it
>>>> easy
>>>> to see at a glance the roadmap of each Struts subproject, and guide new
>>>> contributions.
>>>>
>>>> I see the solution involving the following:
>>>> 1. All tickets, bugs and enhancements, should be marked against a
>>>> Milestone if accepted
>>>> 2. Any major feature or bug fix committed to svn should have a ticket
>>>> and be assigned to a milestone.
>>>> 3. A ticket should only be marked against a Milestone if a developer
>>>> has committed to work on it
>>>> 4. Once all the all the tickets against a Milestone have been
>>>> resolved, the release is ready to be rolled.
>>>>
>>>> The public face of this solution will be automated roadmap pages, which
>>>> will be generated from Bugzilla reports. These pages will show, at a
>>>> glance, the status of each subproject, its milestones, and current
>>>> progress toward reaching them.
>>>>
>>>> I've developed a Java console app, driven by a cron, which screen
>>>> scrapes Bugzilla reports to generate a roadmap [1]. As you can see
>>>> from
>>>> the demo, we don't currently use milestones much at all. The
>>>> roadmap is
>>>> an idea taken from Trac [2] and I've personally have had great success
>>>> with this approach of organizing Milestones.
>>>>
>>>> Comments?
>>>>
>>>> Don
>>>>
>>>> [1] http://www.twdata.org/dakine/roadmap/action.html
>>>> [2] http://www.edgewall.com/trac/
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by James Mitchell <jm...@apache.org>.
I know we've had the Jira vs. Bugzilla discussion before, but given the size
and momentum of our product(s)/community, I think the driving reasons for
staying on Bugzilla are not as valid as they once were.
I've had the fortune of using both on paying gigs and while Jira definitely
has perks over bugzilla wrt user/project management and administration, I
agree with Don that it should exist on Apache hardware. I'm not sure if
things have changed, but I believe infrastructure won't do this for any
project, but then, we could always do like the Geronimo folks do ;)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
678.910.8017
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Wednesday, November 30, 2005 11:21 AM
Subject: Re: [PROPOSAL] Target tickets to milestones and use as roadmap
> Sure, moving to JIRA would also be fine. The thrust of this proposal is
> that we start using Milestones and targetting tickets towards them. The
> roadmap tool we use is a minor point. Even if we switched with JIRA, we'd
> still have to change how we use the ticketing system.
>
> As for switching, I think we should either switch all or none. Personally,
> I find it confusing when for a single project, some materials are on one
> one site, and others on another. This applies to the wiki thread as well.
> If we want to move to Confluence, then let's get it installed on our
> Apache servers and move our all the wiki pages to it. Especially as
> Struts expands, it is important we keep a tight discipline of consistency
> for how we manage the projects.
>
> Don
>
> Ted Husted wrote:
>> Or, we could JIRA for the new projects, which supports Roadmaps directly.
>>
>> * http://tinyurl.com/8m4d6
>>
>> -Ted.
>>
>> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>>
>>>I propose we use an automated, easy to understand roadmap that relies on
>>>Bugzilla tickets marked against Milestones.
>>>
>>>With all the action in the Struts project lately, it is hard to see what
>>>is going on where, and specifically, qualitatively how much work remains
>>>before a Milestone will be reached. We need a system that makes it easy
>>>to see at a glance the roadmap of each Struts subproject, and guide new
>>>contributions.
>>>
>>>I see the solution involving the following:
>>> 1. All tickets, bugs and enhancements, should be marked against a
>>>Milestone if accepted
>>> 2. Any major feature or bug fix committed to svn should have a ticket
>>>and be assigned to a milestone.
>>> 3. A ticket should only be marked against a Milestone if a developer
>>>has committed to work on it
>>> 4. Once all the all the tickets against a Milestone have been
>>>resolved, the release is ready to be rolled.
>>>
>>>The public face of this solution will be automated roadmap pages, which
>>>will be generated from Bugzilla reports. These pages will show, at a
>>>glance, the status of each subproject, its milestones, and current
>>>progress toward reaching them.
>>>
>>>I've developed a Java console app, driven by a cron, which screen
>>>scrapes Bugzilla reports to generate a roadmap [1]. As you can see from
>>>the demo, we don't currently use milestones much at all. The roadmap is
>>>an idea taken from Trac [2] and I've personally have had great success
>>>with this approach of organizing Milestones.
>>>
>>>Comments?
>>>
>>>Don
>>>
>>>[1] http://www.twdata.org/dakine/roadmap/action.html
>>>[2] http://www.edgewall.com/trac/
>>
>>
>> ---------------------------------------------------------------------
>> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Don Brown <mr...@twdata.org>.
Sure, moving to JIRA would also be fine. The thrust of this proposal is
that we start using Milestones and targetting tickets towards them. The
roadmap tool we use is a minor point. Even if we switched with JIRA,
we'd still have to change how we use the ticketing system.
As for switching, I think we should either switch all or none.
Personally, I find it confusing when for a single project, some
materials are on one one site, and others on another. This applies to
the wiki thread as well. If we want to move to Confluence, then let's
get it installed on our Apache servers and move our all the wiki pages
to it. Especially as Struts expands, it is important we keep a tight
discipline of consistency for how we manage the projects.
Don
Ted Husted wrote:
> Or, we could JIRA for the new projects, which supports Roadmaps directly.
>
> * http://tinyurl.com/8m4d6
>
> -Ted.
>
> On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
>>I propose we use an automated, easy to understand roadmap that relies on
>>Bugzilla tickets marked against Milestones.
>>
>>With all the action in the Struts project lately, it is hard to see what
>>is going on where, and specifically, qualitatively how much work remains
>>before a Milestone will be reached. We need a system that makes it easy
>>to see at a glance the roadmap of each Struts subproject, and guide new
>>contributions.
>>
>>I see the solution involving the following:
>> 1. All tickets, bugs and enhancements, should be marked against a
>>Milestone if accepted
>> 2. Any major feature or bug fix committed to svn should have a ticket
>>and be assigned to a milestone.
>> 3. A ticket should only be marked against a Milestone if a developer
>>has committed to work on it
>> 4. Once all the all the tickets against a Milestone have been
>>resolved, the release is ready to be rolled.
>>
>>The public face of this solution will be automated roadmap pages, which
>>will be generated from Bugzilla reports. These pages will show, at a
>>glance, the status of each subproject, its milestones, and current
>>progress toward reaching them.
>>
>>I've developed a Java console app, driven by a cron, which screen
>>scrapes Bugzilla reports to generate a roadmap [1]. As you can see from
>>the demo, we don't currently use milestones much at all. The roadmap is
>>an idea taken from Trac [2] and I've personally have had great success
>>with this approach of organizing Milestones.
>>
>>Comments?
>>
>>Don
>>
>>[1] http://www.twdata.org/dakine/roadmap/action.html
>>[2] http://www.edgewall.com/trac/
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Greg Reddin <gr...@apache.org>.
On Nov 30, 2005, at 6:25 AM, Ted Husted wrote:
> Or, we could JIRA for the new projects, which supports Roadmaps
> directly.
I think I'd be more in favor of this with Jira than Bugzilla, but I'm
+0 even with Bugzilla.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Ted Husted <te...@gmail.com>.
Or, we could JIRA for the new projects, which supports Roadmaps directly.
* http://tinyurl.com/8m4d6
-Ted.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> I propose we use an automated, easy to understand roadmap that relies on
> Bugzilla tickets marked against Milestones.
>
> With all the action in the Struts project lately, it is hard to see what
> is going on where, and specifically, qualitatively how much work remains
> before a Milestone will be reached. We need a system that makes it easy
> to see at a glance the roadmap of each Struts subproject, and guide new
> contributions.
>
> I see the solution involving the following:
> 1. All tickets, bugs and enhancements, should be marked against a
> Milestone if accepted
> 2. Any major feature or bug fix committed to svn should have a ticket
> and be assigned to a milestone.
> 3. A ticket should only be marked against a Milestone if a developer
> has committed to work on it
> 4. Once all the all the tickets against a Milestone have been
> resolved, the release is ready to be rolled.
>
> The public face of this solution will be automated roadmap pages, which
> will be generated from Bugzilla reports. These pages will show, at a
> glance, the status of each subproject, its milestones, and current
> progress toward reaching them.
>
> I've developed a Java console app, driven by a cron, which screen
> scrapes Bugzilla reports to generate a roadmap [1]. As you can see from
> the demo, we don't currently use milestones much at all. The roadmap is
> an idea taken from Trac [2] and I've personally have had great success
> with this approach of organizing Milestones.
>
> Comments?
>
> Don
>
> [1] http://www.twdata.org/dakine/roadmap/action.html
> [2] http://www.edgewall.com/trac/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Craig McClanahan <cr...@apache.org>.
+1 on Don's proposals to improve tracking and roadmap.
+0 on JIRA ... Bugzilla makes cross-bug references with Commons projects we
depend on a little easier, but that is less important now (most of the
Commons packages we use are pretty stable) than it was earlier.
Craig
On 11/29/05, Don Brown <mr...@twdata.org> wrote:
>
> I propose we use an automated, easy to understand roadmap that relies on
> Bugzilla tickets marked against Milestones.
>
> With all the action in the Struts project lately, it is hard to see what
> is going on where, and specifically, qualitatively how much work remains
> before a Milestone will be reached. We need a system that makes it easy
> to see at a glance the roadmap of each Struts subproject, and guide new
> contributions.
>
> I see the solution involving the following:
> 1. All tickets, bugs and enhancements, should be marked against a
> Milestone if accepted
> 2. Any major feature or bug fix committed to svn should have a ticket
> and be assigned to a milestone.
> 3. A ticket should only be marked against a Milestone if a developer
> has committed to work on it
> 4. Once all the all the tickets against a Milestone have been
> resolved, the release is ready to be rolled.
>
> The public face of this solution will be automated roadmap pages, which
> will be generated from Bugzilla reports. These pages will show, at a
> glance, the status of each subproject, its milestones, and current
> progress toward reaching them.
>
> I've developed a Java console app, driven by a cron, which screen
> scrapes Bugzilla reports to generate a roadmap [1]. As you can see from
> the demo, we don't currently use milestones much at all. The roadmap is
> an idea taken from Trac [2] and I've personally have had great success
> with this approach of organizing Milestones.
>
> Comments?
>
> Don
>
> [1] http://www.twdata.org/dakine/roadmap/action.html
> [2] http://www.edgewall.com/trac/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Rahul Akolkar <ra...@gmail.com>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
> I propose we use an automated, easy to understand roadmap that relies on
> Bugzilla tickets marked against Milestones.
>
> With all the action in the Struts project lately, it is hard to see what
> is going on where, and specifically, qualitatively how much work remains
> before a Milestone will be reached. We need a system that makes it easy
> to see at a glance the roadmap of each Struts subproject, and guide new
> contributions.
>
<snip/>
Agreed that its getting hard to follow stuff closely across the board.
FWIW, as a user, I'd be glad if such a system were available. Other
than the "roadmap" view, it'll also serve as a good reference for
common user questions such as:
* When will the next milestone come out (approximately)?
* What work is pending before that?
* When can I expect a particular bug to be resolved?
Ofcourse, this will require additional developer discipline.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Target tickets to milestones and use as roadmap
Posted by Laurie Harper <la...@holoweb.net>.
+1 (non-binding). Definitely a good way to add a lot more clarity about
where things stand and what needs doing.
L.
Don Brown wrote:
> I propose we use an automated, easy to understand roadmap that relies on
> Bugzilla tickets marked against Milestones.
>
> With all the action in the Struts project lately, it is hard to see what
> is going on where, and specifically, qualitatively how much work remains
> before a Milestone will be reached. We need a system that makes it easy
> to see at a glance the roadmap of each Struts subproject, and guide new
> contributions.
>
> I see the solution involving the following:
> 1. All tickets, bugs and enhancements, should be marked against a
> Milestone if accepted
> 2. Any major feature or bug fix committed to svn should have a ticket
> and be assigned to a milestone.
> 3. A ticket should only be marked against a Milestone if a developer
> has committed to work on it
> 4. Once all the all the tickets against a Milestone have been resolved,
> the release is ready to be rolled.
>
> The public face of this solution will be automated roadmap pages, which
> will be generated from Bugzilla reports. These pages will show, at a
> glance, the status of each subproject, its milestones, and current
> progress toward reaching them.
>
> I've developed a Java console app, driven by a cron, which screen
> scrapes Bugzilla reports to generate a roadmap [1]. As you can see from
> the demo, we don't currently use milestones much at all. The roadmap is
> an idea taken from Trac [2] and I've personally have had great success
> with this approach of organizing Milestones.
>
> Comments?
>
> Don
>
> [1] http://www.twdata.org/dakine/roadmap/action.html
> [2] http://www.edgewall.com/trac/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org