falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajay Yadav <ajayn...@gmail.com>
Subject Re: [DISCUSS] Alternative flow for committing patches
Date Sun, 11 Jan 2015 00:26:44 GMT
I agree that each contribution is being acknowledged and Srikanth has aptly
explained it. Just to add

   1. Being author of a commit is higher form of acknowledgement than being
   mentioned in the commit message which github  doesn't credit in
   contributor's name. It's a tiny psychological boost for new contributors :)
   Git provides special provision for this, why not use it?
   2. Preserving extended commit messages is harder in current approach as
   committers have to rewrite commit messages.


@Amareshwari,
I checked how git and linux projects handle that. For historical reasons
they use Signed-off-by for D.C.O (Developer's Certificate of Origin) issues
and for code review credits they use tag "Reviewed-by: Real Name of the
person<emailid>" at the end of the commit message. You can do that by
giving the command
git commit --amend
after you have applied the patch. Unfortunately, there is no flag to do
that automatically in git.


On Sat, Jan 10, 2015 at 10:14 PM, Srikanth Sundarrajan <sriksun@hotmail.com>
wrote:

> I guess @Ajay's point isn't about the acknowledgement of the contributors,
> which I guess is happening without any gaps as @Venkatesh has pointed out.
> It is more to do with the potential benefits of the proposed approach. From
> what I know, this is widely adopted and is increasingly the norm with git
> SCM based projects (including apache projects). Some apache examples for
> reference to consider
>
> https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute
> http://deltaspike.apache.org/suggested-git-workflows.html
> https://airavata.apache.org/community/how-to-commit-contributed-code.html
>
> https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
>
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-ContributorWorkflow
>
> +1 for the suggestion. The single biggest reason, I feel that this is
> worth considering is that the current approach squashes the commits.
>
> Regards
> Srikanth Sundarrajan
>
> > Date: Fri, 9 Jan 2015 09:45:43 -0800
> > Subject: Re: [DISCUSS] Alternative flow for committing patches
> > From: venkatesh@innerzeal.com
> > To: dev@falcon.apache.org
> >
> > Due credit is given to all contributors in the current approach and we
> make
> > sure contributor names are added in the commit message. I do not see what
> > is the issue?
> >
> > On Fri, Jan 9, 2015 at 3:28 AM, Ajay Yadav <ajaynsit@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Currently when we commit a patch, the git commit shows the commit in
> the
> > > name of the person who committed the patch to the trunk(committer) and
> by
> > > convention the committer mentions the name of the person who
> contributed
> > > the patch(contributor) in the commit message. Committers also need to
> make
> > > changes to CHANGES.txt to log the change for release notes etc. Git
> has a
> > > provision to distinguish between author(contributor) and the
> committer. I
> > > would like to propose another approach and hear your thoughts on this.
> > >
> > > Commit a patch using the following command
> > > git am falcon-652-v2.patch
> > >
> > > If you have reviewed the patch as well then use -s option and git will
> > > append Signed-off-by: with your git handle in the extended commit
> message.
> > >
> > > This command uses the commit metadata in the patch to create a commit.
> It
> > > also adds a metadata of "signed off by" using the handle of the
> committer
> > > who is applying the patch. This way the commit is in the name of the
> > > contributor and sign off is in the name of the committer who committed
> the
> > > patch.
> > >
> > > Please note
> > >
> > >    - Contributors will need to *squash* all commits into one before
> > >    submitting the patch. If a patch consists of two commits, the
> command
> > > will
> > >    create two commits in the trunk. *This behaviour is same as in a
> github
> > >    pull request.*
> > >    - Contributors will need to generate their patches using *git
> > >    format-patch* command and not using the git diff command.
> > >    - Contributors will also need to make the changes to CHANGES.txt
> > >
> > > *Pros:*
> > >
> > >    - Biggest pro of this approach is that author of commit is the
> person
> > >    who contributed this patch (this should compensate for the extra
> steps
> > > that
> > >    the contributors need to make).
> > >    - Commit messages will be more detailed and more relevant. Users
> can now
> > >    add extended commit messages explaining the changes in more details
> and
> > >    they will not be lost.
> > >    - Will make committing a patch easier for a committer (less in
> numbers
> > >    than contributors). Committers can use this approach to commit
> multiple
> > >    patches in one go.
> > >
> > >
> > >
> > > Cheers
> > > Ajay Yadava
> > >
> >
> >
> >
> > --
> > Regards,
> > Venkatesh
> >
> > “Perfection (in design) is achieved not when there is nothing more to
> add,
> > but rather when there is nothing more to take away.”
> > - Antoine de Saint-Exupéry
>
>

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