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/12/01 06:03:28 UTC
Milestones proposal: Step 1
I take it the "Target tickets to milestones" proposal passed, and thanks
for all the feedback. As the first step, could Martin or Craig please
make the following Bugzilla changes:
Milestone changes
- Remove all "Family" milestones
- Rename "(.*) Milestone" to \1 (redundant w/o the family ones)
- Add milestones: 1.2.7, 1.2.8, 1.2.9, 1.0.0, 1.0.2, 0.9
Component changes
- Rename the BSF component to Scripting
- Add "Action" component
- Remove the following components and move their bugs to Action:
Controller, Validator Framework, Digester, Documentation, File Upload,
Test, Utilities and move their bugs to Action component
- Rename the Custom Tags to Taglibs
- Remove EL and move to Taglibs
- Rename Examples as Apps
- Rename Standard Actions to Extras
- Rename Struts Flow to Flow
- Rename Struts-Faces Library to Faces
- Rename Tiles framework to Tiles
I think these changes will make Bugzilla match our project better, and
the milestones, since they have to be shared between all subprojects,
will probably grow quickly with time. Next, I'll start going through
closed tickets and marking them against milestones. Help of course is
appreciated.
Thanks,
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Milestones proposal: Step 1
Posted by Martin Cooper <ma...@apache.org>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
> I take it the "Target tickets to milestones" proposal passed, and thanks
> for all the feedback. As the first step, could Martin or Craig please
> make the following Bugzilla changes:
I'll leave this thread open for a bit, to allow for discussion, but I can
take care of this at the weekend, if not before (assuming Bugzilla lets me).
--
Martin Cooper
Milestone changes
> - Remove all "Family" milestones
> - Rename "(.*) Milestone" to \1 (redundant w/o the family ones)
> - Add milestones: 1.2.7, 1.2.8, 1.2.9, 1.0.0, 1.0.2, 0.9
>
> Component changes
> - Rename the BSF component to Scripting
> - Add "Action" component
> - Remove the following components and move their bugs to Action:
> Controller, Validator Framework, Digester, Documentation, File Upload,
> Test, Utilities and move their bugs to Action component
> - Rename the Custom Tags to Taglibs
> - Remove EL and move to Taglibs
> - Rename Examples as Apps
> - Rename Standard Actions to Extras
> - Rename Struts Flow to Flow
> - Rename Struts-Faces Library to Faces
> - Rename Tiles framework to Tiles
>
> I think these changes will make Bugzilla match our project better, and
> the milestones, since they have to be shared between all subprojects,
> will probably grow quickly with time. Next, I'll start going through
> closed tickets and marking them against milestones. Help of course is
> appreciated.
>
> Thanks,
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Milestones proposal: Step 1
Posted by Martin Cooper <ma...@apache.org>.
On 12/1/05, Don Brown <mr...@twdata.org> wrote:
>
> In my opinion, it would be simpler to assign those tickets to the next
> major/minor release, forcing developers to assess when that milestone is
> on deck
> whether the ticket will actually get fixed in this one or moved further
> down.
> The problem with this "1.1 Family" is evident in Bugzilla where we have a
> bunch
> of tickets still assigned to the 1.2.x family. I think these family
> categories
> are just corners where tickets go to hide and be forgotten.
+1
Personally, I think even a "Future" or "TBD" milestone clouds the issue, but
> it
> would be a good compromise. What I'm going for is tickets are only
> assigned to
> a milestone when someone steps up and says they'll fix them or the
> community
> agrees it is a requirement of the milestone.
What I'd like to see is that, when an issue is assigned to a milestone, it
means that someone has committed to make sure it gets into that milestone,
not that someone thinks it would be a good idea to get it into that
milestone but isn't stepping up to make that happen. If we abide by that,
then I think we can add an Unspecified (or New or Undecided) as an initial
default. Whether we need an additional value for "probably never", I'm not
really sure, but I tend to think that if we just have Unspecified, that
should be enough.
As for the "probably never" tickets, just sitting in Bugzilla not having a
> milestone will be enough to keep them from the casual project view
> (assuming we
> put in place a clean roadmap).
>
> In general, I think the most simple solution will be the one that lives
> the
> longest and brings the most clarity.
+1
--
Martin Cooper
Don
>
> Ted Husted wrote:
> > On 12/1/05, Niall Pemberton <ni...@gmail.com> wrote:
> >
> >>Did we agree anything on bugs which we don't want to allocate to a
> >>milestone - my preference is a "probably never" or "un-allocated"
> >>milestone - something we can query on. Personally I don't like "LATER"
> >>resolutions - IMO thats not a "resolution".
> >
> >
> > In my own project, we have a major release pseudo-release for issues
> > that we haven't allocated yet, and then true mliestone releases for
> > issues that'ave we have allocated, so the JIRA map looks like this:
> >
> > [Unreleased] 2.x ( Release Notes)
> > Progress: [Unresolved Issues - 100% (4 issues)]
> > 0 of 4 issues have been resolved
> > New Feature (Story) WNE-77 UNRESOLVED A user by any other role
> > New Feature (Story) WNE-76 UNRESOLVED Attachments
> > New Feature (Story) WNE-75 UNRESOLVED Multiple comment
> > New Feature (Story) WNE-44 UNRESOLVED Optimistic locking
> >
> > [Unreleased] 2.0.16 ( 2005-Dec-13 | Release Notes)
> > Progress: [Resolved Issues - 9% (1 issues)] [Unresolved Issues
> -
> > 90% (10 issues)]
> > 1 of 11 issues have been resolved
> > New Feature (Story) WNE-16 UNRESOLVED Add Facility Mandate
> > New Feature (Story) WNE-19 UNRESOLVED Delete an Action and a
> Violation
> > New Feature (Story) WNE-84 UNRESOLVED Meeting Table
> > ....
> >
> > ----
> >
> > So, "2.x" is the "undecided" category for our 2.x release series.
> >
> > -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: Milestones proposal: Step 1
Posted by Don Brown <mr...@twdata.org>.
+1 to new "Probably never" or perhaps something more politically correct state.
Don
Laurie Harper wrote:
> There does need to be a distinction, though, between 'probably never'
> and new tickets, not yet assigned to a milestone. I'm not that familiar
> with Bugzilla, though; maybe the Status field is enough to handle that?
>
> L.
>
> Don Brown wrote:
>
>> In my opinion, it would be simpler to assign those tickets to the next
>> major/minor release, forcing developers to assess when that milestone
>> is on deck whether the ticket will actually get fixed in this one or
>> moved further down. The problem with this "1.1 Family" is evident in
>> Bugzilla where we have a bunch of tickets still assigned to the 1.2.x
>> family. I think these family categories are just corners where
>> tickets go to hide and be forgotten.
>>
>> Personally, I think even a "Future" or "TBD" milestone clouds the
>> issue, but it would be a good compromise. What I'm going for is
>> tickets are only assigned to a milestone when someone steps up and
>> says they'll fix them or the community agrees it is a requirement of
>> the milestone.
>>
>> As for the "probably never" tickets, just sitting in Bugzilla not
>> having a milestone will be enough to keep them from the casual project
>> view (assuming we put in place a clean roadmap).
>>
>> In general, I think the most simple solution will be the one that
>> lives the longest and brings the most clarity.
>>
>> Don
>>
>> Ted Husted wrote:
>>
>>> On 12/1/05, Niall Pemberton <ni...@gmail.com> wrote:
>>>
>>>> Did we agree anything on bugs which we don't want to allocate to a
>>>> milestone - my preference is a "probably never" or "un-allocated"
>>>> milestone - something we can query on. Personally I don't like "LATER"
>>>> resolutions - IMO thats not a "resolution".
>>>
>>>
>>>
>>> In my own project, we have a major release pseudo-release for issues
>>> that we haven't allocated yet, and then true mliestone releases for
>>> issues that'ave we have allocated, so the JIRA map looks like this:
>>>
>>> [Unreleased] 2.x ( Release Notes) Progress: [Unresolved
>>> Issues - 100% (4 issues)]
>>> 0 of 4 issues have been resolved
>>> New Feature (Story) WNE-77 UNRESOLVED A user by any other
>>> role
>>> New Feature (Story) WNE-76 UNRESOLVED Attachments
>>> New Feature (Story) WNE-75 UNRESOLVED Multiple comment
>>> New Feature (Story) WNE-44 UNRESOLVED Optimistic locking
>>>
>>> [Unreleased] 2.0.16 ( 2005-Dec-13 | Release Notes)
>>> Progress: [Resolved Issues - 9% (1 issues)] [Unresolved
>>> Issues -
>>> 90% (10 issues)]
>>> 1 of 11 issues have been resolved
>>> New Feature (Story) WNE-16 UNRESOLVED Add Facility Mandate
>>> New Feature (Story) WNE-19 UNRESOLVED Delete an Action
>>> and a Violation New Feature (Story) WNE-84 UNRESOLVED
>>> Meeting Table
>>> ....
>>>
>>> ----
>>>
>>> So, "2.x" is the "undecided" category for our 2.x release series.
>>>
>>> -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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Milestones proposal: Step 1
Posted by Laurie Harper <la...@holoweb.net>.
There does need to be a distinction, though, between 'probably never'
and new tickets, not yet assigned to a milestone. I'm not that familiar
with Bugzilla, though; maybe the Status field is enough to handle that?
L.
Don Brown wrote:
> In my opinion, it would be simpler to assign those tickets to the next
> major/minor release, forcing developers to assess when that milestone is
> on deck whether the ticket will actually get fixed in this one or moved
> further down. The problem with this "1.1 Family" is evident in Bugzilla
> where we have a bunch of tickets still assigned to the 1.2.x family. I
> think these family categories are just corners where tickets go to hide
> and be forgotten.
>
> Personally, I think even a "Future" or "TBD" milestone clouds the issue,
> but it would be a good compromise. What I'm going for is tickets are
> only assigned to a milestone when someone steps up and says they'll fix
> them or the community agrees it is a requirement of the milestone.
>
> As for the "probably never" tickets, just sitting in Bugzilla not having
> a milestone will be enough to keep them from the casual project view
> (assuming we put in place a clean roadmap).
>
> In general, I think the most simple solution will be the one that lives
> the longest and brings the most clarity.
>
> Don
>
> Ted Husted wrote:
>> On 12/1/05, Niall Pemberton <ni...@gmail.com> wrote:
>>
>>> Did we agree anything on bugs which we don't want to allocate to a
>>> milestone - my preference is a "probably never" or "un-allocated"
>>> milestone - something we can query on. Personally I don't like "LATER"
>>> resolutions - IMO thats not a "resolution".
>>
>>
>> In my own project, we have a major release pseudo-release for issues
>> that we haven't allocated yet, and then true mliestone releases for
>> issues that'ave we have allocated, so the JIRA map looks like this:
>>
>> [Unreleased] 2.x ( Release Notes)
>> Progress: [Unresolved Issues - 100% (4 issues)]
>> 0 of 4 issues have been resolved
>> New Feature (Story) WNE-77 UNRESOLVED A user by any other
>> role
>> New Feature (Story) WNE-76 UNRESOLVED Attachments
>> New Feature (Story) WNE-75 UNRESOLVED Multiple comment
>> New Feature (Story) WNE-44 UNRESOLVED Optimistic locking
>>
>> [Unreleased] 2.0.16 ( 2005-Dec-13 | Release Notes)
>> Progress: [Resolved Issues - 9% (1 issues)] [Unresolved Issues -
>> 90% (10 issues)]
>> 1 of 11 issues have been resolved
>> New Feature (Story) WNE-16 UNRESOLVED Add Facility Mandate
>> New Feature (Story) WNE-19 UNRESOLVED Delete an Action and
>> a Violation
>> New Feature (Story) WNE-84 UNRESOLVED Meeting Table
>> ....
>>
>> ----
>>
>> So, "2.x" is the "undecided" category for our 2.x release series.
>>
>> -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: Milestones proposal: Step 1
Posted by Don Brown <mr...@twdata.org>.
In my opinion, it would be simpler to assign those tickets to the next
major/minor release, forcing developers to assess when that milestone is on deck
whether the ticket will actually get fixed in this one or moved further down.
The problem with this "1.1 Family" is evident in Bugzilla where we have a bunch
of tickets still assigned to the 1.2.x family. I think these family categories
are just corners where tickets go to hide and be forgotten.
Personally, I think even a "Future" or "TBD" milestone clouds the issue, but it
would be a good compromise. What I'm going for is tickets are only assigned to
a milestone when someone steps up and says they'll fix them or the community
agrees it is a requirement of the milestone.
As for the "probably never" tickets, just sitting in Bugzilla not having a
milestone will be enough to keep them from the casual project view (assuming we
put in place a clean roadmap).
In general, I think the most simple solution will be the one that lives the
longest and brings the most clarity.
Don
Ted Husted wrote:
> On 12/1/05, Niall Pemberton <ni...@gmail.com> wrote:
>
>>Did we agree anything on bugs which we don't want to allocate to a
>>milestone - my preference is a "probably never" or "un-allocated"
>>milestone - something we can query on. Personally I don't like "LATER"
>>resolutions - IMO thats not a "resolution".
>
>
> In my own project, we have a major release pseudo-release for issues
> that we haven't allocated yet, and then true mliestone releases for
> issues that'ave we have allocated, so the JIRA map looks like this:
>
> [Unreleased] 2.x ( Release Notes)
> Progress: [Unresolved Issues - 100% (4 issues)]
> 0 of 4 issues have been resolved
> New Feature (Story) WNE-77 UNRESOLVED A user by any other role
> New Feature (Story) WNE-76 UNRESOLVED Attachments
> New Feature (Story) WNE-75 UNRESOLVED Multiple comment
> New Feature (Story) WNE-44 UNRESOLVED Optimistic locking
>
> [Unreleased] 2.0.16 ( 2005-Dec-13 | Release Notes)
> Progress: [Resolved Issues - 9% (1 issues)] [Unresolved Issues -
> 90% (10 issues)]
> 1 of 11 issues have been resolved
> New Feature (Story) WNE-16 UNRESOLVED Add Facility Mandate
> New Feature (Story) WNE-19 UNRESOLVED Delete an Action and a Violation
> New Feature (Story) WNE-84 UNRESOLVED Meeting Table
> ....
>
> ----
>
> So, "2.x" is the "undecided" category for our 2.x release series.
>
> -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: Milestones proposal: Step 1
Posted by Ted Husted <te...@gmail.com>.
On 12/1/05, Niall Pemberton <ni...@gmail.com> wrote:
> Did we agree anything on bugs which we don't want to allocate to a
> milestone - my preference is a "probably never" or "un-allocated"
> milestone - something we can query on. Personally I don't like "LATER"
> resolutions - IMO thats not a "resolution".
In my own project, we have a major release pseudo-release for issues
that we haven't allocated yet, and then true mliestone releases for
issues that'ave we have allocated, so the JIRA map looks like this:
[Unreleased] 2.x ( Release Notes)
Progress: [Unresolved Issues - 100% (4 issues)]
0 of 4 issues have been resolved
New Feature (Story) WNE-77 UNRESOLVED A user by any other role
New Feature (Story) WNE-76 UNRESOLVED Attachments
New Feature (Story) WNE-75 UNRESOLVED Multiple comment
New Feature (Story) WNE-44 UNRESOLVED Optimistic locking
[Unreleased] 2.0.16 ( 2005-Dec-13 | Release Notes)
Progress: [Resolved Issues - 9% (1 issues)] [Unresolved Issues -
90% (10 issues)]
1 of 11 issues have been resolved
New Feature (Story) WNE-16 UNRESOLVED Add Facility Mandate
New Feature (Story) WNE-19 UNRESOLVED Delete an Action and a Violation
New Feature (Story) WNE-84 UNRESOLVED Meeting Table
....
----
So, "2.x" is the "undecided" category for our 2.x release series.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Milestones proposal: Step 1
Posted by Niall Pemberton <ni...@gmail.com>.
On 12/1/05, Don Brown <mr...@twdata.org> wrote:
> I take it the "Target tickets to milestones" proposal passed, and thanks
> for all the feedback. As the first step, could Martin or Craig please
> make the following Bugzilla changes:
>
> Milestone changes
> - Remove all "Family" milestones
> - Rename "(.*) Milestone" to \1 (redundant w/o the family ones)
> - Add milestones: 1.2.7, 1.2.8, 1.2.9, 1.0.0, 1.0.2, 0.9
Did we agree anything on bugs which we don't want to allocate to a
milestone - my preference is a "probably never" or "un-allocated"
milestone - something we can query on. Personally I don't like "LATER"
resolutions - IMO thats not a "resolution".
> Component changes
> - Rename the BSF component to Scripting
> - Add "Action" component
> - Remove the following components and move their bugs to Action:
> Controller, Validator Framework, Digester, Documentation, File Upload,
> Test, Utilities and move their bugs to Action component
> - Rename the Custom Tags to Taglibs
> - Remove EL and move to Taglibs
> - Rename Examples as Apps
> - Rename Standard Actions to Extras
> - Rename Struts Flow to Flow
> - Rename Struts-Faces Library to Faces
> - Rename Tiles framework to Tiles
EL is a separate sub-project - not part of taglib.
> I think these changes will make Bugzilla match our project better, and
> the milestones, since they have to be shared between all subprojects,
> will probably grow quickly with time. Next, I'll start going through
> closed tickets and marking them against milestones. Help of course is
> appreciated.
Are you sure you meant "closed" and not "open" or do we need
everything targeted so that it works for all future releases?
Niall
> Thanks,
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Milestones proposal: Step 1 (revised)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:33 AM -0500 12/2/05, Ted Husted wrote:
>On my own project, we now require that all commits reference an issue ticket.
>
>Is that what we're going for here?
This seems like a lot of overhead; just thinking back to when I was
heavily developing the ActionContext and related features for the
ComposableRequestProcessor... what ticket would we have for that?
even if we had a ticket for the general new feature, when would we
deem it ready to be closed?
I understand the appeal, but I fear it's more bureacracy than value
for us. I'm willing to be convinced otherwise.
Joe
--
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: Milestones proposal: Step 1 (revised)
Posted by Ted Husted <te...@gmail.com>.
On my own project, we now require that all commits reference an issue ticket.
Is that what we're going for here?
If I'm working on WebTests for the MailReader, should I create a
ticket for that, so I can reference it in the commits?
It's been suggested that we have tickets for everything before, and
try to keep the comments with the tickets for future reference, but
most of us never developed the habit.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Milestones proposal: Step 1 (revised)
Posted by Don Brown <mr...@twdata.org>.
Hubert Rabago wrote:
> On 12/1/05, Don Brown <mr...@twdata.org> wrote:
>
>>If we add the "TBD" milestone, I encourage everyone to only add tickets to it if
>>it is a clear, reachable goal that we want to achieve. While I'm afraid it will
>>attract stagnant tickets no one cares about, I understand some folks find it
>>useful, and I'm usually wrong anyways :)
>
>
> Maybe we can agree that if a ticket has had no progress for 12 or 18
> or 24 mos, it should be reviewed and possibly marked WONTFIX /
> INVALID.
Sure. What about as a step 2.5 making use of the
http://struts.apache.org/issue-tracking.html page to record issue tracking
policies and conventions?
>>Next, I see the following steps:
>>
>>Step 2:
>> - Move closed tickets included in soon-to-be-released projects to their
>>milestone.
>> - Wade through TBD tickets and assign to milestones
>>
>>While I like Martin's idea of only putting tickets to milestones when someone
>>commits to resolving them <snip/>
>
>
> I thought this was your idea? (#3 on your initial proposal)
> http://www.nabble.com/-PROPOSAL-Target-tickets-to-milestones-and-use-as-roadmap-p1711361.html
Actually, it was originally Martin's and I agreed, but after more thought,
decided a looser interpretation would be better.
>>Perhaps we could start
>>using the "Assigned" field more often to mark which ones have been taken up and
>>which are just hanging.
>
>
> ...or the combination of "Assigned" and a milestone means that
> committer plans to resolve the ticket for the specified milestone.
Sure, more good stuff for that issue tracking page :)
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: Milestones proposal: Step 1 (revised)
Posted by Hubert Rabago <hr...@gmail.com>.
On 12/1/05, Don Brown <mr...@twdata.org> wrote:
> If we add the "TBD" milestone, I encourage everyone to only add tickets to it if
> it is a clear, reachable goal that we want to achieve. While I'm afraid it will
> attract stagnant tickets no one cares about, I understand some folks find it
> useful, and I'm usually wrong anyways :)
Maybe we can agree that if a ticket has had no progress for 12 or 18
or 24 mos, it should be reviewed and possibly marked WONTFIX /
INVALID.
> Next, I see the following steps:
>
> Step 2:
> - Move closed tickets included in soon-to-be-released projects to their
> milestone.
> - Wade through TBD tickets and assign to milestones
>
> While I like Martin's idea of only putting tickets to milestones when someone
> commits to resolving them <snip/>
I thought this was your idea? (#3 on your initial proposal)
http://www.nabble.com/-PROPOSAL-Target-tickets-to-milestones-and-use-as-roadmap-p1711361.html
> Perhaps we could start
> using the "Assigned" field more often to mark which ones have been taken up and
> which are just hanging.
...or the combination of "Assigned" and a milestone means that
committer plans to resolve the ticket for the specified milestone.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Milestones proposal: Step 1 (revised)
Posted by Paul Speed <ps...@progeeks.com>.
I'll mention how we do it in case it sparks inspiration...
We use Jira to manage issues for several software configurations and
packages. Because of our odd agile process, we never really know when
we're going to cut a release (which is sort of similar to you guys but
we're more customer driven in this case).
To manage this, we always have -Next and -Future versions in Jira. So
for a Foo package, we'd have Foo-Next and Foo-Future. When we know when
our next release will be, we change the name of Foo-Next to Foo-x.y.z or
whatever and make a new Foo-Next. We then move any Foo-x.y.z issues out
of Foo-Next if we don't think they'll make it in. We do this because it
forces us to readdress the pending issues with each release and close
them or move the to -Future if they somehow fall out of pending status.
From the submitter's perspective, they also get an e-mail notification
that their issue won't be making it into the next release.
One could just as easily create a new Foo-x.y.z and move issues from
Foo-Next into it. In our environment, we prefer to have to cycle
through the issues each time since we're customer driven and not
development driven.
This allows us to track what we feel are the three major categories of
issues: 1) issues scheduled for a specific release, 2) issues pending
scheduling, 3) future issues that may need more research or otherwise be
more appropriate for some future major version bump/rearchitecture
before scheduling is feasible.
For what it's worth.
-Paul
Ted Husted wrote:
> On 12/1/05, Don Brown <mr...@twdata.org> wrote:
>
>>Step 2:
>> - Move closed tickets included in soon-to-be-released projects to their
>>milestone.
>> - Wade through TBD tickets and assign to milestones
>>
>>While I like Martin's idea of only putting tickets to milestones when someone
>>commits to resolving them, I'm afraid it would distort the roadmap by giving the
>>wrong impression that we are always close to a release. Perhaps we could start
>>using the "Assigned" field more often to mark which ones have been taken up and
>>which are just hanging.
>
>
> I'd be more concerned about giving people the wrong impression that
> someone is going to resolve the ticket before the next release.
>
> IMHO, if a committer assigns a ticket to a milestone, then that
> committer is saying he or she is going to make it so.
>
> :) Otherwise, we have a situation where someone who is not planning to
> do the work is making the decision :)
>
> And, if the bugs are resolved, we *should* always be close to a
> release. In 1.0 to 1.1 era, we were always saying "let's get this one
> last feature in before we release". I don't think that worked well for
> us. If we start setting tickets to milestones when there is not a
> volunteer ready, willing, and able to work on the ticket, we're
> falling back into the old pattern that says a release has to be big to
> be worthwhile.
>
> Hey, I'd be in favor of releasing after any ticket is resolved. Fix a
> bug, add a feature, roll a release -- works for me!
>
> If we end up with milestones like 2.3.52, then so be it. MySQL does
> that, and I never blinked.
>
> -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: Milestones proposal: Step 1 (revised)
Posted by Martin Cooper <ma...@apache.org>.
On 12/2/05, Ted Husted <te...@gmail.com> wrote:
>
> On 12/1/05, Don Brown <mr...@twdata.org> wrote:
> > Step 2:
> > - Move closed tickets included in soon-to-be-released projects to
> their
> > milestone.
> > - Wade through TBD tickets and assign to milestones
> >
> > While I like Martin's idea of only putting tickets to milestones when
> someone
> > commits to resolving them, I'm afraid it would distort the roadmap by
> giving the
> > wrong impression that we are always close to a release. Perhaps we
> could start
> > using the "Assigned" field more often to mark which ones have been taken
> up and
> > which are just hanging.
>
> I'd be more concerned about giving people the wrong impression that
> someone is going to resolve the ticket before the next release.
>
> IMHO, if a committer assigns a ticket to a milestone, then that
> committer is saying he or she is going to make it so.
>
> :) Otherwise, we have a situation where someone who is not planning to
> do the work is making the decision :)
Exactly. That was the reasoning behind suggesting this. We've been in this
situation before (and are probably still in it!) where we've written down a
roadmap, and assigned features to specific dot releases. What's actually
happened, not surprisingly, is that what got done was what people wanted to
work on, not what we originally thought were good plans for a roadmap.
And, if the bugs are resolved, we *should* always be close to a
> release. In 1.0 to 1.1 era, we were always saying "let's get this one
> last feature in before we release". I don't think that worked well for
> us.
Gosh, that sounds just like my day job. ;-)
If we start setting tickets to milestones when there is not a
> volunteer ready, willing, and able to work on the ticket, we're
> falling back into the old pattern that says a release has to be big to
> be worthwhile.
Or that the milestone attached to an issue doesn't really mean anything...
Hey, I'd be in favor of releasing after any ticket is resolved. Fix a
> bug, add a feature, roll a release -- works for me!
It might work for me if the release process was completely automated and
foolproof, but I think we're still a long way from that. ;-)
--
Martin Cooper
If we end up with milestones like 2.3.52, then so be it. MySQL does
> that, and I never blinked.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Milestones proposal: Step 1 (revised)
Posted by Ted Husted <te...@gmail.com>.
On 12/1/05, Don Brown <mr...@twdata.org> wrote:
> Step 2:
> - Move closed tickets included in soon-to-be-released projects to their
> milestone.
> - Wade through TBD tickets and assign to milestones
>
> While I like Martin's idea of only putting tickets to milestones when someone
> commits to resolving them, I'm afraid it would distort the roadmap by giving the
> wrong impression that we are always close to a release. Perhaps we could start
> using the "Assigned" field more often to mark which ones have been taken up and
> which are just hanging.
I'd be more concerned about giving people the wrong impression that
someone is going to resolve the ticket before the next release.
IMHO, if a committer assigns a ticket to a milestone, then that
committer is saying he or she is going to make it so.
:) Otherwise, we have a situation where someone who is not planning to
do the work is making the decision :)
And, if the bugs are resolved, we *should* always be close to a
release. In 1.0 to 1.1 era, we were always saying "let's get this one
last feature in before we release". I don't think that worked well for
us. If we start setting tickets to milestones when there is not a
volunteer ready, willing, and able to work on the ticket, we're
falling back into the old pattern that says a release has to be big to
be worthwhile.
Hey, I'd be in favor of releasing after any ticket is resolved. Fix a
bug, add a feature, roll a release -- works for me!
If we end up with milestones like 2.3.52, then so be it. MySQL does
that, and I never blinked.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Milestones proposal: Step 1 (revised)
Posted by Don Brown <mr...@twdata.org>.
Incorporating the helpful feedback, here are the revised step 1 changes:
Milestone changes
- Add a "TBD" milestone
- Remove all "Family" milestones and move their bugs to "TBD"
- Rename "(.*) Milestone" to \1 (redundant w/o the family ones)
- Add milestones: 1.2.7, 1.2.8, 1.2.9, 1.3.1, 1.4.0, 1.0.0, 1.0.2, 1.1.0, 0.9
Component changes
- Rename the BSF component to Scripting
- Add "Action" component
- Remove the following components and move their bugs to Action:
Controller, Validator Framework, Digester, Documentation, File Upload,
Test, Utilities and move their bugs to Action component
- Rename the Custom Tags to Taglibs
- Rename Examples as Apps
- Rename Standard Actions to Extras
- Rename Struts Flow to Flow
- Rename Struts-Faces Library to Faces
- Rename Tiles framework to Tiles
If we add the "TBD" milestone, I encourage everyone to only add tickets to it if
it is a clear, reachable goal that we want to achieve. While I'm afraid it will
attract stagnant tickets no one cares about, I understand some folks find it
useful, and I'm usually wrong anyways :)
Next, I see the following steps:
Step 2:
- Move closed tickets included in soon-to-be-released projects to their
milestone.
- Wade through TBD tickets and assign to milestones
While I like Martin's idea of only putting tickets to milestones when someone
commits to resolving them, I'm afraid it would distort the roadmap by giving the
wrong impression that we are always close to a release. Perhaps we could start
using the "Assigned" field more often to mark which ones have been taken up and
which are just hanging.
Step 3: Vote on moving to JIRA. I have this last, because I want to capitalize
on the consensus we've achieved here before we start a new debate. :)
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Milestones proposal: Step 1
Posted by Craig McClanahan <cr...@apache.org>.
On 11/30/05, Don Brown <mr...@twdata.org> wrote:
>
> I take it the "Target tickets to milestones" proposal passed, and thanks
> for all the feedback. As the first step, could Martin or Craig please
> make the following Bugzilla changes:
>
> Milestone changes
> - Remove all "Family" milestones
> - Rename "(.*) Milestone" to \1 (redundant w/o the family ones)
> - Add milestones: 1.2.7, 1.2.8, 1.2.9, 1.0.0, 1.0.2, 0.9
>
> Component changes
> - Rename the BSF component to Scripting
> - Add "Action" component
> - Remove the following components and move their bugs to Action:
> Controller, Validator Framework, Digester, Documentation, File Upload,
> Test, Utilities and move their bugs to Action component
> - Rename the Custom Tags to Taglibs
> - Remove EL and move to Taglibs
> - Rename Examples as Apps
> - Rename Standard Actions to Extras
> - Rename Struts Flow to Flow
> - Rename Struts-Faces Library to Faces
> - Rename Tiles framework to Tiles
>
> I think these changes will make Bugzilla match our project better, and
> the milestones, since they have to be shared between all subprojects,
> will probably grow quickly with time. Next, I'll start going through
> closed tickets and marking them against milestones. Help of course is
> appreciated.
+1 on the changes in general, and thanks to Martin for being willing to do
the grunt work involved.
Regarding milestones, I kinda like the "TBD" label that Sean mentioned is
used in MyFaces for stuff that is "yah, we probably want to do this, but
don't know quite yet at this point." -- that seems to give correct
implications that the ticket has been accepted (versus rejected as WONTFIX),
but is not yet integrated into the schedule.
Thanks,
>
> Don
Craig