You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by Madhan Neethiraj <ma...@apache.org> on 2017/05/24 06:27:52 UTC
Patches with trivial changes
All,
I notice a number of recent patches address trivial issues like white space, spelling mistakes (one patch just changed a single letter in a label). And few other patches update a large number of files for trivial/non-functional changes – like whitespaces. I strongly suggest we refrain from authoring/encouraging such patches – for many reasons. One of the main reasons is the overhead such updates add in backporting real/critical fixes (that would come later) to other branches, as these changes might force dealing with merge conflicts.
Since the changes introduced in such patches are not essential, I would suggest to take these up when these source files are updated for other functional fixes. I would greatly appreciate if the patches focus on fixing/enhancing Ranger functionality; this would be benefit the community immensely.
Thanks,
Madhan
答复: Re: Patches with trivial changes
Posted by pe...@zte.com.cn.
SGkgTWFkaGFuLA0KDQoNCg0KDQpNZXJnaW5nIHRoZXNlIHNtYWxsIGlzc3VlcyB0byBvdGhlciBi
cmFuY2hlcyB3aWxsIGluY3JlYXNlIHRoZSB3b3JrbG9hZCBhbmQgdGhlIHByb2JhYmlsaXR5IG9m
IGVycm9yLiBJZiBwb3NzaWJsZSwgd2UgY2FuIHVuZGVydGFrZSBzaW1pbGFyIHRhc2tzIHdoZW4g
c29tZSBpbXBvcnRhbnQgaXNzdWVzIG5lZWQgdG8gYmUgbWVyZ2VkIGludG8gb3RoZXIgYnJhbmNo
ZXMuIA0KDQoNCg0KDQpXaXRoIHRoZSBpbXByb3ZlbWVudCBvZiBxdWFsaXR5LCB0aGVzZSBzbWFs
bCBpc3N1ZXMgd2lsbCBiZSBncmFkdWFsbHkgcmVkdWNlZCB1bnRpbCB0aGUgbGFzdCBkaXNhcHBl
YXIuIFRoZSBjdXJyZW50IGRpZmZpY3VsdGllcyB3aWxsIGdyYWR1YWxseSByZWR1Y2UgaWYgd2Ug
Y29udGludWUgdG8gaGFuZGxlIHRoZXNlIGlzc3Vlcy4gT3RoZXJ3aXNlIHdpdGggdGhlIGZ1bmN0
aW9uIG9mIHRoZSBwZXJmZWN0LCBzdWNoIHNtYWxsIGlzc3VlIHdpbGwgYmUgYWNjdW11bGF0ZWQg
YW5kIGluY3JlYXNlZC4NCg0KQXQgdGhlIHNhbWUgdGltZSwgd2Ugc2hvdWxkIHN0cmljdGx5IGNv
bnRyb2wgdGhlIHF1YWxpdHkgb2YgdGhlIGNvZGUgdG8gYXZvaWQgc2ltaWxhciBwcm9ibGVtcy4N
Cg0KDQoNCg0KV2Ugd2lsbCByZXNwZWN0IHlvdXIgb3BpbmlvbiBhbmQgY29udHJvbCB0aGUgcXVh
bGl0eSBvZiB0aGUgY29kZS4NCg0KDQoNCg0KUGVuZy5qaWFuaHVhDQoNCg0KDQoNCuWPkeS7tuS6
uu+8miDvvJxjb2hlaWdlYUBhcGFjaGUub3Jn77yeDQoNCg0KDQoNCg0KDQoNCuaUtuS7tuS6uu+8
miDvvJxkZXZAcmFuZ2VyLmFwYWNoZS5vcmfvvJ4NCuaKhOmAgeS6uu+8miDvvJxjb21taXRzQHJh
bmdlci5hcGFjaGUub3Jn77yeDQrml6Ug5pyfIO+8mjIwMTflubQwNeaciDI05pelIDE2OjQ5DQrk
uLsg6aKYIO+8mlJlOiBQYXRjaGVzIHdpdGggdHJpdmlhbCBjaGFuZ2VzDQoNCg0KDQoNCg0KSGkg
TWFkaGFuLA0KDQpUcml2aWFsIGNvbW1pdHMgcHJvdmlkZSBhIHBhdGggdG8gZ2V0IG5ldyBjb250
cmlidXRvcnMgb24gYm9hcmQgdG8gdGhlDQpwcm9qZWN0IC0gc29tZXRoaW5nIHRoYXQgdGhlIHBy
b2plY3QgbmVlZHMgSU1PLiBZZXMgaXQgbWF5IG1ha2UgYmFja3BvcnRpbmcNCmZpeGVzIGEgbGl0
dGxlIG1vcmUgZGlmZmljdWx0LCBidXQgaXQncyBoYXJkbHkgYW4gaW50cmFjdGFibGUgcHJvYmxl
bSB0bw0KZmlndXJlIG91dCBzb21lIHdoaXRlc3BhY2UgY2hhbmdlcyBiZXR3ZWVuIGJyYW5jaGVz
IC0gaXQncyBub3QgYXMgaWYgUmFuZ2VyDQppcyBhIHBhcnRpY3VsYXJseSBsYXJnZSBwcm9qZWN0
Lg0KDQpIYXZpbmcgc2FpZCB0aGF0IEkgYWdyZWUgdGhhdCBzb21lIG9mIHRoZSB2ZXJ5IHRyaXZp
YWwgcGF0Y2hlcyBjb3VsZCBtYXliZQ0KYmUgY29uc29saWRhdGVkIGEgYml0IG1vcmUuIEkgd2ls
bCBlbmNvdXJhZ2UgZnV0dXJlIHJldmlldyByZXF1ZXN0cyB0aGF0DQpoYXZlIGEgdmVyeSB0cml2
aWFsIHNwZWxsaW5nIGZpeCB0byBob2xkIG9uIHRvIHRoZSBmaXggZm9yIGEgd2hpbGUsIHNvIHRo
YXQNCndlIGNhbiBmaXggbXVsdGlwbGUgc3BlbGxpbmcgZml4ZXMgZXRjLiBhdCB0aGUgc2FtZSB0
aW1lLg0KDQpDb2xtLg0KDQpPbiBXZWQsIE1heSAyNCwgMjAxNyBhdCA3OjI3IEFNLCBNYWRoYW4g
TmVldGhpcmFqIO+8nG1hZGhhbkBhcGFjaGUub3Jn77yeIHdyb3RlOg0KDQrvvJ4gQWxsLA0K77ye
DQrvvJ4NCu+8ng0K77yeIEkgbm90aWNlIGEgbnVtYmVyIG9mIHJlY2VudCBwYXRjaGVzIGFkZHJl
c3MgdHJpdmlhbCBpc3N1ZXMgbGlrZSB3aGl0ZQ0K77yeIHNwYWNlLCBzcGVsbGluZyBtaXN0YWtl
cyAob25lIHBhdGNoIGp1c3QgY2hhbmdlZCBhIHNpbmdsZSBsZXR0ZXIgaW4gYQ0K77yeIGxhYmVs
KS4gQW5kIGZldyBvdGhlciBwYXRjaGVzIHVwZGF0ZSBhIGxhcmdlIG51bWJlciBvZiBmaWxlcyBm
b3INCu+8niB0cml2aWFsL25vbi1mdW5jdGlvbmFsIGNoYW5nZXMg4oCTIGxpa2Ugd2hpdGVzcGFj
ZXMuIEkgc3Ryb25nbHkgc3VnZ2VzdCB3ZQ0K77yeIHJlZnJhaW4gZnJvbSBhdXRob3JpbmcvZW5j
b3VyYWdpbmcgc3VjaCBwYXRjaGVzIOKAkyBmb3IgbWFueSByZWFzb25zLiBPbmUgb2YNCu+8niB0
aGUgbWFpbiByZWFzb25zIGlzIHRoZSBvdmVyaGVhZCBzdWNoIHVwZGF0ZXMgYWRkIGluIGJhY2tw
b3J0aW5nDQrvvJ4gcmVhbC9jcml0aWNhbCBmaXhlcyAodGhhdCB3b3VsZCBjb21lIGxhdGVyKSB0
byBvdGhlciBicmFuY2hlcywgYXMgdGhlc2UNCu+8niBjaGFuZ2VzIG1pZ2h0IGZvcmNlIGRlYWxp
bmcgd2l0aCBtZXJnZSBjb25mbGljdHMuDQrvvJ4NCu+8ng0K77yeDQrvvJ4gU2luY2UgdGhlIGNo
YW5nZXMgaW50cm9kdWNlZCBpbiBzdWNoIHBhdGNoZXMgYXJlIG5vdCBlc3NlbnRpYWwsIEkgd291
bGQNCu+8niBzdWdnZXN0IHRvIHRha2UgdGhlc2UgdXAgd2hlbiB0aGVzZSBzb3VyY2UgZmlsZXMg
YXJlIHVwZGF0ZWQgZm9yIG90aGVyDQrvvJ4gZnVuY3Rpb25hbCBmaXhlcy4gSSB3b3VsZCBncmVh
dGx5IGFwcHJlY2lhdGUgaWYgdGhlIHBhdGNoZXMgZm9jdXMgb24NCu+8niBmaXhpbmcvZW5oYW5j
aW5nIFJhbmdlciBmdW5jdGlvbmFsaXR5IHRoaXMgd291bGQgYmUgYmVuZWZpdCB0aGUgY29tbXVu
aXR5DQrvvJ4gaW1tZW5zZWx5Lg0K77yeDQrvvJ4NCu+8ng0K77yeIFRoYW5rcywNCu+8ng0K77ye
IE1hZGhhbg0K77yeDQrvvJ4NCu+8ng0KDQoNCg0KLS0gDQpDb2xtIE8gaEVpZ2VhcnRhaWdoDQoN
ClRhbGVuZCBDb21tdW5pdHkgQ29kZXINCmh0dHA6Ly9jb2RlcnMudGFsZW5kLmNvbQ==
Re: Patches with trivial changes
Posted by Madhan Neethiraj <ma...@apache.org>.
Zsombor,
>> Instead of discouraging contributions
My suggestion was to discourage patches that have *only* very, very tiny and non-essential updates – like changing case of a label word from “G” to “g”, removing a blank line, etc; or patches that touch hundreds of files for trivial/non-essential updates. I think these can’t be a way to ease into the project. A better way would be to take time to understand the project functionality and contribute towards enhancing it. I think an excellent example in this regard would be Colm’s initial contributions, which significantly improved the unit test coverage for Ranger plugins. It will help the Ranger community immensely if contributors take such a path.
>> Is there any particular reason, why the current workflow used as is ?
Ranger community has been using review-board since its beginning, and it seems to be working well. Many Apache project do use this approach.
As new contributors join the community, their experience/expectation might be different. Use of ‘pull requests’ to deal with patch/review/merge was suggested sometime back as well. I think we should give this a shot, to find if this approach makes it easier for everyone. However, bear in mind that people might have bias towards a specific approach, based on their prior experience and comfort level. Forcing everyone to change might take effort/time.
Thanks,
Madhan
On 5/24/17, 4:31 AM, "Zsombor" <gz...@gmail.com> wrote:
Instead of discouraging contributions, the project should ease the
contribution - and also the review process.
The current JIRA + Reviewboard infrastructure needs a lot's of unnecessary
manual steps, which hurts everyone who wants to help.
Currently, the contributor needs to do the following, after they have a
working commit in their git repository
1, open a jira ticket
2, generate a patch from git
2, create a review boad request, uploading the patch to it
3, upload the patch to jira
4, if something is not correct, they have to repeat 2-3.
Similarly, for the reviewer, he has to manually download, apply, and run
the tests locally, even when he thinks the patch is ok.
My suggestion is to switch to a pull request based workflow, where the
manual patch creation, upload-download process could be omitted, and travis
or some other automatic build service should be introduced, to ensure, that
the base sanity tests are not omitted accidentally.
With this process, a commiter could review and approve a trivial commits
in less than a minute.
Is there any particular reason, why the current workflow used as is ?
Regards,
Zsombor
On Wed, May 24, 2017 at 12:28 PM, Gautam Borad <gb...@gmail.com> wrote:
> +1 for Madhan's recommendations,
>
> Colm, I agree that we should not discourage new contributions. However, I
> think, we should also not encourage such single line/whitespace
> contributions. We want contributors who can do more functionals/feature
> changes and while doing that they can also fix the trivial issues
> (whitespace etc)
>
> Since each contribution to Ranger requires creating Jira/RR, if we start
> having lot of such trivial contributions, the community will be overwhelmed
> with activities(mails etc) like this and that can lead to ignoring of a
> real functional change, when it comes.
>
> In fact, the Apache page on Contributors itself says :
>
> "Being a contributor simply means that you take an interest in the project
> and contribute in some way, ranging from asking sensible questions (which
> documents the project and provides feedback to developers) through to
> providing *new features* as patches."
>
>
> So yes, we should encourage contributors, but encourage them to try and
> understand Ranger and add more features/functionalities and eventually
> "earn" the title of a committer. Thanks.
>
>
>
> On Wed, May 24, 2017 at 2:19 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> > Hi Madhan,
> >
> > Trivial commits provide a path to get new contributors on board to the
> > project - something that the project needs IMO. Yes it may make
> backporting
> > fixes a little more difficult, but it's hardly an intractable problem to
> > figure out some whitespace changes between branches - it's not as if
> Ranger
> > is a particularly large project.
> >
> > Having said that I agree that some of the very trivial patches could
> maybe
> > be consolidated a bit more. I will encourage future review requests that
> > have a very trivial spelling fix to hold on to the fix for a while, so
> that
> > we can fix multiple spelling fixes etc. at the same time.
> >
> > Colm.
> >
> > On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj <ma...@apache.org>
> > wrote:
> >
> > > All,
> > >
> > >
> > >
> > > I notice a number of recent patches address trivial issues like white
> > > space, spelling mistakes (one patch just changed a single letter in a
> > > label). And few other patches update a large number of files for
> > > trivial/non-functional changes – like whitespaces. I strongly suggest
> we
> > > refrain from authoring/encouraging such patches – for many reasons. One
> > of
> > > the main reasons is the overhead such updates add in backporting
> > > real/critical fixes (that would come later) to other branches, as these
> > > changes might force dealing with merge conflicts.
> > >
> > >
> > >
> > > Since the changes introduced in such patches are not essential, I would
> > > suggest to take these up when these source files are updated for other
> > > functional fixes. I would greatly appreciate if the patches focus on
> > > fixing/enhancing Ranger functionality; this would be benefit the
> > community
> > > immensely.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Madhan
> > >
> > >
> > >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Regards,
> Gautam.
>
Re: Patches with trivial changes
Posted by Madhan Neethiraj <ma...@apache.org>.
Zsombor,
>> Instead of discouraging contributions
My suggestion was to discourage patches that have *only* very, very tiny and non-essential updates – like changing case of a label word from “G” to “g”, removing a blank line, etc; or patches that touch hundreds of files for trivial/non-essential updates. I think these can’t be a way to ease into the project. A better way would be to take time to understand the project functionality and contribute towards enhancing it. I think an excellent example in this regard would be Colm’s initial contributions, which significantly improved the unit test coverage for Ranger plugins. It will help the Ranger community immensely if contributors take such a path.
>> Is there any particular reason, why the current workflow used as is ?
Ranger community has been using review-board since its beginning, and it seems to be working well. Many Apache project do use this approach.
As new contributors join the community, their experience/expectation might be different. Use of ‘pull requests’ to deal with patch/review/merge was suggested sometime back as well. I think we should give this a shot, to find if this approach makes it easier for everyone. However, bear in mind that people might have bias towards a specific approach, based on their prior experience and comfort level. Forcing everyone to change might take effort/time.
Thanks,
Madhan
On 5/24/17, 4:31 AM, "Zsombor" <gz...@gmail.com> wrote:
Instead of discouraging contributions, the project should ease the
contribution - and also the review process.
The current JIRA + Reviewboard infrastructure needs a lot's of unnecessary
manual steps, which hurts everyone who wants to help.
Currently, the contributor needs to do the following, after they have a
working commit in their git repository
1, open a jira ticket
2, generate a patch from git
2, create a review boad request, uploading the patch to it
3, upload the patch to jira
4, if something is not correct, they have to repeat 2-3.
Similarly, for the reviewer, he has to manually download, apply, and run
the tests locally, even when he thinks the patch is ok.
My suggestion is to switch to a pull request based workflow, where the
manual patch creation, upload-download process could be omitted, and travis
or some other automatic build service should be introduced, to ensure, that
the base sanity tests are not omitted accidentally.
With this process, a commiter could review and approve a trivial commits
in less than a minute.
Is there any particular reason, why the current workflow used as is ?
Regards,
Zsombor
On Wed, May 24, 2017 at 12:28 PM, Gautam Borad <gb...@gmail.com> wrote:
> +1 for Madhan's recommendations,
>
> Colm, I agree that we should not discourage new contributions. However, I
> think, we should also not encourage such single line/whitespace
> contributions. We want contributors who can do more functionals/feature
> changes and while doing that they can also fix the trivial issues
> (whitespace etc)
>
> Since each contribution to Ranger requires creating Jira/RR, if we start
> having lot of such trivial contributions, the community will be overwhelmed
> with activities(mails etc) like this and that can lead to ignoring of a
> real functional change, when it comes.
>
> In fact, the Apache page on Contributors itself says :
>
> "Being a contributor simply means that you take an interest in the project
> and contribute in some way, ranging from asking sensible questions (which
> documents the project and provides feedback to developers) through to
> providing *new features* as patches."
>
>
> So yes, we should encourage contributors, but encourage them to try and
> understand Ranger and add more features/functionalities and eventually
> "earn" the title of a committer. Thanks.
>
>
>
> On Wed, May 24, 2017 at 2:19 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> > Hi Madhan,
> >
> > Trivial commits provide a path to get new contributors on board to the
> > project - something that the project needs IMO. Yes it may make
> backporting
> > fixes a little more difficult, but it's hardly an intractable problem to
> > figure out some whitespace changes between branches - it's not as if
> Ranger
> > is a particularly large project.
> >
> > Having said that I agree that some of the very trivial patches could
> maybe
> > be consolidated a bit more. I will encourage future review requests that
> > have a very trivial spelling fix to hold on to the fix for a while, so
> that
> > we can fix multiple spelling fixes etc. at the same time.
> >
> > Colm.
> >
> > On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj <ma...@apache.org>
> > wrote:
> >
> > > All,
> > >
> > >
> > >
> > > I notice a number of recent patches address trivial issues like white
> > > space, spelling mistakes (one patch just changed a single letter in a
> > > label). And few other patches update a large number of files for
> > > trivial/non-functional changes – like whitespaces. I strongly suggest
> we
> > > refrain from authoring/encouraging such patches – for many reasons. One
> > of
> > > the main reasons is the overhead such updates add in backporting
> > > real/critical fixes (that would come later) to other branches, as these
> > > changes might force dealing with merge conflicts.
> > >
> > >
> > >
> > > Since the changes introduced in such patches are not essential, I would
> > > suggest to take these up when these source files are updated for other
> > > functional fixes. I would greatly appreciate if the patches focus on
> > > fixing/enhancing Ranger functionality; this would be benefit the
> > community
> > > immensely.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Madhan
> > >
> > >
> > >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Regards,
> Gautam.
>
Re: Patches with trivial changes
Posted by Zsombor <gz...@gmail.com>.
Instead of discouraging contributions, the project should ease the
contribution - and also the review process.
The current JIRA + Reviewboard infrastructure needs a lot's of unnecessary
manual steps, which hurts everyone who wants to help.
Currently, the contributor needs to do the following, after they have a
working commit in their git repository
1, open a jira ticket
2, generate a patch from git
2, create a review boad request, uploading the patch to it
3, upload the patch to jira
4, if something is not correct, they have to repeat 2-3.
Similarly, for the reviewer, he has to manually download, apply, and run
the tests locally, even when he thinks the patch is ok.
My suggestion is to switch to a pull request based workflow, where the
manual patch creation, upload-download process could be omitted, and travis
or some other automatic build service should be introduced, to ensure, that
the base sanity tests are not omitted accidentally.
With this process, a commiter could review and approve a trivial commits
in less than a minute.
Is there any particular reason, why the current workflow used as is ?
Regards,
Zsombor
On Wed, May 24, 2017 at 12:28 PM, Gautam Borad <gb...@gmail.com> wrote:
> +1 for Madhan's recommendations,
>
> Colm, I agree that we should not discourage new contributions. However, I
> think, we should also not encourage such single line/whitespace
> contributions. We want contributors who can do more functionals/feature
> changes and while doing that they can also fix the trivial issues
> (whitespace etc)
>
> Since each contribution to Ranger requires creating Jira/RR, if we start
> having lot of such trivial contributions, the community will be overwhelmed
> with activities(mails etc) like this and that can lead to ignoring of a
> real functional change, when it comes.
>
> In fact, the Apache page on Contributors itself says :
>
> "Being a contributor simply means that you take an interest in the project
> and contribute in some way, ranging from asking sensible questions (which
> documents the project and provides feedback to developers) through to
> providing *new features* as patches."
>
>
> So yes, we should encourage contributors, but encourage them to try and
> understand Ranger and add more features/functionalities and eventually
> "earn" the title of a committer. Thanks.
>
>
>
> On Wed, May 24, 2017 at 2:19 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> > Hi Madhan,
> >
> > Trivial commits provide a path to get new contributors on board to the
> > project - something that the project needs IMO. Yes it may make
> backporting
> > fixes a little more difficult, but it's hardly an intractable problem to
> > figure out some whitespace changes between branches - it's not as if
> Ranger
> > is a particularly large project.
> >
> > Having said that I agree that some of the very trivial patches could
> maybe
> > be consolidated a bit more. I will encourage future review requests that
> > have a very trivial spelling fix to hold on to the fix for a while, so
> that
> > we can fix multiple spelling fixes etc. at the same time.
> >
> > Colm.
> >
> > On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj <ma...@apache.org>
> > wrote:
> >
> > > All,
> > >
> > >
> > >
> > > I notice a number of recent patches address trivial issues like white
> > > space, spelling mistakes (one patch just changed a single letter in a
> > > label). And few other patches update a large number of files for
> > > trivial/non-functional changes – like whitespaces. I strongly suggest
> we
> > > refrain from authoring/encouraging such patches – for many reasons. One
> > of
> > > the main reasons is the overhead such updates add in backporting
> > > real/critical fixes (that would come later) to other branches, as these
> > > changes might force dealing with merge conflicts.
> > >
> > >
> > >
> > > Since the changes introduced in such patches are not essential, I would
> > > suggest to take these up when these source files are updated for other
> > > functional fixes. I would greatly appreciate if the patches focus on
> > > fixing/enhancing Ranger functionality; this would be benefit the
> > community
> > > immensely.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Madhan
> > >
> > >
> > >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Regards,
> Gautam.
>
Re: Patches with trivial changes
Posted by Gautam Borad <gb...@gmail.com>.
+1 for Madhan's recommendations,
Colm, I agree that we should not discourage new contributions. However, I
think, we should also not encourage such single line/whitespace
contributions. We want contributors who can do more functionals/feature
changes and while doing that they can also fix the trivial issues
(whitespace etc)
Since each contribution to Ranger requires creating Jira/RR, if we start
having lot of such trivial contributions, the community will be overwhelmed
with activities(mails etc) like this and that can lead to ignoring of a
real functional change, when it comes.
In fact, the Apache page on Contributors itself says :
"Being a contributor simply means that you take an interest in the project
and contribute in some way, ranging from asking sensible questions (which
documents the project and provides feedback to developers) through to
providing *new features* as patches."
So yes, we should encourage contributors, but encourage them to try and
understand Ranger and add more features/functionalities and eventually
"earn" the title of a committer. Thanks.
On Wed, May 24, 2017 at 2:19 PM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> Hi Madhan,
>
> Trivial commits provide a path to get new contributors on board to the
> project - something that the project needs IMO. Yes it may make backporting
> fixes a little more difficult, but it's hardly an intractable problem to
> figure out some whitespace changes between branches - it's not as if Ranger
> is a particularly large project.
>
> Having said that I agree that some of the very trivial patches could maybe
> be consolidated a bit more. I will encourage future review requests that
> have a very trivial spelling fix to hold on to the fix for a while, so that
> we can fix multiple spelling fixes etc. at the same time.
>
> Colm.
>
> On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj <ma...@apache.org>
> wrote:
>
> > All,
> >
> >
> >
> > I notice a number of recent patches address trivial issues like white
> > space, spelling mistakes (one patch just changed a single letter in a
> > label). And few other patches update a large number of files for
> > trivial/non-functional changes – like whitespaces. I strongly suggest we
> > refrain from authoring/encouraging such patches – for many reasons. One
> of
> > the main reasons is the overhead such updates add in backporting
> > real/critical fixes (that would come later) to other branches, as these
> > changes might force dealing with merge conflicts.
> >
> >
> >
> > Since the changes introduced in such patches are not essential, I would
> > suggest to take these up when these source files are updated for other
> > functional fixes. I would greatly appreciate if the patches focus on
> > fixing/enhancing Ranger functionality; this would be benefit the
> community
> > immensely.
> >
> >
> >
> > Thanks,
> >
> > Madhan
> >
> >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Regards,
Gautam.
Re: Patches with trivial changes
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Madhan,
Trivial commits provide a path to get new contributors on board to the
project - something that the project needs IMO. Yes it may make backporting
fixes a little more difficult, but it's hardly an intractable problem to
figure out some whitespace changes between branches - it's not as if Ranger
is a particularly large project.
Having said that I agree that some of the very trivial patches could maybe
be consolidated a bit more. I will encourage future review requests that
have a very trivial spelling fix to hold on to the fix for a while, so that
we can fix multiple spelling fixes etc. at the same time.
Colm.
On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj <ma...@apache.org> wrote:
> All,
>
>
>
> I notice a number of recent patches address trivial issues like white
> space, spelling mistakes (one patch just changed a single letter in a
> label). And few other patches update a large number of files for
> trivial/non-functional changes – like whitespaces. I strongly suggest we
> refrain from authoring/encouraging such patches – for many reasons. One of
> the main reasons is the overhead such updates add in backporting
> real/critical fixes (that would come later) to other branches, as these
> changes might force dealing with merge conflicts.
>
>
>
> Since the changes introduced in such patches are not essential, I would
> suggest to take these up when these source files are updated for other
> functional fixes. I would greatly appreciate if the patches focus on
> fixing/enhancing Ranger functionality; this would be benefit the community
> immensely.
>
>
>
> Thanks,
>
> Madhan
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Patches with trivial changes
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Madhan,
Trivial commits provide a path to get new contributors on board to the
project - something that the project needs IMO. Yes it may make backporting
fixes a little more difficult, but it's hardly an intractable problem to
figure out some whitespace changes between branches - it's not as if Ranger
is a particularly large project.
Having said that I agree that some of the very trivial patches could maybe
be consolidated a bit more. I will encourage future review requests that
have a very trivial spelling fix to hold on to the fix for a while, so that
we can fix multiple spelling fixes etc. at the same time.
Colm.
On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj <ma...@apache.org> wrote:
> All,
>
>
>
> I notice a number of recent patches address trivial issues like white
> space, spelling mistakes (one patch just changed a single letter in a
> label). And few other patches update a large number of files for
> trivial/non-functional changes – like whitespaces. I strongly suggest we
> refrain from authoring/encouraging such patches – for many reasons. One of
> the main reasons is the overhead such updates add in backporting
> real/critical fixes (that would come later) to other branches, as these
> changes might force dealing with merge conflicts.
>
>
>
> Since the changes introduced in such patches are not essential, I would
> suggest to take these up when these source files are updated for other
> functional fixes. I would greatly appreciate if the patches focus on
> fixing/enhancing Ranger functionality; this would be benefit the community
> immensely.
>
>
>
> Thanks,
>
> Madhan
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com