I like the idea of having a pre-cooked jira that we keep open for the purpose. I'd refine it a bit by having it specific to the next release we're planning, so one jira for code formatting issues on 0.9; another for rewriting logic to remove contorted logic (e.g. turning 5 if-then-else into 2); another for javadoc cleanup for 0.9; another for documentation on 0.9.

I'm a little more nervous about "things that are wrong" unless we make it clear that it's only things that have no externally visible behavior. These should have real bug numbers and descriptions that users can search.

Craig

On Aug 18, 2006, at 12:12 PM, Patrick Linskey wrote:

At BEA, we have a rule that a commit message must either begin with
'CR######' (CR stands for change request, BEA's word for issue, and ###### is a sequence of numbers) or 'No CR'. I rather like this convention. I often come across things in code that are wrong or are non-optimal that I fix in the course of doing unrelated work. I imagine that if I had to create a JIRA issue, I'd just not make the change. So, I think that a system that allows for small changes to be made without a corresponding issue would be a good
thing.

I guess one way to acheive this would be to have a pre-built set of JIRA issues for these sorts of things -- one for fixing code formatting, one for minor potential algorithm problems, etc. Then, that issue could be used for
commits that don't merit a full issue of their own.

Thoughts?

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 8:50 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: JIRA bug tracking of code changes

I have asked the question on infrastructure@, but we might also find
out if the others on openjpa want to have enforcement of JIRA issue
on commits.

What do you all think?

Craig

On Aug 18, 2006, at 8:34 AM, Kevin Sutter wrote:

That did the trick, Craig.  Thanks!

Now that we are on the same page, we're back to your original
question of
whether this is enforceable or not.  (And, if we even to make this
enforceable.)  I would guess that we have to revert to some
outside
tooling
such as SCMBug to make this enforceable.

Kevin

On 8/18/06, Craig L Russell <[EMAIL PROTECTED]> wrote:

Hi Kevin,

You should be able to see svn now.

I added you to openjpa-developers (you need this anyway).

I added jira-users to permissions to see svn checkins. (Actually,
this should be the default for all svn checkins for the Apache
installation. I've made a note).

Try it now.

Craig

On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote:

Craig,
I must be blind or something.  I looked at OPENJPA-3 before and I
don't see
the "change history".  I see the attached diff file, but
that won't
always
be the case with committers.  I am logged into JIRA.  Is
there some
other
configuration that I need to do to view these changes?

Thanks,
Kevin

On 8/18/06, Craig L Russell <[EMAIL PROTECTED]> wrote:

Hi Kevin,

On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote:

As a start, it would be good if we had this plugin support:

http://www.atlassian.com/software/jira/docs/v3.2/
svn_integration.html

Do we know if this is available for our SVN/JIRA setup within
Apache?
Having the extra tab with the corresponding file adds,
deletes, and
modifies
would be nice.

Absolutely Apache JIRA do have this installed. Take a look at
the bug
OPENJPA-3 below that has a checkin associated. What I don't
know is
whether they offer "forced JIRA" on every checkin.

Craig

Kevin

On 8/17/06, Craig L Russell <[EMAIL PROTECTED]> wrote:

Hi Kevin,

SVN does have a tie-in to JIRA at Apache. The key is
to include
the
project-issue as the first characters of the commit
message.
Then
JIRA will magically (ask infrastructure) pick up the
commit and
update the issue for you.

http://issues.apache.org/jira/browse/OPENJPA-3

svn commit -m "Brett Porter's patch to resolve OPENJPA-3"
openjpa-
lib/
src/test/java/org/apache/openjpa/lib/util/
TestPropertiesParser.java

But to answer your other questions,

On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote:

Hi,
Looking for some guidance from more experienced Apache
developers...

Is there a means of enforcing the SVN commit process to
include a
JIRA bug
or enhancement number so that the code changes are
associated
with
that
particular bug or enhancement?  I searched some
mailing list
archives and
found that the Apache Logging project at least
investigated this
process,
but I couldn't tell if it turned into something
real or not.

Don't know. Would be nice.

I know there are tools like SCMBug which provide
something
like
this..
Specifically, I would like to enforce rules similar to the
following:

o Enforces that you specify a bug id [#nnnnn] will all
commits to
SVN (or,
whatever syntax works with JIRA)
o Enforces that you specify a comment with all commits that
is at
least 10
characters long (or, some arbitrary length)
o Enforces that you have a valid user ID with the Tracker
o Enforces that you have specified a valid bug id (the bug
exists
and is in
the proper state, e.g. not CLOSED or CANCELLED)

Is this configurable with Apache projects usage of
SVN and
JIRA?

And, if this is configurable, would OpenJPA be
interested in
enforcing this
type of mechanism?  I've used these type of
processes with
other
open-source
projects and found the history useful when
reviewing old bug
reports.

I'd be interested in enforcing some of these rules. My
experience
with this kind of enforcement is that it's just
another process
hoop
to jump through, and while some developers find it
stifling, I
find
it good to have some additional structure.

But first things first. Is there an enforcement arm of svn?

Craig

Thanks,
Kevin

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/
products/
jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!





Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/
products/
jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!





Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/
jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!





Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!


______________________________________________________________________ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this
by email and then delete it.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to