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 goodthing.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 forcommits that don't merit a full issue of their own. Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc.______________________________________________________________________ _ 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-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 8:50 AM To: [email protected] 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 someoutsidetooling 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, butthat won'talways be the case with committers. I am logged into JIRA. Isthere someother 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.htmlDo we know if this is available for our SVN/JIRA setup withinApache?Having the extra tab with the corresponding file adds,deletes, andmodifies would be nice.Absolutely Apache JIRA do have this installed. Take a look atthe bugOPENJPA-3 below that has a checkin associated. What I don'tknow iswhether they offer "forced JIRA" on every checkin. CraigKevin On 8/17/06, Craig L Russell <[EMAIL PROTECTED]> wrote:Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key isto includetheproject-issue as the first characters of the commitmessage.ThenJIRA will magically (ask infrastructure) pick up thecommit andupdate 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.javaBut to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote:Hi, Looking for some guidance from more experienced Apachedevelopers...Is there a means of enforcing the SVN commit process toinclude aJIRA bug or enhancement number so that the code changes areassociatedwiththat particular bug or enhancement? I searched somemailing listarchives and found that the Apache Logging project at leastinvestigated thisprocess, but I couldn't tell if it turned into somethingreal or not.Don't know. Would be nice.I know there are tools like SCMBug which providesomethinglikethis..Specifically, I would like to enforce rules similar to thefollowing:o Enforces that you specify a bug id [#nnnnn] will allcommits toSVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits thatis atleast 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 bugexistsand is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage ofSVN andJIRA?And, if this is configurable, would OpenJPA beinterested inenforcing this type of mechanism? I've used these type ofprocesses withotheropen-source projects and found the history useful whenreviewing old bugreports. I'd be interested in enforcing some of these rules. Myexperiencewith this kind of enforcement is that it's justanother processhoopto jump through, and while some developers find itstifling, Ifindit good to have some additional structure. But first things first. Is there an enforcement arm of svn? CraigThanks, KevinCraig 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 Systemhttp://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!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!
smime.p7s
Description: S/MIME cryptographic signature
