You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2008/01/21 21:39:36 UTC
Two methodological proposals
1) If you find a bug that a user might find, make a JIRA, even if you
are fixing it on the spot. This allows users of the previous release to
find it in JIRA.
2) If you fix a bug, add some remark to the JIRA as to the nature of the
bug and the fix.
Re: Two methodological proposals
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 21 January 2008, Benson Margulies wrote:
> > Still, I haven't had time much for commits, but I'll be more liberal
> > in my usage of JIRA if you would like. Trivial matters (spelling
> > fixes and the like), I will continue to not bother with JIRA,
> > however. If you wish to type in a JIRA over minor changes of that
> > nature you are most welcome, but I suspect you'll get bored of doing
> > so after awhile. All in all, working code is more important than
> > beautiful documentation.
>
> I never intended to ask for that level of minutia. It's the big, bad,
> bugs I'm after.
Yea. For the most part, if I'm digging through something and find a
bug, I log a JIRA for two types of things:
1) Something I don't have time to fix right now. That's important to
get logged so it doesn't get lost.
2) Something a user is likely to hit through normal use of the product.
Those need to get logged so they can be searched/found. One popular
use of Jira is to "watch" a bug to see when things are fixed, any
discussion, etc.... If someone does say on the list "why is this not
working", you can point them at the JIRA item.
For the trivial spelling things, javadoc, basic code cleanup/reorg
things, etc.... don't really need JIRA's. It's mostly the things
users may encounter and track.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Two methodological proposals
Posted by Glen Mazza <gl...@verizon.net>.
Am Montag, den 21.01.2008, 21:04 -0500 schrieb Benson Margulies:
> > Still, I haven't had time much for commits, but I'll be more liberal in
> > my usage of JIRA if you would like. Trivial matters (spelling fixes and
> > the like), I will continue to not bother with JIRA, however. If you
> > wish to type in a JIRA over minor changes of that nature you are most
> > welcome, but I suspect you'll get bored of doing so after awhile. All
> > in all, working code is more important than beautiful documentation.
>
> I never intended to ask for that level of minutia. It's the big, bad,
> bugs I'm after.
>
>
Good! We're in full agreement then.
Glen
Re: Two methodological proposals
Posted by Benson Margulies <bi...@gmail.com>.
> Still, I haven't had time much for commits, but I'll be more liberal in
> my usage of JIRA if you would like. Trivial matters (spelling fixes and
> the like), I will continue to not bother with JIRA, however. If you
> wish to type in a JIRA over minor changes of that nature you are most
> welcome, but I suspect you'll get bored of doing so after awhile. All
> in all, working code is more important than beautiful documentation.
I never intended to ask for that level of minutia. It's the big, bad,
bugs I'm after.
Re: Two methodological proposals
Posted by Glen Mazza <gl...@verizon.net>.
Am Montag, den 21.01.2008, 19:34 -0500 schrieb Benson Margulies:
> On Mon, 2008-01-21 at 19:25 -0500, Glen Mazza wrote:
> > I disagree with both. The CVS commit log, not JIRA, is the
> > authoritative source of changes made to the product, anyone who needs
> > that level of detail can go through those logs. JIRA is for bugs not
> > fixed yet.
>
> Glen,
>
> I'm more interested in defending the first than the second.
> User hits problem. What do we want user to do? Search JIRA and see if it
> is a known problem. We don't expect users to search the svn commit logs.
>
Normally users check the user mailing list archives, and if nothing is
found there, ask a question on the mailing list. Nothing is 100%, but
if the issue has been fixed in the latest version, someone will probably
open their mouth and the person will be informed. They may even get
more information on the matter by asking on the user list, because the
response can be customized to their problem.
A JIRA search, even under the best of circumstances, would probably only
provide an 80% success rate of seeing if something changed. Those who
*really* need to know if a class changed would still need to search the
svn logs or use ViewVC to check file change history.
Still, I haven't had time much for commits, but I'll be more liberal in
my usage of JIRA if you would like. Trivial matters (spelling fixes and
the like), I will continue to not bother with JIRA, however. If you
wish to type in a JIRA over minor changes of that nature you are most
welcome, but I suspect you'll get bored of doing so after awhile. All
in all, working code is more important than beautiful documentation.
Regards,
Glen
> --benson
>
>
Re: Two methodological proposals
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, 2008-01-21 at 19:25 -0500, Glen Mazza wrote:
> I disagree with both. The CVS commit log, not JIRA, is the
> authoritative source of changes made to the product, anyone who needs
> that level of detail can go through those logs. JIRA is for bugs not
> fixed yet.
Glen,
I'm more interested in defending the first than the second.
User hits problem. What do we want user to do? Search JIRA and see if it
is a known problem. We don't expect users to search the svn commit logs.
--benson
Re: Two methodological proposals
Posted by Glen Mazza <gl...@verizon.net>.
I disagree with both. The CVS commit log, not JIRA, is the
authoritative source of changes made to the product, anyone who needs
that level of detail can go through those logs. JIRA is for bugs not
fixed yet.
Glen
Am Montag, den 21.01.2008, 15:47 -0500 schrieb Daniel Kulp:
> On Monday 21 January 2008, Benson Margulies wrote:
> > 1) If you find a bug that a user might find, make a JIRA, even if you
> > are fixing it on the spot. This allows users of the previous release
> > to find it in JIRA.
>
> +1
> This also makes the release notes much more accurate. The release notes
> are based on the JIRA entries and having a fairly complete picture is
> important.
>
>
> > 2) If you fix a bug, add some remark to the JIRA as to the nature of
> > the bug and the fix.
>
> Well, I'm not sure if that is necessary. If you put the JIRA number in
> the commit message and describe it there, it will automatically appear
> in the "Subversion" tag of the JIRA instance.
>
>
Re: Two methodological proposals
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 21 January 2008, Benson Margulies wrote:
> 1) If you find a bug that a user might find, make a JIRA, even if you
> are fixing it on the spot. This allows users of the previous release
> to find it in JIRA.
+1
This also makes the release notes much more accurate. The release notes
are based on the JIRA entries and having a fairly complete picture is
important.
> 2) If you fix a bug, add some remark to the JIRA as to the nature of
> the bug and the fix.
Well, I'm not sure if that is necessary. If you put the JIRA number in
the commit message and describe it there, it will automatically appear
in the "Subversion" tag of the JIRA instance.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog