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/02 00:17:08 UTC
Milestones proposal: Step 1 (revised)
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 (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