[notmuch] Git feature branch
* martin f krafft (madduck at madduck.net) wrote:
> also sprach micah anderson [2010.01.27.1124 +1300]:
> > Personally, I've found mailing lists that have patches sent to
> > them tends to totally kill the list for anything else. It seems
> > a bit weird to use Debian's bug tracker for a non-Debian native
> > program (but using it for the Debian package of notmuch does make
> > sense). I am not so familiar with Roundup, patch queue trackers or
> > patchwork to have anything to say about those.
>
> patchwork integrates with the mailing list and slurps patches and
> related discussion and threads them into a webpage, where they can
> be workflow-managed.
>
> The Debian bug tracker has the benefit of being usable with e-mail
> (and this is notmuch we're developing, don't forget). The others are
> all exclusively web-based, with the exception of launchpad, AFAIK.
As I use some of the other options...
Roundup has command line and email interfaces. The email interface is
quite similar to debian's. I've never used a launchpad hosted project
so I can't compare it.
Google's codereview tool has a nice interface for collecting and
commenting on patches, but I suspect that suggestion will also meet with
a degree of friction. To me codereview feels like patchwork with
polish.
Both gitorious and github have commenting functionality built in.
Commenting on commits in a fork is as easy as opening the commit in
a browser. I use something along the lines of the following script to
open commits on github:
#! /bin/sh
BASE=$(git config remote.${2:-origin}.url | sed
's,git\(@\|://\)\([^:/]*\)[:/]\(.*\).git,http://\2/\3/commit,')
COMMIT=$(git rev-parse ${1:-HEAD})
sensible-browser ${BASE}/${COMMIT}
Using github or gitorious you can easily find and track forks from one
place as well, which makes discovering new work much easier. Github
even provides a pretty single page interface to the work going on in
other forks, gitorious requires a little more leg work to do the same
but not much.
For a couple of hosted projects we use at the office we email the
individual entries from http://github.com/$user/$project/comments.atom
to the mailing list so they're /forcibly/ seen by everybody :)
Thanks,
James
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
Re: [notmuch] Git feature branch
* martin f krafft (madd...@madduck.net) wrote:
also sprach micah anderson mi...@riseup.net [2010.01.27.1124 +1300]:
Personally, I've found mailing lists that have patches sent to
them tends to totally kill the list for anything else. It seems
a bit weird to use Debian's bug tracker for a non-Debian native
program (but using it for the Debian package of notmuch does make
sense). I am not so familiar with Roundup, patch queue trackers or
patchwork to have anything to say about those.
patchwork integrates with the mailing list and slurps patches and
related discussion and threads them into a webpage, where they can
be workflow-managed.
The Debian bug tracker has the benefit of being usable with e-mail
(and this is notmuch we're developing, don't forget). The others are
all exclusively web-based, with the exception of launchpad, AFAIK.
As I use some of the other options...
Roundup has command line and email interfaces. The email interface is
quite similar to debian's. I've never used a launchpad hosted project
so I can't compare it.
Google's codereview tool has a nice interface for collecting and
commenting on patches, but I suspect that suggestion will also meet with
a degree of friction. To me codereview feels like patchwork with
polish.
Both gitorious and github have commenting functionality built in.
Commenting on commits in a fork is as easy as opening the commit in
a browser. I use something along the lines of the following script to
open commits on github:
#! /bin/sh
BASE=$(git config remote.${2:-origin}.url | sed
's,git\(@\|://\)\([^:/]*\)[:/]\(.*\).git,http://\2/\3/commit,')
COMMIT=$(git rev-parse ${1:-HEAD})
sensible-browser ${BASE}/${COMMIT}
Using github or gitorious you can easily find and track forks from one
place as well, which makes discovering new work much easier. Github
even provides a pretty single page interface to the work going on in
other forks, gitorious requires a little more leg work to do the same
but not much.
For a couple of hosted projects we use at the office we email the
individual entries from http://github.com/$user/$project/comments.atom
to the mailing list so they're /forcibly/ seen by everybody :)
Thanks,
James
pgpIpxyv08ZLr.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 2/9] Adjust autoload comments
[Sorry, I'm flipping back and forth between mail clients at the moment and I appear to have inadvertently marked a lot of mail as read that wasn't.] Excerpts from Carl's message of Fri Dec 04 01:07:07 + 2009: > On Mon, 30 Nov 2009 20:38:00 +0000, James Rowe wrote: > > I had planned on posting a patch for inclusion in packaging/Gentoo per > > Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the > > backburner and I haven't looked again. Might still be useful to people > > unless there is going to be a "real" release soon, as then it would be > > easier to push for it on bugs.gentoo.org. > > Is the GPLv3 a problem for you and your ebuild for some reason, or is it > just that you happened to start with a GPLv2 file or so? GPL v3 isn't a problem for me personally. The problem is Gentoo ebuilds in the main tree are all GPL v2, and I accepted changes with a clear GPL v2 header on the ebuild. I don't claim to understand the licensing stuff enough to know if mixing the two together is valid, so I just moved on to something more fun. I might have pushed the issue if it was important, but it isn't even a valuable change. > I'm definitely interested in hearing, since this is the first project > I've let loose myself under the GPLv3. So far, it hasn't seemed to be a > big impediment to contributions, which I think is great. It definitely doesn't seem to have been an impediment. git-rank-contributors shows 29 contributors already, and that is very impressive given the age of the project. -- Thanks, James -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 290 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091217/f651b40e/attachment.pgp>
Re: [notmuch] [PATCH 2/9] Adjust autoload comments
[Sorry, I'm flipping back and forth between mail clients at the moment and I appear to have inadvertently marked a lot of mail as read that wasn't.] Excerpts from Carl's message of Fri Dec 04 01:07:07 + 2009: On Mon, 30 Nov 2009 20:38:00 +, James Rowe wrote: I had planned on posting a patch for inclusion in packaging/Gentoo per Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the backburner and I haven't looked again. Might still be useful to people unless there is going to be a real release soon, as then it would be easier to push for it on bugs.gentoo.org. Is the GPLv3 a problem for you and your ebuild for some reason, or is it just that you happened to start with a GPLv2 file or so? GPL v3 isn't a problem for me personally. The problem is Gentoo ebuilds in the main tree are all GPL v2, and I accepted changes with a clear GPL v2 header on the ebuild. I don't claim to understand the licensing stuff enough to know if mixing the two together is valid, so I just moved on to something more fun. I might have pushed the issue if it was important, but it isn't even a valuable change. I'm definitely interested in hearing, since this is the first project I've let loose myself under the GPLv3. So far, it hasn't seemed to be a big impediment to contributions, which I think is great. It definitely doesn't seem to have been an impediment. git-rank-contributors shows 29 contributors already, and that is very impressive given the age of the project. -- Thanks, James signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 2/9] Adjust autoload comments
Firstly, thanks for the full explanations! On Thu, 03 Dec 2009 17:04:52 -0800, Carl Worth wrote: > The notmuch-folder command is definitely a nice primary interface to > notmuch for some people. I'm seriously considering making it the view > that one gets with "M-x notmuch" (after the notmuch-folder view gets a > little sprucing up). Coming from sup and being a gmail user "emacs -f notmuch" seems like the natural mail interface to me. Still, even if the default view changes I can switch to just opening a tag:inbox search. I've left the elisp-make-autoload-file change in our builds, which means all the ";;;###autoload" enveloped functions are available. Nobody seems to be upset by the change. > As for notmuch-search, I find it very convenient to have the ability to > do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it) > From any random emacs buffer. If you don't live inside emacs, and just > have a single emacs frame open for notmuch sake, maybe that's not as > interesting. Carl, you've got me pegged. I use the /other/ editor, I only installed emacs for notmuch. For me, I've already managed to train myself to just fire up notmuch and hit 's' when searching. The extra search buffer that method creates makes no difference to my personal usage patterns. -- Thanks, James
[notmuch] [PATCH 2/9] Adjust autoload comments
On Sat, 28 Nov 2009 09:27:00 -0800, Keith Amidon
wrote:
> I was interested in them because the gentoo packaging support for emacs
> includes the ability to automatically create autoloads from these
> comments for installed add-on packages that then get loaded system-wide
> when emacs is started.
I have to admit I played with elisp-make-autoload-file in my ebuild
initially, but came to the conclusion there wasn't a great deal of
purpose to exposing more than the main notmuch function. Mostly because
it muddies my emacs and shell autocompletion, and my laziness prevailed.
Am I missing some obviously useful things that can be done if
notmuch-{folder,search} are available directly?
I just pushed out an update that uses it, mostly so I can see the
reaction of my work colleagues in the morning. So, it may or may not be
there by lunchtime GMT tomorrow :)
> I've my own ebuild using this functionality right now that is just
> slightly different from the one that was posted here a little while ago.
> I've been meaning to merge my version with that one but haven't gotten
> to it yet.
Post a link! If it is better than mine I'll happily switch our
installs to it.
If you're merging the two please look at the github version[1] as it
is significantly different from the version I originally posted, almost
entirely as a result of the helpful contributions from others.
I had planned on posting a patch for inclusion in packaging/Gentoo per
Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the
backburner and I haven't looked again. Might still be useful to people
unless there is going to be a "real" release soon, as then it would be
easier to push for it on bugs.gentoo.org.
1. http://github.com/JNRowe/misc-overlay/tree/master/mail-client/notmuch/
2. id:87lji1k014.fsf at yoom.home.cworth.org
--
Thanks,
James
[notmuch] [PATCH] Missing final semi-colon in .desktop's Categories.
"Those keys which have several values should have a semicolon as the trailing character." -- http://standards.freedesktop.org/desktop-entry-spec/1.0/ar01s03.html Signed-off-by: James Rowe --- notmuch.desktop |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch.desktop b/notmuch.desktop index d29dff6..819cd1e 100644 --- a/notmuch.desktop +++ b/notmuch.desktop @@ -4,4 +4,4 @@ Exec=emacs -f notmuch Icon=emblem-mail Terminal=false Type=Application -Categories=Network;Email +Categories=Network;Email; -- 1.6.4.4
[notmuch] Gentoo ebuild for notmuch
On Fri, 20 Nov 2009 10:39:35 +0100, Carl Worth wrote: > If you think it makes sense, I can add this to the notmuch repository in > a packaging/gentoo directory. Just let me know if you'd like that. Hmm... The problem is the ebuild can't currently use the install target because the file locations are incorrect for Gentoo[1]. Which means it could require quite a bit of churn to keep it synced as the build process changes. The patch that follows makes it easier to use the install target within the ebuild. If this sort of change is acceptable then the ebuild will be simpler, and it is more likely to stay working without me kicking heaps of patches at you. Given that I'd say "yes, please include it." Thanks, James 1. fex. Bash completion files are installed in to /usr/share/bash-completion, then enabled via a link in /etc/bash_completion.d if desired
[notmuch] [PATCH] Make bash completion directory configurable.
Some systems install completion scripts in /usr/share/bash-completion, make the location configurable from Makefile.config. --- Makefile.config |1 + Makefile.local |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile.config b/Makefile.config index 63c90a8..d72a39e 100644 --- a/Makefile.config +++ b/Makefile.config @@ -1 +1,2 @@ prefix = /usr/local +bash_completion_dir = /etc/bash_completion.d diff --git a/Makefile.local b/Makefile.local index ecd4ceb..1017a8c 100644 --- a/Makefile.local +++ b/Makefile.local @@ -27,14 +27,14 @@ notmuch.1.gz: notmuch.1 install: all notmuch.1.gz for d in $(DESTDIR)$(prefix)/bin/ $(DESTDIR)$(prefix)/share/man/man1 \ - $(DESTDIR)/etc/bash_completion.d/ ; \ + $(DESTDIR)$(bash_completion_dir) ; \ do \ install -d $$d ; \ done ; install notmuch $(DESTDIR)$(prefix)/bin/ install -m0644 notmuch.1.gz $(DESTDIR)$(prefix)/share/man/man1/ install notmuch-completion.bash \ - $(DESTDIR)/etc/bash_completion.d/notmuch + $(DESTDIR)$(bash_completion_dir)/notmuch install-emacs: install emacs for d in $(DESTDIR)/$(emacs_lispdir) ; \ -- 1.6.4.4
[notmuch] link error
* Peter Wang (novalazy at gmail.com) wrote: > Linking fails on my system for some reason (undefined references to > talloc functions). Putting $(LDFLAGS) after the object list solves it. I have a similar ordering change in the ebuild I posted earlier as a workaround for people using ld's --as-needed option. Thanks, James
[notmuch] Gentoo ebuild for notmuch
Hi,
Just in case other Gentoo users are trying notmuch out I thought I'd post my
ebuild(perhaps you'll make it better for me too :). It is working well up to
at least e5da2b70.
I won't bother the list if it requires changes, as it is available from my
main overlay[1] if you wish to check for updated versions.
Thanks,
James
1. http://github.com/JNRowe/misc-overlay/tree/master/mail-client/notmuch/
-- next part --
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI="2"
inherit toolchain-funcs elisp-common bash-completion git
EGIT_REPO_URI="git://notmuchmail.org/git/${PN}"
DESCRIPTION="Thread-based email index, search and tagging."
HOMEPAGE="http://notmuchmail.org/;
SRC_URI=""
LICENSE="GPL-3"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE="emacs"
DEPEND="dev-util/pkgconfig
${RDEPEND}"
RDEPEND="sys-libs/talloc
dev-libs/gmime
dev-libs/xapian
emacs? ( virtual/emacs )"
SITEFILE="50${PN}-gentoo.el"
src_prepare() {
# Change ordering in case people are using as-needed
sed -i 's,\($(LDFLAGS)\)\(.*\),\2 \1,' Makefile.local
}
src_compile() {
emake CC="$(tc-getCC)" CXX="$(tc-getCXX)" CFLAGS="${CFLAGS}" \
|| die "emake failed"
if use emacs; then
elisp-compile ${PN}.el || die "elisp-compile failed"
fi
}
src_install() {
# Don't use make install, because it installs compressed man pages,
# bash-completion in the wrong location and emacs files unconditionally.
# Three commands are quicker than patching Makefile.local locally.
dobin ${PN}
doman ${PN}.1
dobashcompletion notmuch-completion.bash ${PN}
dodoc AUTHORS README TODO
if use emacs; then
elisp-install ${PN}{,.el}
elisp-site-file-install "${FILESDIR}/${SITEFILE}"
fi
}
-- next part --
; notmuch site-list config
(add-to-list 'load-path "@SITELISP@")
(autoload 'notmuch "notmuch" "Start notmuch" t)
