lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Lombard" <lombardena...@gmail.com>
Subject RE: [Lucene.Net] Procedure for Commiting
Date Mon, 14 Mar 2011 23:01:47 GMT
The only problem I found with the JIRA commit log is that if you also
reference a Java Lucene issue it will be referenced in their JIRA as well.
I have been using a space instead of a dash.  Example LUCENE-222 would be
LUCENE 222.

Scott

> -----Original Message-----
> From: Troy Howard [mailto:thoward37@gmail.com]
> Sent: Monday, March 14, 2011 5:16 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Procedure for Commiting
> 
> I like the CTR workflow, but ensure that all commits have an
> associated JIRA item in the commit log so that it's tracked in JIRA
> correctly via the commits tab.
> 
> I also recently asked Infra to set us up with ReviewBoard (see
> reviews.apache.org)... However this tool is focused on RTC style
> workflow. We could use a combination depending on the situation.
> 
> Thanks,
> Troy
> 
> 
> On Mon, Mar 14, 2011 at 1:24 PM, Digy <digydigy@gmail.com> wrote:
> > OK, you are right. I didn't know this tab. I must have missed this
> feature
> > with the new version of JIRA(even I don't recall surely whether it was
> > available in previous version or not :) ).
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Lombard, Scott [mailto:slombard@KINGINDUSTRIES.COM]
> > Sent: Monday, March 14, 2011 8:44 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: RE: [Lucene.Net] Procedure for Commiting
> >
> > Yes it does.  Under the issue you can find a tab Subversion Commits.
> >
> > Scott
> >
> >
> >> -----Original Message-----
> >> From: Michael Herndon [mailto:mherndon@wickedsoftware.net]
> >> Sent: Monday, March 14, 2011 2:38 PM
> >> To: lucene-net-dev@lucene.apache.org
> >> Cc: Digy
> >> Subject: Re: [Lucene.Net] Procedure for Commiting
> >>
> >> Is Jira not currently setup to track the commit messages with the
> >> referenced
> >> ticket number in them?
> >>
> >> On Mon, Mar 14, 2011 at 12:59 PM, Digy <digydigy@gmail.com> wrote:
> >>
> >> > I don't know what others think, but I find it more trackable to see
> the
> >> > issues and related patches in one place(JIRA)
> >> > (especially, while trying to understand what was done for a specific
> >> issue;
> >> > after many months)
> >> >
> >> > DIGY
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> >> > Sent: Monday, March 14, 2011 5:41 PM
> >> > To: lucene-net-dev@lucene.apache.org
> >> > Subject: Re: [Lucene.Net] Procedure for Commiting
> >> >
> >> > On 2011-03-14, Scott Lombard wrote:
> >> >
> >> > > I wanted to get a final agreement on how we want to handle commits
> to
> >> the
> >> > > repository.  There have been discussions in a couple of different
> >> threads
> >> > > about this topic.  I know patches, branches and just go for it has
> >> been
> >> > > discussed and different people have different ideas.  I just wanted
> to
> >> > know
> >> > > what the group thinks is the way to handle commits in our project.
> >> >
> >> > Inside the ASF we have varying ideas about how to handle it.
> >> >
> >> > Many if not most projects use commit-then-review (CTR[1]) as their
> main
> >> > model where you just commit and your peers review it later (that's
> why
> >> > the commits mailing list exists).  This is probably the quickest way
> to
> >> > move forward but may lead to slipped-through problems.
> >> >
> >> > At the other extreme there are projects that require JIRA items for
> each
> >> > and every commit with automated pre-build CI checks that reject
> patches
> >> > attached to JIRA tickets if they break the
> >> > build/tests/coding-standards/whatever[2].  This is probably the
> "safe"
> >> > way but may keep people from contributing because the effort to get a
> >> > patch in seems to big.
> >> >
> >> > Other projects live in some sort of middle ground where some branch
> is
> >> > open for CTR and other branches (the "stable" branch) requires
> >> > review-then-commit (RTC[3]).  Many projects have written down
> policies
> >> > like Hadoop which I've already cited or Solr[4].
> >> >
> >> > I guess what I'm trying to say is there is no policy that would force
> >> > you to do it one way or the other, it is your decision.
> >> >
> >> > Stefan
> >> >
> >> > [1] http://www.apache.org/foundation/glossary.html#CommitThenReview
> >> >
> >> > [2] http://wiki.apache.org/hadoop/HowToContribute
> >> >
> >> > [3] http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >> >
> >> > [4] http://wiki.apache.org/solr/CommitPolicy
> >> >
> >> >
> >
> >
> > This message (and any associated files) is intended only for the
> > use of the individual or entity to which it is addressed and may
> > contain information that is confidential, subject to copyright or
> > constitutes a trade secret. If you are not the intended recipient
> > you are hereby notified that any dissemination, copying or
> > distribution of this message, or files associated with this message,
> > is strictly prohibited. If you have received this message in error,
> > please notify us immediately by replying to the message and deleting
> > it from your computer.  Thank you, King Industries, Inc.
> >
> >


Mime
View raw message