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 20:49:02 UTC
Commit template (was [PROPOSAL] Target tickets to milestones and
use as roadmap)
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: 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