When will we have our next release?
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>
Re: When will we have our next release?
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 pgpUewLWvTMMr.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: When will we have our next release?
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 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
When will we have our next release?
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.
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.
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.
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.
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
Re: [PATCH] Add dir-locals style variables for C++ and Elisp code.
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. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
