falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siva Tumma <sivatu...@gmail.com>
Subject Re: [DISCUSS] Alternative flow for committing patches
Date Tue, 13 Jan 2015 17:44:35 GMT
In my opinion git based pull requests work well.
People with read access to the repo fork, make changes, make pull requests.
The workaround of RAC is either way unavoidable at the committer's (your) end.
The current patch based workaround for me, reduces the interest of contributing.

Thanks for the OpenSource. Any Layman can sound like a professional.

> On 12-Jan-2015, at 11:29 am, Srikanth Sundarrajan <sriksun@hotmail.com> wrote:
> 
> @Shwetha, Airavat is probably not a good example. You might want to take a look at 
> 
> https://github.com/apache/kafka/commits/trunk
> https://github.com/apache/knox/commits/master
> 
> Commits across multiple pushes wont be interleaved as far as I know.
> 
> While we are on this topic, wanted to see if we can use git based pull requests. This
will make reviews seamless as well. But we will have to study if this can be done easily.
Some projects have moved to this model.
> 
> Regards
> Srikanth Sundarrajan
> 
>> From: shwethags@gmail.com
>> Date: Mon, 12 Jan 2015 11:19:17 +0530
>> Subject: Re: [DISCUSS] Alternative flow for committing patches
>> To: dev@falcon.apache.org
>> 
>> We should maintain single commit per jira. This is useful for multiple
>> reasons:
>> 1. To merge changes between branches, its easier to take commit diff if its
>> single commit. (Its always better to take commit diff than patch on the
>> jira as its possible that patch is out of date or committer made some small
>> changes to the patch before committing.)
>> 2. While debugging issues, to figure out which jira introduced the issue,
>> its useful to look at one commit rather than trying to figure out the diff
>> across commits
>> 3. Looking at commit history, commit message, we can't figure out the jira
>> to which the commit belong to. Since the contributor provides the commit
>> message, you can't enforce particular format. For example, look at commit
>> history of airavata: https://github.com/apache/airavata/commits/master
>> 4. With multiple commits per jira, I think the commits for different jiras
>> will be interleaved which is confusing
>> 
>> 
>> -Shwetha
>> 
>>> On Sun, Jan 11, 2015 at 5:56 AM, Ajay Yadav <ajaynsit@gmail.com> wrote:
>>> 
>>> 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
View raw message