For example, this commit should have had a JIRA, and the commit it reverts had a JIRA listed. However, looking at the commit tab on that JIRA in future there will be no indication this revert occured.
"URL: http://svn.apache.org/viewvc?rev=1068417&view=rev Log: Reverts r1068042. We will fix this bug in the C++ client messaging library rather than the broker." Robbie On 8 February 2011 15:15, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: <snip> > We could allow certain things through the hook, eg putting NO-JIRA in > the commit log bypasses it. That could presumably also be stripped by > the hook on success, and be indicated in any failure message to ensure > people always know its an option. That way its still possible to > commit without a JIRA, but makes doing so a conscious decision to > subvert the JIRA process. It also takes accidental ommision out the > picture </snip> > > On 8 February 2011 14:07, Rajith Attapattu <rajit...@gmail.com> wrote: >> On Tue, Feb 8, 2011 at 8:14 AM, Robbie Gemmell >> <robbie.gemm...@gmail.com>wrote: >> >>> I largely agree with Rajith as shown by my commit history, there are >>> some changes I dont think warrant a JIRA such as random litle README >>> or website changes (however, larger documentation changes should >>> generally be associated with a JIRA because surely they are >>> documenting something that was implemented or fixed). >>> >> >> Agreed ! >> Some of the documentation changes are prompted by bug fixes or new features >> being added. >> In such cases it's best to include the svn commit for doc changes under the >> original JIRA created for the bug or new feature. >> As a group we have been historically bad when it comes to keeping our docs >> in sync with the code. >> (All though separate discussion, I think Release managers should not allow a >> JIRA to be marked resolved if they feel it needs documentation updates.) >> >> I think we need to have a commit hook that displays a friendly message >> reminding folks to include a JIRA number and update the docs if necessary. >> That IMO is better than one that blocks a commit bcos there is no JIRA in >> the commit log. >> >> When people keep seeing the same message every time they commit, it will >> eventually sink in :) >> >> Rajith. >> >> >>> The problem defining where that line is and then not crossing it; >>> results suggest we have proven absolutely incapable of doing that as a >>> group so far. Also, as mentioned there are tools such as the JIRA >>> commit list that require a JIRA tag in order to work at all; it would >>> be good for everything to be visible there. >>> >>> There should be a minimal amount of cases that would be warranted to >>> forego a JIRA, to the extent that id rather just enforce 100% JIRA >>> creation to stop there being any room for doubt or getting lazy. They >>> dont always have to be new JIRAs, as Andrew suggested some of them >>> could be short term umbrella JIRAs, eg 'Release preperation readme >>> cleanup' etc. It doesnt take long to create a short but descriptive >>> titled JIRA. >>> >>> Robbie >>> >>> On 7 February 2011 16:55, Rajith Attapattu <rajit...@gmail.com> wrote: >>> > On Mon, Feb 7, 2011 at 11:15 AM, Jonathan Robie >>> > <jonathan.ro...@redhat.com>wrote: >>> > >>> >> I'm also a repeat offender. I'll create the missing JIRAs and do better >>> >> going forward. >>> >> >>> >> Question: I have some commits that I think are quite minor, fixing a >>> >> README, whitespace, etc. I assume I don't need a JIRA for that kind of >>> >> thing? >>> >> >>> > >>> > IMO I don't think you need a JIRA for trivial things like that. >>> > However when you commit code it's best to have a JIRA. >>> > 95% of the commits done in actual code are either bug fixes or new >>> features >>> > or things that sort of sit in btw and I thing we need a JIRA for those. >>> > The other 5% are probably fixing typos, documentation, cleaning up etc.. >>> can >>> > probably go in without a JIRA. >>> > >>> > If you are fixing a bug, then even if it's just a one line commit, it's >>> > really important to create a JIRA. >>> > Also updating those JIRA's with release info is very important as well. >>> > If not we really don't know what we fixed in each release. >>> > >>> > >>> > >>> >> >>> >> Jonathan >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> Apache Qpid - AMQP Messaging Implementation >>> >> Project: http://qpid.apache.org >>> >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >>> >> >>> >> >>> > >>> > >>> > -- >>> > Regards, >>> > >>> > Rajith Attapattu >>> > Red Hat >>> > http://rajith.2rlabs.com/ >>> > >>> >>> --------------------------------------------------------------------- >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:dev-subscr...@qpid.apache.org >>> >>> >> >> >> -- >> Regards, >> >> Rajith Attapattu >> Red Hat >> http://rajith.2rlabs.com/ >> > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
