maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: commit logs (svn commit: r365696)
Date Thu, 05 Jan 2006 01:08:28 GMT
Brett Porter wrote:
> Jason van Zyl wrote:
>> That's not a problem, and we can try to get everything useful in a
>> single line for things like Mylar.
> I didn't know it needed a single line? That might make it harder to
> read, but we can look into it.

It will take more, it's just the one line summary view makes it easier 
to see things. I got a short demo from Eugene and have only played with 
it for a few minutes myself.

>> If you actually look at the way Mylar works it pulls everything in from
>> JIRA using URLs. 
> It's a shame they don't recognise numbers/ids and link them up through
> some configuration.

It might be able to, but while I was watching Eugene a browser was 
coming up inside a view, that's how Mylar integrated with JIRA and 
Bugzilla. I'm sure it wouldn't take much to give it the base url.

>> I'm not sure I see that as important provided you have navigation back
>> to the issue. Whether that be typing in the key or using the URL. If
>> we're going to populate contributors elements it would probably make
>> more sense to take them from the source in JIRA and not from second hand
>> information. You probably want the users full information for a
>> contributor element and JIRA has more information.
> I don't consider JIRA the authoratative source here. You often don't use
> a patch, or use one and not the other, or something altogether
> different. 

Ok, I figured a contributor was someone who contributed a patch. But 
whatever they contributed should be in the issue tracking system, stored 
in a way we can link back to it. JIRA doesn't really work very well for 
this but a custom field in conjunction with the patch submission plugin 
could probably get the correct information. It's captured upfront in 
JIRA and we should put the information there to use in something like 
the scm message as opposed to multiple places.

Sure, we might use JIRA to get more details (which is really
> only the email address), but I think we need to be recording the authors
> in SVN.

Sure, the author being the contributor of the patch. That should be 
captured in JIRA to be resused elsewhere. Most of the time it is the 
reporter but a custom field(s) would be better where you could 
definitively get the author of the patch.

>> MNG-2010 implemented the maven mind reader to pre-write all user
>> documentation requests
>> The url can be optional. I use it all the time and I know it would be
>> useful in Mylar.
> This is fine with me (I wouldn't necessarily use the JIRA summary which
> is often crap, but would want to type my own comment). 

Fair enough. It should be good enough but often times is not.

> I still think the
> submitter of patches is important and could be a second line. I might
> ping legal-discuss to check if we actually have a requirement to capture
> this in SVN.

I think it needs to be captured, but I think the issue management system 
is the place for it. Whether you pull it automatically or cut and paste 
it into the message.

> Thanks :)
> - Brett
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
jason at

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

  -- Buddha

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message