lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <mhern...@wickedsoftware.net>
Subject Re: [Lucene.Net] Procedure for Commiting
Date Mon, 14 Mar 2011 18:38:09 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message