Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> JIRA Patch Conventions


Copy link to this message
-
Re: JIRA Patch Conventions
#2 as well.
On Wed, Apr 24, 2013 at 11:08 AM, John Vines <[EMAIL PROTECTED]> wrote:

> I too am in favor of the patch history being available.
>
>
> On Wed, Apr 24, 2013 at 11:07 AM, Billie Rinaldi
> <[EMAIL PROTECTED]>wrote:
>
> > I like #2 as well. Here's a quote from the incubator list confirming that
> > we don't need ICLAs for patches.
> >
> > > Under the terms of the AL, any contribution made back to the ASF on
> > > ASF infrastructure, such as via a mailing list, JIRA, or Bugzilla, is
> > > licensed to the foundation. The JIRA checkbox existed to give people
> > > an easy way to _avoid_ contributing something. There is no need to ask
> > > casual patchers for ICLAs.
> > On Apr 24, 2013 10:05 AM, "Josh Elser" <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On 4/24/13 9:32 AM, Keith Turner wrote:
> > >
> > >> On Tue, Apr 23, 2013 at 11:51 PM, Mike Drob <[EMAIL PROTECTED]> wrote:
> > >>
> > >>  Accumulo Devs,
> > >>>
> > >>> Are there any conventions that we'd like to follow for attaching
> > updated
> > >>> patches to issues? There are two lines of thought applicable here:
> > >>>
> > >>> 1) Remove the old one and attach the new patch. This has the
> advantage
> > of
> > >>> being immediately obvious to future google searchers what the patch
> > was,
> > >>> especially in case of back porting issues.
> > >>> 2) Leave all patches attached to the ticket, and use a one-up
> > identifier
> > >>> for each subsequent patch. This preserves context from comments, and
> > >>> might
> > >>> be useful in other ways.
> > >>>
> > >>
> > >>  I've seen both approaches used on Accumulo tickets, and don't have a
> > >>> strong
> > >>> preference outside of a desire for consistency. I think I'd lean
> > towards
> > >>> option #2, if only because that means I get one fewer email
> > notification.
> > >>>
> > >>>  I agree I would like consistency.   I lean towards 2 also, but I do
> > not
> > >> have a good reason, its just my preference.  We should probably put
> > >> together a page outlining how to submit a patch.  I have seen other
> > >> projects do this.
> > >>
> > > Ditto.
> > >
> > >>
> > >>  As an aside, what is the IP status of submitted patches? I think I
> > >>> remember
> > >>> hearing that they immediately become part of the Apache Foundation,
> so
> > >>> removing them might be a bad idea from that perspective.
> > >>>
> > >>>  Does someone who is submitting patches need to submit an ICLA?
> > >>
> > > I believe they just need to be capable of assigning the copyright to
> the
> > > ASF (as in, an employer does not hold rights to the patch). I believe
> the
> > > ICLA is more for the case of a committer being able to use SVN (and not
> > > having the jira checkbox).
> > >
> > >>
> > >>
> > >>  Mike
> > >>>
> > >>>
> > >
> >
>

--
Corey Nolet
Senior Software Engineer
TexelTek, inc.
[Office] 301.880.7123
[Cell] 410-903-2110
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB