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@xxxxxxxxxx> 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
