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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
