----- Original Message ----

> From: David Lutterkort <lut...@redhat.com>
> To: general@incubator.apache.org
> Sent: Wed, September 15, 2010 7:33:45 PM
> Subject: Re: Accepting patches in a podling
> 
> On Tue, 2010-09-14 at 04:22 +0200, Daniel Shahaf wrote:
> > FWIW, what  Subversion uses:
> > 
> >  
>http://subversion.apache.org/docs/community-guide/community-guide.html#patches
> > 
>http://subversion.apache.org/docs/community-guide/community-guide.html#patch-manager
>
> > ; 
> > Briefly, all patches go to dev@, and only the unlucky patches  that
> > were neither applied nor rejected get stashed in the issue  tracker
> > to avoid being dropped on the floor.
> 
> This seems a very  workable approach - going through Jira for everything
> is too much work on the  part of the contributer. I'll use that as the
> submission policy for  Deltacloud from now on:
> 
>       * Patch submittes must have  a CLA on file

Well IMO this should only be a requirement for "substantial" changes.
Minor bugfixes and such aren't even copyrightable, so just take them
if they're posted to the list without disclaimers.  If you use reasonable
judgement about minor changes, you don't need to burden an occasional
contributor with any paperwork- the license ensures your actions are
defensible.

>       * Patches need to go to the dev@ list (and  be ACK'd there)
>       * In some cases, we might ask the  submitter to put the patch into
>         Jira (e.g., for  large contributions)
> 
> Only tangentially related: is there a way to make  subversion (especially
> via git-svn) distinguish between a committer and an  author ? That would
> help keep the patch submission trail much more  transparent.

With cvs we used to have a way of formatting log messages to indicate
independent authorship.  Unfortunately there is no such thing available
with subversion, so you can be a bit creative in how you denote authorship
in the log message.


      

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to