When will we have our next release?

2011-06-07 Thread Sebastian Spaeth
On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins wrote:

> I would love to hear any other ideas people have on this front.

I agree that delegation of bindings (and potentially the emacs code) is
a good thing. I believe both areas are separate enough to be
delegated. Perhaps have a similar tiered sytem with a different
"lieutenant" for the elisp code would be acceptable?

As for notmuch core, I do like the careful reviews and would prefer if
cworth still nodded off patch series, but a tiered review system, where
amdragon's nod off is enough to get patches at the top of cworth queue
would be great too.

> Notmuch is an incredible project, with an absolutely incredible
> development community.  It's an absolute joy to work on.
Signed-off-by: Sebastian Spaeth  :)

spaetz
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110607/b371c96d/attachment.pgp>


When will we have our next release?

2011-06-07 Thread Jameson Graef Rollins
On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth  wrote:
> Frankly, I wouldn't mind doing strict time-based releases with something
> like the following:

Hi, Carl.  I think this is a fine idea, and we (not you) can definitely
run this process.  I'm quite sure that at least bremner and I can
completely handle this together, and I'm sure we can get others to help.

But the mechanics of the actual release are not the problem.  The
problem is the current one-person bottleneck for all patches: your
review and merge of all patches into the notmuch/master branch.  This
would not necessarily be a problem if you could get to reviewing and
merging patches more frequently.  But as it is now, if there are no new
patches on notmuch/master for longer than the release period, there will
be nothing to package and upload.

This is *not* meant to be an indictment of you at all.  I know it's
incredibly hard to keep up with the incoming patch flow.  It takes a lot
of time and work to review every patch.  I also really like your
reviews.  They are incredibly thorough and insightful, and I always
learn from them.  Your intimate knowledge of the code base also means
that you can frequently come up with cleaner solutions to the proposed
patches (as with the reworked part handling).

However, the bottleneck presents a big problem when delays are
introduced.  We can't really do anything until you can get to the
review.  Furthermore, even if we do push ahead to put together a release
candidate branch (as we did with 0.6), if your review severely alters
patches early in that branch we have to do a lot of work to rework their
decedents (as we did with 0.6).  This leads to a lot of inefficiencies.

So we need to figure out a way to break the bottleneck.

I would really like to continue to get your review of patches.  I think
they're just too valuable.  So it would be really nice if one of the
solutions was a way to just "grease" the bottleneck, so to speak.  For
instance, if you could commit to reviewing just 1 patch series a week we
would be way ahead of where we have been.

Another thing that would help would be to delegate responsibility of
certain components to others, as you have with the python binding to
spaetz.  For instance, we have at least a couple of elisp experts
hanging around.  Maybe you could cede handling of all emacs patches to
someone like jkr or dme, and to felipe for vim, etc. (if they're willing
to take on those rolls).  That would help reduce your burden a bit.

We could also formalize some sort of tiered review system.  amdragon has
been doing a really good job of frequently providing good review of
patches on list.  I think that any proposed patch that gets a thumbs up


[PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Dmitry Kurochkin
Hi Austin.

On Tue,  7 Jun 2011 01:20:25 -0400, Austin Clements  wrote:
> Also, slightly reformat dir-locals.el so that the settings align and
> to make it friendlier for future additions.
> ---
>  .dir-locals.el |   18 ++
>  1 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/.dir-locals.el b/.dir-locals.el
> index cbdb1f9..eff29fc 100644
> --- a/.dir-locals.el
> +++ b/.dir-locals.el
> @@ -1,7 +1,17 @@
>  ; emacs local configuration settings for notmuch source
>  ; surmised by dkg on 2010-11-23 13:43:18-0500
> +; amended by amdragon on 2011-06-06
>  
> -((c-mode . ((indent-tabs-mode . t)
> -(tab-width . 8)
> -(c-basic-offset . 4)
> -(c-file-style . "linux"
> +((c-mode
> +  (indent-tabs-mode . t)
> +  (tab-width . 8)
> +  (c-basic-offset . 4)
> +  (c-file-style . "linux"))
> + (c++-mode
> +  (indent-tabs-mode . t)
> +  (tab-width . 8)
> +  (c-basic-offset . 4)
> +  (c-file-style . "linux"))
> + (emacs-lisp-mode
> +  (indent-tabs-mode . t))
> + )

Why tab-width is not set for the emacs-lisp-mode?

Also, perhaps we should set these variables for all modes?  Setting
c-basic-offset and c-file-style should not hurt.  And indent-tabs-mode
and tab-width should be relevant for any file in notmuch (shell, python,
probably even text files), no?

Regards,
  Dmitry

> -- 
> 1.7.5.1
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Austin Clements
On Tue, Jun 7, 2011 at 2:38 AM, Dima Kogan  
wrote:
>> On Tue, ?7 Jun 2011 01:20:25 -0400
>> Austin Clements  wrote:
>>
>> Also, slightly reformat dir-locals.el so that the settings align and
>> to make it friendlier for future additions.
>
> Should we also add:
>
> (tab-always-indent . nil)

tab-always-indent is a user-interface preference and definitely
shouldn't be overridden by .dir-locals.  (Personally, I would go crazy
if I had tab-always-indent set to nil.)

> (indent-tabs-mode ?. t)

I'll add this for shell-mode.  As I pointed out in my reply to Dmitry,
this shouldn't be set globally.  Are there any other specific modes it
should be set for?

> Otherwise the setups of people who normally use spaces will still
> insert spaces when 'tab' is depressed.


[PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Austin Clements
Quoth Dmitry Kurochkin on Jun 07 at  9:27 am:
> Hi Austin.
> 
> On Tue,  7 Jun 2011 01:20:25 -0400, Austin Clements  
> wrote:
> > Also, slightly reformat dir-locals.el so that the settings align and
> > to make it friendlier for future additions.
> > ---
> >  .dir-locals.el |   18 ++
> >  1 files changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/.dir-locals.el b/.dir-locals.el
> > index cbdb1f9..eff29fc 100644
> > --- a/.dir-locals.el
> > +++ b/.dir-locals.el
> > @@ -1,7 +1,17 @@
> >  ; emacs local configuration settings for notmuch source
> >  ; surmised by dkg on 2010-11-23 13:43:18-0500
> > +; amended by amdragon on 2011-06-06
> >  
> > -((c-mode . ((indent-tabs-mode . t)
> > -(tab-width . 8)
> > -(c-basic-offset . 4)
> > -(c-file-style . "linux"
> > +((c-mode
> > +  (indent-tabs-mode . t)
> > +  (tab-width . 8)
> > +  (c-basic-offset . 4)
> > +  (c-file-style . "linux"))
> > + (c++-mode
> > +  (indent-tabs-mode . t)
> > +  (tab-width . 8)
> > +  (c-basic-offset . 4)
> > +  (c-file-style . "linux"))
> > + (emacs-lisp-mode
> > +  (indent-tabs-mode . t))
> > + )
> 
> Why tab-width is not set for the emacs-lisp-mode?

Because I forgot to set it.  ]:--8)

> Also, perhaps we should set these variables for all modes?  Setting
> c-basic-offset and c-file-style should not hurt.  And indent-tabs-mode
> and tab-width should be relevant for any file in notmuch (shell, python,
> probably even text files), no?

Personally, I would prefer to keep .dir-locals conservative, rather
than make sweeping settings.  For example, the Python code isn't (and
definitely shouldn't be) using tabs.  Adding settings for shell is a
good idea, though.

> Regards,
>   Dmitry


[PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Austin Clements
Also, slightly reformat dir-locals.el so that the settings align and
to make it friendlier for future additions.
---
 .dir-locals.el |   18 ++
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index cbdb1f9..eff29fc 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -1,7 +1,17 @@
 ; emacs local configuration settings for notmuch source
 ; surmised by dkg on 2010-11-23 13:43:18-0500
+; amended by amdragon on 2011-06-06

-((c-mode . ((indent-tabs-mode . t)
-(tab-width . 8)
-(c-basic-offset . 4)
-(c-file-style . "linux"
+((c-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (c-basic-offset . 4)
+  (c-file-style . "linux"))
+ (c++-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (c-basic-offset . 4)
+  (c-file-style . "linux"))
+ (emacs-lisp-mode
+  (indent-tabs-mode . t))
+ )
-- 
1.7.5.1



[PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Dima Kogan
> On Tue,  7 Jun 2011 01:20:25 -0400
> Austin Clements  wrote:
>
> Also, slightly reformat dir-locals.el so that the settings align and
> to make it friendlier for future additions.

Should we also add:

(tab-always-indent . nil)
(indent-tabs-mode  . t)

Otherwise the setups of people who normally use spaces will still
insert spaces when 'tab' is depressed.


[PATCH] added keys to hide/show a portion of the thread

2011-06-07 Thread Dima Kogan
> On Sun, 29 May 2011 01:56:44 -0700
> notmuch at dima.secretsauce.net wrote:
>
>  Here's another improvement. In the notmuch-show display this binds
> '[' to expand all the children messages (replies). Analogously ']'
> collapses all the children messages.

Here's an update of the patch to conform with notmuch's indentation style.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-added-keys-to-hide-show-a-portion-of-the-thread.patch
Type: text/x-patch
Size: 2119 bytes
Desc: not available
URL: 



[PATCH] Added C-up and C-down to cycle through previous searches

2011-06-07 Thread Dima Kogan
> Notmuch uses a mix of 8 char width tabs and spaces.  First go tabs,
> then, if you need indenting with more precision, spaces.  Look at the
> lines your patch removes for an example.
> 
> Also, .dir-locals.el sets some variables to configure Emacs for
> Notmuch coding style but only for c-mode.  You may set it by hand for
> lisp.

Hi again. Here's the new patch, with M-n/M-p and tabbed indentation

dima
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Added-M-n-and-M-p-to-cycle-through-previous-searches.patch
Type: text/x-patch
Size: 3698 bytes
Desc: not available
URL: 



Re: [PATCH] Added C-up and C-down to cycle through previous searches

2011-06-07 Thread Dima Kogan
 Notmuch uses a mix of 8 char width tabs and spaces.  First go tabs,
 then, if you need indenting with more precision, spaces.  Look at the
 lines your patch removes for an example.
 
 Also, .dir-locals.el sets some variables to configure Emacs for
 Notmuch coding style but only for c-mode.  You may set it by hand for
 lisp.

Hi again. Here's the new patch, with M-n/M-p and tabbed indentation

dimaFrom 70193e0a9f7451033fd0843d46ac40e5524b000b Mon Sep 17 00:00:00 2001
From: Dima Kogan d...@secretsauce.net
Date: Mon, 6 Jun 2011 23:15:26 -0700
Subject: [PATCH] Added M-n and M-p to cycle through previous searches

---
 emacs/notmuch-hello.el |   47 ---
 1 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 916cda1..035e551 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -123,6 +123,12 @@ Typically \,\ in the US and UK and \.\ in Europe.
 
 (defvar notmuch-hello-recent-searches nil)
 
+(defvar notmuch-hello-cyclerecent-index 0
+  The current index of the most-recent searches )
+
+(defvar notmuch-hello-search-widget nil
+  The search widget)
+
 (defun notmuch-hello-remember-search (search)
   (if (not (member search notmuch-hello-recent-searches))
   (push search notmuch-hello-recent-searches))
@@ -148,6 +154,26 @@ Typically \,\ in the US and UK and \.\ in Europe.
   (match-string 1 search)
 search))
 
+(defun notmuch-hello-cyclerecent-next ()
+  Cycle through the most recently-searched queries, going forwards
+  (interactive)
+  (notmuch-hello-cyclerecent 1))
+
+(defun notmuch-hello-cyclerecent-prev ()
+  Cycle through the most recently-searched queries, going backwards
+  (interactive)
+  (notmuch-hello-cyclerecent -1))
+
+(defun notmuch-hello-cyclerecent (d) ()
+  (when notmuch-hello-recent-searches ; if no recent searches, do nothing
+(let ((N (length notmuch-hello-recent-searches)))
+  (setq notmuch-hello-cyclerecent-index
+	(% (+ notmuch-hello-cyclerecent-index d N) N))) ; update the index
+
+(widget-value-set notmuch-hello-search-widget
+		  (nth notmuch-hello-cyclerecent-index notmuch-hello-recent-searches))
+(widget-setup)))
+
 (defun notmuch-hello-search (search)
   (let ((search (notmuch-hello-trim search)))
 (notmuch-hello-remember-search search)
@@ -455,13 +481,19 @@ Complete list of currently available key bindings:
 
 	(widget-insert \nSearch: )
 	(setq notmuch-hello-search-bar-marker (point-marker))
-	(widget-create 'editable-field
-		   ;; Leave some space at the start and end of the
-		   ;; search boxes.
-		   :size (max 8 (- (window-width) notmuch-hello-indent
-   (length Search: )))
-		   :action (lambda (widget rest ignore)
- (notmuch-hello-search (widget-value widget
+	(setq notmuch-hello-search-widget
+	  (widget-create 'editable-field
+			 ;; Leave some space at the start and end of the
+			 ;; search boxes.
+			 :size (max 8 (- (window-width) notmuch-hello-indent
+	 (length Search: )))
+			 :action (lambda (widget rest ignore)
+   (notmuch-hello-search (widget-value widget)))
+			 :keymap (let ((map (make-sparse-keymap)))
+   (set-keymap-parent map widget-field-keymap)
+   (define-key map (kbd M-p) 'notmuch-hello-cyclerecent-prev)
+   (define-key map (kbd M-n) 'notmuch-hello-cyclerecent-next)
+   map)))
 	(widget-insert \n)
 
 	(when notmuch-hello-recent-searches
@@ -535,6 +567,7 @@ Complete list of currently available key bindings:
 	(widget-insert Type a search query and hit RET to view matching threads.\n)
 	(when notmuch-hello-recent-searches
 	  (widget-insert Hit RET to re-submit a previous search. Edit it first if you like.\n)
+	  (widget-insert In the search box, M-n/M-p cycles through the recent searches.\n)
 	  (widget-insert Save recent searches with the `save' button.\n))
 	(when notmuch-saved-searches
 	  (widget-insert Edit saved searches with the `edit' button.\n))
-- 
1.7.5.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] added keys to hide/show a portion of the thread

2011-06-07 Thread Dima Kogan
 On Sun, 29 May 2011 01:56:44 -0700
 notm...@dima.secretsauce.net wrote:

  Here's another improvement. In the notmuch-show display this binds
 '[' to expand all the children messages (replies). Analogously ']'
 collapses all the children messages.

Here's an update of the patch to conform with notmuch's indentation style.
From 0e2ef657fe0f6e7f8f2f7e87acd1fbbf58d8d95d Mon Sep 17 00:00:00 2001
From: Dima Kogan d...@secretsauce.net
Date: Sun, 29 May 2011 00:37:55 -0700
Subject: [PATCH] added keys to hide/show a portion of the thread

---
 emacs/notmuch-show.el |   31 +++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 2ba151e..5ecf5ca 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -813,6 +813,8 @@ function is used. 
 	(define-key map   'notmuch-show-advance-and-archive)
 	(define-key map (kbd M-RET) 'notmuch-show-open-or-close-all)
 	(define-key map (kbd RET) 'notmuch-show-toggle-message)
+	(define-key map ] 'notmuch-show-hide-hierarchy)
+	(define-key map [ 'notmuch-show-show-hierarchy)
 	map)
   Keymap for \notmuch show\ buffers.)
 (fset 'notmuch-show-mode-map notmuch-show-mode-map)
@@ -1266,6 +1268,35 @@ argument, hide all of the messages.
 	  until (not (notmuch-show-goto-message-next
   (force-window-update))
 
+; get the depth, assuming the point is at the start of the header line
+(defun notmuch-show-get-depth ()
+  (save-excursion
+(let ((start (point)))
+  (- (re-search-forward ^ *) start
+
+(defun notmuch-show-hideshow-hierarchy (doshow)
+  Hides or shows this message and all its replies
+  (interactive)
+  (save-excursion
+(notmuch-show-move-to-message-top)
+
+(let ((depth0 (notmuch-show-get-depth)))
+  (loop do (notmuch-show-message-visible (notmuch-show-get-message-properties)
+	 doshow)
+	until (or (not (notmuch-show-goto-message-next))
+		  (= (notmuch-show-get-depth) depth0
+(force-window-update)))
+
+(defun notmuch-show-show-hierarchy ()
+  Show this message and all its replies
+  (interactive)
+  (notmuch-show-hideshow-hierarchy 1))
+
+(defun notmuch-show-hide-hierarchy ()
+  Hide this message and all its replies
+  (interactive)
+  (notmuch-show-hideshow-hierarchy nil))
+
 (defun notmuch-show-next-button ()
   Advance point to the next button in the buffer.
   (interactive)
-- 
1.7.5.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Dima Kogan
 On Tue,  7 Jun 2011 01:20:25 -0400
 Austin Clements amdra...@mit.edu wrote:

 Also, slightly reformat dir-locals.el so that the settings align and
 to make it friendlier for future additions.

Should we also add:

(tab-always-indent . nil)
(indent-tabs-mode  . t)

Otherwise the setups of people who normally use spaces will still
insert spaces when 'tab' is depressed.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Austin Clements
Quoth Dmitry Kurochkin on Jun 07 at  9:27 am:
 Hi Austin.
 
 On Tue,  7 Jun 2011 01:20:25 -0400, Austin Clements amdra...@mit.edu wrote:
  Also, slightly reformat dir-locals.el so that the settings align and
  to make it friendlier for future additions.
  ---
   .dir-locals.el |   18 ++
   1 files changed, 14 insertions(+), 4 deletions(-)
  
  diff --git a/.dir-locals.el b/.dir-locals.el
  index cbdb1f9..eff29fc 100644
  --- a/.dir-locals.el
  +++ b/.dir-locals.el
  @@ -1,7 +1,17 @@
   ; emacs local configuration settings for notmuch source
   ; surmised by dkg on 2010-11-23 13:43:18-0500
  +; amended by amdragon on 2011-06-06
   
  -((c-mode . ((indent-tabs-mode . t)
  -(tab-width . 8)
  -(c-basic-offset . 4)
  -(c-file-style . linux
  +((c-mode
  +  (indent-tabs-mode . t)
  +  (tab-width . 8)
  +  (c-basic-offset . 4)
  +  (c-file-style . linux))
  + (c++-mode
  +  (indent-tabs-mode . t)
  +  (tab-width . 8)
  +  (c-basic-offset . 4)
  +  (c-file-style . linux))
  + (emacs-lisp-mode
  +  (indent-tabs-mode . t))
  + )
 
 Why tab-width is not set for the emacs-lisp-mode?

Because I forgot to set it.  ]:--8)

 Also, perhaps we should set these variables for all modes?  Setting
 c-basic-offset and c-file-style should not hurt.  And indent-tabs-mode
 and tab-width should be relevant for any file in notmuch (shell, python,
 probably even text files), no?

Personally, I would prefer to keep .dir-locals conservative, rather
than make sweeping settings.  For example, the Python code isn't (and
definitely shouldn't be) using tabs.  Adding settings for shell is a
good idea, though.

 Regards,
   Dmitry
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Add dir-locals style variables for C++ and Elisp code.

2011-06-07 Thread Austin Clements
On Tue, Jun 7, 2011 at 2:38 AM, Dima Kogan notm...@dima.secretsauce.net wrote:
 On Tue,  7 Jun 2011 01:20:25 -0400
 Austin Clements amdra...@mit.edu wrote:

 Also, slightly reformat dir-locals.el so that the settings align and
 to make it friendlier for future additions.

 Should we also add:

 (tab-always-indent . nil)

tab-always-indent is a user-interface preference and definitely
shouldn't be overridden by .dir-locals.  (Personally, I would go crazy
if I had tab-always-indent set to nil.)

 (indent-tabs-mode  . t)

I'll add this for shell-mode.  As I pointed out in my reply to Dmitry,
this shouldn't be set globally.  Are there any other specific modes it
should be set for?

 Otherwise the setups of people who normally use spaces will still
 insert spaces when 'tab' is depressed.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: When will we have our next release?

2011-06-07 Thread Jameson Graef Rollins
On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth cwo...@cworth.org wrote:
 Frankly, I wouldn't mind doing strict time-based releases with something
 like the following:

Hi, Carl.  I think this is a fine idea, and we (not you) can definitely
run this process.  I'm quite sure that at least bremner and I can
completely handle this together, and I'm sure we can get others to help.

But the mechanics of the actual release are not the problem.  The
problem is the current one-person bottleneck for all patches: your
review and merge of all patches into the notmuch/master branch.  This
would not necessarily be a problem if you could get to reviewing and
merging patches more frequently.  But as it is now, if there are no new
patches on notmuch/master for longer than the release period, there will
be nothing to package and upload.

This is *not* meant to be an indictment of you at all.  I know it's
incredibly hard to keep up with the incoming patch flow.  It takes a lot
of time and work to review every patch.  I also really like your
reviews.  They are incredibly thorough and insightful, and I always
learn from them.  Your intimate knowledge of the code base also means
that you can frequently come up with cleaner solutions to the proposed
patches (as with the reworked part handling).

However, the bottleneck presents a big problem when delays are
introduced.  We can't really do anything until you can get to the
review.  Furthermore, even if we do push ahead to put together a release
candidate branch (as we did with 0.6), if your review severely alters
patches early in that branch we have to do a lot of work to rework their
decedents (as we did with 0.6).  This leads to a lot of inefficiencies.

So we need to figure out a way to break the bottleneck.

I would really like to continue to get your review of patches.  I think
they're just too valuable.  So it would be really nice if one of the
solutions was a way to just grease the bottleneck, so to speak.  For
instance, if you could commit to reviewing just 1 patch series a week we
would be way ahead of where we have been.

Another thing that would help would be to delegate responsibility of
certain components to others, as you have with the python binding to
spaetz.  For instance, we have at least a couple of elisp experts
hanging around.  Maybe you could cede handling of all emacs patches to
someone like jkr or dme, and to felipe for vim, etc. (if they're willing
to take on those rolls).  That would help reduce your burden a bit.

We could also formalize some sort of tiered review system.  amdragon has
been doing a really good job of frequently providing good review of
patches on list.  I think that any proposed patch that gets a thumbs up
From someone like amdragon should immediately be elevated in your queue,
or just applied out-right.  If the review of others explicitly helped
get patches merged faster, I'm quite sure it would encourage more folks
to submit their reviews as well.

I would love to hear any other ideas people have on this front.

Notmuch is an incredible project, with an absolutely incredible
development community.  It's an absolute joy to work on.  If we can just
grease the wheels a little bit to get releases out the door a little
quicker, I think we'll all be a lot happier.

jamie.


pgpq6sW2gCncv.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: When will we have our next release?

2011-06-07 Thread Sebastian Spaeth
On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins wrote:

 I would love to hear any other ideas people have on this front.

I agree that delegation of bindings (and potentially the emacs code) is
a good thing. I believe both areas are separate enough to be
delegated. Perhaps have a similar tiered sytem with a different
lieutenant for the elisp code would be acceptable?

As for notmuch core, I do like the careful reviews and would prefer if
cworth still nodded off patch series, but a tiered review system, where
amdragon's nod off is enough to get patches at the top of cworth queue
would be great too.

 Notmuch is an incredible project, with an absolutely incredible
 development community.  It's an absolute joy to work on.
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de :)

spaetz


pgpUewLWvTMMr.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch