[Gluster-devel] Reviewing patches early

[Justin Clift]

Can you chuck that on the wiki in a new page?

We can link to it from the Developers section.  I have .vimrc
settings around somewhere that can be added too. :)

+ Justin


On 26/06/2014, at 1:54 AM, Harshavardhana wrote:
> Been thinking about rebasing it, let me think about a cleaner way.
> 
> For emacs here you go!
> 
> ~~~
> (defun my-linux-c-mode ()
>  "C mode with adjusted defaults for use with the linux kernel."
>  (c-set-style "linux"))
> (add-hook 'c-mode-hook 'my-linux-c-mode)
> 
> (setq indent-tabs-mode nil)
> (add-hook 'python-mode-hook '(lambda ()
>                               (setq python-indent 4)))
> 
> (require 'whitespace)
> (setq whitespace-style '(face empty tabs lines-tail trailing))
> (global-whitespace-mode t)
> (setq whitespace-action '(auto-cleanup)) ;; automatically clean up bad
> whitespace
> 
> ;; I hate tabs!
> (setq-default indent-tabs-mode nil)
> ~~~
> 
> On Wed, Jun 25, 2014 at 5:40 PM, Pranith Kumar Karampuri
> <pkarampu at redhat.com> wrote:
>> 
>> On 06/25/2014 10:31 PM, Jeff Darcy wrote:
>>> 
>>> Justin asked me, as the group's official Grumpy Old Man, to send a note
>>> reminding people about the importance of reviewing patches early.  Here
>>> it is.  As I see it, we've historically had two problems with reviews.
>>> 
>>> (1) Patches that don't get reviewed at all.
>>> 
>>> (2) Patches that have to be re-worked continually due to late reviews.
>>> 
>>> We've made a lot of progress on (1), especially with the addition of
>>> more maintainers, so this is about (2).  As a patch gets older, it
>>> becomes increasingly likely that it will be rebased and regression tests
>>> will have to be re-run because of merge conflicts.  This isn't a problem
>>> for features to which Red Hat has graciously assigned more than one
>>> developer, as they review each others' work and the patch gets merged
>>> quickly (sometimes before other interested parties have even had a
>>> chance to see it in the queue but that's a different problem).  However,
>>> it creates a problem for *every other patch*, which might now have to
>>> rebased etc. - even those that are older and more important to users and
>>> up against tighter deadlines.  This "priority inversion" can often be
>>> avoided if people who intend to review a patch would do so sooner, so
>>> that all of the review re-work can be done before new merge conflicts
>>> are created.  Given the differences in time zones throughout our group,
>>> each round of such unnecessary work can cost an entire day, leading to
>>> even more potential for further merge conflicts.  It's a vicious cycle
>>> that we need to break.  Please, get all of those complaints about tabs
>>> and spaces and variable names in *early*, and help us keep the
>> 
>> While I agree with everything you said. Complaining about tabs/spaces should
>> be done by a script. Something like http://review.gluster.com/#/c/5404
>> Some one who knows perl should help us with rebasing it and getting it in?
>> 
>> Pranith

--
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift