Re: [notmuch] Git feature branch

[Carl Worth]

On Wed, 03 Feb 2010 22:58:05 -0500, Jameson Rollins 
 wrote:
> Once the project becomes more mature and other developers are
> vetting patches, then their branches can take over as "master" in the
> absence of an outdated canonical master.

The other thing that will happen as the project matures is that I expect
to start merging other people's carefully vetted and reviewed
branches. This will happen as people start to take ownership of
particular code areas and we establish mutual trust on taste, code
review, testing, etc.

I think that will be the real solution for future bottlenecks when I'm
not available for much patch review due to travel, sickness,
hectic-life-in-general, etc.

-Carl


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

[notmuch] Git feature branch

[Carl Worth]

On Wed, 03 Feb 2010 22:58:05 -0500, Jameson Rollins  wrote:
> Once the project becomes more mature and other developers are
> vetting patches, then their branches can take over as "master" in the
> absence of an outdated canonical master.

The other thing that will happen as the project matures is that I expect
to start merging other people's carefully vetted and reviewed
branches. This will happen as people start to take ownership of
particular code areas and we establish mutual trust on taste, code
review, testing, etc.

I think that will be the real solution for future bottlenecks when I'm
not available for much patch review due to travel, sickness,
hectic-life-in-general, etc.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Re: [notmuch] Git feature branch

[Carl Worth]

On Wed, 27 Jan 2010 14:17:39 -0500, Ben Gamari  wrote:
> I agree. There is no good reason to switch away from the existing
> infrastructure. If he wants, Carl can give regular contributors their
> own repositories on notmuchmail.org if some people have difficulties
> providing it themselves. After all, this is one of the strengths of
> distributed version control.

I should emphasize that point:

I think it's great that people are posting their own notmuch
repositories wherever they see fit. Please continue doing that.

Also, if anybody would like to host such a repository on the
notmuchmail.org server, I'm more than happy to arrange that. Just let me
know.

-Carl


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

[notmuch] Git feature branch

[Carl Worth]

On Wed, 27 Jan 2010 14:17:39 -0500, Ben Gamari  wrote:
> I agree. There is no good reason to switch away from the existing
> infrastructure. If he wants, Carl can give regular contributors their
> own repositories on notmuchmail.org if some people have difficulties
> providing it themselves. After all, this is one of the strengths of
> distributed version control.

I should emphasize that point:

I think it's great that people are posting their own notmuch
repositories wherever they see fit. Please continue doing that.

Also, if anybody would like to host such a repository on the
notmuchmail.org server, I'm more than happy to arrange that. Just let me
know.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] Git feature branch

[martin f krafft]

also sprach Carl Worth  [2010.02.04.1605 +1300]:
> >   maint/? the stable release
> >   master/   ? the stablising head
> >   next/ ? testing branch
> >   pu/   ? patch integration branch (proposed updates)
> 
> I'm not a fan of this scheme, (or maybe I've just never quite understood
> it).
> 
> When I first encountered this scheme, (when first using git), it was
> never clear to me what branch I should actually run or test as a
> user. Nor was it obvious which branches would be regularly rebased or
> not---nor which branches had features being discussed on the mailing
> list.

I'll happily explain if you want. I think that this workflow, in
combination with the distributed functionality of Git, makes for
really powerful collaboration.

To answer your two (implicit) questions directly:

- as a user, you'd probably be tracking master, if you aren't
  running a stable release anyway. if you are ready to deal with the
  occasional bug and want some juicy stuff, go with next. if you are
  a developer ready to fend of the sh*t as it hits the fan, use pu.

  Basically, it's a bit like Debian testing/unstable/experiemental,
  except that the default entry point for new patches (packages in
  that analogy) is pu (experimental), not next (unstable, as it is
  in Debian).

  maint is then the stable branch, see below.

- nothing is ever rebased. patches are cherry-picked downwards
  (pu?next?master) and branches are occasionally merged upwards
  (master into next, next into pu).

I don't think we will need 'next' anytime soon, not until we have
a situation where we are e.g. working on the next 1.x release by
already have 2.0 on the horizon.

The important distinction is between pu (proposed-updates) and
master. The goal for master should always be that it's usable.
Features that are too new to ensure that go to pu until they
matured.

> Instead of "maint" I'd much rather just have branches that are
> named directly after the stable releases being maintained. We've
> done this with the cairo repository with branch names like "1.2",
> "1.4", "1.6", etc. That way it's very clear what the branch
> represents and it's possible to have multiple concurrent "live"
> maintenance branches. But of course, until we actually have
> releases, this doesn't really matter. :-)

This is all possible to do. It has no impact on the pu/next/master
distinction. Basically, once a release is made, master is merged
into maint (I think) and tagged. If a maintenance release has to be
made, a maint/1.0 branch is created. I don't think Git/Linux do
that, but I do.

> I want to maintain a branch myself, (where I'm the only person
> pushing to the branch). [This is different than what I've done
> with the cairo repository where we have all core maintainer's
> pushing to a central repository. I'm intentionally trying
> something new here.]

Do you want to maintain that branch yourself for your own purposes,
or do you want to be the sole maintainer of the branch that is
advertised as *the* notmuch branch, and from which future releases
are made?

> Obviously, that branch that I maintain is currently called
> "master", but I wouldn't mind (and might actually prefer) to have
> it be called "~cworth" or so. Though we have the problem that we
> need "master" to point to *something*.

Actually, there is no reason for master to exist at all. ;)
It's just the default, but it's not intrinsic.

> Beyond that, I'm quite happy to have any number of branches similarly
> maintained by any other individuals. I want to get things setup so that
> those will be hosted and listed alongside my branch on
> notmuchmail.org.

So you are talking repos, not branches. I know they are almost the
same, but branches live in repos, and if you want to be the only
person pushing to a branch, you need to be the only one with write
access to the containing repo ? unless you use gitolite, which can
do in-repo per-branch access control.

> > What patch tracking workflow should we adopt? Keep sending
> > patches to the mailing list
> 
> I definitely like the patches on the list. I find that with
> notmuch, I can maintain a queue of outstanding patches very
> effectively, (meaning, that the queue is usable and doesn't forget
> even if I do get very far behind like I am currently).

The reason why I set up patchwork is because you might have spent
hours triaging some patches already, e.g. bringing the count from
400 to 100. Since I cannot really "pull" your tags, I am forced to
go through the entire list myself.

> > master or pu (or even maint/next), as appropriate? Use the
> > Debian bug tracker? Use Sebastian's Roundup instance? Set up
> > a patch queue manager on notmuchmail.org? Use patchwork [1]?
>
> I'm personally not interested in any system that requires me to
> push any additional buttons outside of notmuch and git itself.
> I am interested in tools that can generate reports and help
> provide visibility into things. So patchwork fixed to
> automatically notice wh

[notmuch] Git feature branch

[Jameson Rollins]

On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth  wrote:
> I want to maintain a branch myself, (where I'm the only person pushing
> to the branch). [This is different than what I've done with the cairo
> repository where we have all core maintainer's pushing to a central
> repository. I'm intentionally trying something new here.]

Just my 2 cents here, but I fully support the idea of perusing a fully
distributed development model.  I have been using it on other projects I
work on and it works great.

> Obviously, that branch that I maintain is currently called "master", but
> I wouldn't mind (and might actually prefer) to have it be called
> "~cworth" or so. Though we have the problem that we need "master" to
> point to *something*.

There's really no need to do that.  For others developers, they would
just add your repo as a "remote", which would presumably be named
something like "cworth".  Then in the developers repo your master branch
would be named "cworth/master".

With a crew of developers, A, B, C, etc., each one would add the others
as remotes, and their branches would be visible under their remotes, ie:

C at host:~$ git branch -a
master
foo
bar
remotes/A/master
remotes/A/foo
remotes/B/master
remotes/B/foo
...

> Beyond that, I'm quite happy to have any number of branches similarly
> maintained by any other individuals. I want to get things setup so that
> those will be hosted and listed alongside my branch on
> notmuchmail.org. And I'll be happy to accept pull requests from
> people. I expect to find people naturally gravitating to "ownership" or
> particular portions of the code, where I will gain a lot of trust for
> particular maintainers over the code they own.

I think this is the right idea.

I think the problem we've been having recently is that we have bit of a
patch backlog due to circumstances of Carl's travel.  This is an issue
because the project is new and people are eager to see their
contributions in place.  I'm sure Carl will get to them as fast as he
can.  Once the project becomes more mature and other developers are
vetting patches, then their branches can take over as "master" in the
absence of an outdated canonical master.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [notmuch] Git feature branch

[Jameson Rollins]

On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth  wrote:
> I want to maintain a branch myself, (where I'm the only person pushing
> to the branch). [This is different than what I've done with the cairo
> repository where we have all core maintainer's pushing to a central
> repository. I'm intentionally trying something new here.]

Just my 2 cents here, but I fully support the idea of perusing a fully
distributed development model.  I have been using it on other projects I
work on and it works great.

> Obviously, that branch that I maintain is currently called "master", but
> I wouldn't mind (and might actually prefer) to have it be called
> "~cworth" or so. Though we have the problem that we need "master" to
> point to *something*.

There's really no need to do that.  For others developers, they would
just add your repo as a "remote", which would presumably be named
something like "cworth".  Then in the developers repo your master branch
would be named "cworth/master".

With a crew of developers, A, B, C, etc., each one would add the others
as remotes, and their branches would be visible under their remotes, ie:

c...@host:~$ git branch -a
master
foo
bar
remotes/A/master
remotes/A/foo
remotes/B/master
remotes/B/foo
...

> Beyond that, I'm quite happy to have any number of branches similarly
> maintained by any other individuals. I want to get things setup so that
> those will be hosted and listed alongside my branch on
> notmuchmail.org. And I'll be happy to accept pull requests from
> people. I expect to find people naturally gravitating to "ownership" or
> particular portions of the code, where I will gain a lot of trust for
> particular maintainers over the code they own.

I think this is the right idea.

I think the problem we've been having recently is that we have bit of a
patch backlog due to circumstances of Carl's travel.  This is an issue
because the project is new and people are eager to see their
contributions in place.  I'm sure Carl will get to them as fast as he
can.  Once the project becomes more mature and other developers are
vetting patches, then their branches can take over as "master" in the
absence of an outdated canonical master.

jamie.


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

Re: [notmuch] Git feature branch

[martin f krafft]

also sprach Carl Worth  [2010.02.04.1605 +1300]:
> >   maint/— the stable release
> >   master/   — the stablising head
> >   next/ — testing branch
> >   pu/   — patch integration branch (proposed updates)
> 
> I'm not a fan of this scheme, (or maybe I've just never quite understood
> it).
> 
> When I first encountered this scheme, (when first using git), it was
> never clear to me what branch I should actually run or test as a
> user. Nor was it obvious which branches would be regularly rebased or
> not---nor which branches had features being discussed on the mailing
> list.

I'll happily explain if you want. I think that this workflow, in
combination with the distributed functionality of Git, makes for
really powerful collaboration.

To answer your two (implicit) questions directly:

- as a user, you'd probably be tracking master, if you aren't
  running a stable release anyway. if you are ready to deal with the
  occasional bug and want some juicy stuff, go with next. if you are
  a developer ready to fend of the sh*t as it hits the fan, use pu.

  Basically, it's a bit like Debian testing/unstable/experiemental,
  except that the default entry point for new patches (packages in
  that analogy) is pu (experimental), not next (unstable, as it is
  in Debian).

  maint is then the stable branch, see below.

- nothing is ever rebased. patches are cherry-picked downwards
  (pu→next→master) and branches are occasionally merged upwards
  (master into next, next into pu).

I don't think we will need 'next' anytime soon, not until we have
a situation where we are e.g. working on the next 1.x release by
already have 2.0 on the horizon.

The important distinction is between pu (proposed-updates) and
master. The goal for master should always be that it's usable.
Features that are too new to ensure that go to pu until they
matured.

> Instead of "maint" I'd much rather just have branches that are
> named directly after the stable releases being maintained. We've
> done this with the cairo repository with branch names like "1.2",
> "1.4", "1.6", etc. That way it's very clear what the branch
> represents and it's possible to have multiple concurrent "live"
> maintenance branches. But of course, until we actually have
> releases, this doesn't really matter. :-)

This is all possible to do. It has no impact on the pu/next/master
distinction. Basically, once a release is made, master is merged
into maint (I think) and tagged. If a maintenance release has to be
made, a maint/1.0 branch is created. I don't think Git/Linux do
that, but I do.

> I want to maintain a branch myself, (where I'm the only person
> pushing to the branch). [This is different than what I've done
> with the cairo repository where we have all core maintainer's
> pushing to a central repository. I'm intentionally trying
> something new here.]

Do you want to maintain that branch yourself for your own purposes,
or do you want to be the sole maintainer of the branch that is
advertised as *the* notmuch branch, and from which future releases
are made?

> Obviously, that branch that I maintain is currently called
> "master", but I wouldn't mind (and might actually prefer) to have
> it be called "~cworth" or so. Though we have the problem that we
> need "master" to point to *something*.

Actually, there is no reason for master to exist at all. ;)
It's just the default, but it's not intrinsic.

> Beyond that, I'm quite happy to have any number of branches similarly
> maintained by any other individuals. I want to get things setup so that
> those will be hosted and listed alongside my branch on
> notmuchmail.org.

So you are talking repos, not branches. I know they are almost the
same, but branches live in repos, and if you want to be the only
person pushing to a branch, you need to be the only one with write
access to the containing repo — unless you use gitolite, which can
do in-repo per-branch access control.

> > What patch tracking workflow should we adopt? Keep sending
> > patches to the mailing list
> 
> I definitely like the patches on the list. I find that with
> notmuch, I can maintain a queue of outstanding patches very
> effectively, (meaning, that the queue is usable and doesn't forget
> even if I do get very far behind like I am currently).

The reason why I set up patchwork is because you might have spent
hours triaging some patches already, e.g. bringing the count from
400 to 100. Since I cannot really "pull" your tags, I am forced to
go through the entire list myself.

> > master or pu (or even maint/next), as appropriate? Use the
> > Debian bug tracker? Use Sebastian's Roundup instance? Set up
> > a patch queue manager on notmuchmail.org? Use patchwork [1]?
>
> I'm personally not interested in any system that requires me to
> push any additional buttons outside of notmuch and git itself.
> I am interested in tools that can generate reports and help
> provide visibility into things. So patchwork fixed to
> automatically notice wh

Re: [notmuch] Git feature branch

[Carl Worth]

On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft  wrote:
> I discussed this with Carl at LCA a bit and ideally we should come
> up with a way to relieve Carl of the bottleneck burden (obviously
> without stealing away his dictator hat ;)

Sounds great! Let's keep working together and find ways to help our
community work together. And I really appreciate all the help!

> I think it would make sense to move the mainline to git.debian.org
> for now, or another place where everyone can easily get an account.
> As alternatives I propose repo.or.cz. I'd prefer to stay away from
> commercial services like Github.

I'm glad to help make things work on notmuchmail.org directly. I don't
have a problem giving out shell access to people who want to help set
things up the way we want. (And prototyping things elsewhere is fine
too.)

> Once we're there, how about copying the branch structure from
> Git development[0]:
> 
>   maint/— the stable release
>   master/   — the stablising head
>   next/ — testing branch
>   pu/   — patch integration branch (proposed updates)

I'm not a fan of this scheme, (or maybe I've just never quite understood
it).

When I first encountered this scheme, (when first using git), it was
never clear to me what branch I should actually run or test as a
user. Nor was it obvious which branches would be regularly rebased or
not---nor which branches had features being discussed on the mailing
list.

Here are some of my thoughts:

Instead of "maint" I'd much rather just have branches that are named
directly after the stable releases being maintained. We've done this
with the cairo repository with branch names like "1.2", "1.4", "1.6",
etc. That way it's very clear what the branch represents and it's
possible to have multiple concurrent "live" maintenance branches. But of
course, until we actually have releases, this doesn't really matter. :-)

I want to maintain a branch myself, (where I'm the only person pushing
to the branch). [This is different than what I've done with the cairo
repository where we have all core maintainer's pushing to a central
repository. I'm intentionally trying something new here.]

Obviously, that branch that I maintain is currently called "master", but
I wouldn't mind (and might actually prefer) to have it be called
"~cworth" or so. Though we have the problem that we need "master" to
point to *something*.

Beyond that, I'm quite happy to have any number of branches similarly
maintained by any other individuals. I want to get things setup so that
those will be hosted and listed alongside my branch on
notmuchmail.org. And I'll be happy to accept pull requests from
people. I expect to find people naturally gravitating to "ownership" or
particular portions of the code, where I will gain a lot of trust for
particular maintainers over the code they own.

> What patch tracking workflow should we adopt? Keep sending patches
> to the mailing list

I definitely like the patches on the list. I find that with notmuch, I
can maintain a queue of outstanding patches very effectively, (meaning,
that the queue is usable and doesn't forget even if I do get very far
behind like I am currently).

> master or pu (or even maint/next), as appropriate? Use the Debian
> bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> manager on notmuchmail.org? Use patchwork [1]?

I'm personally not interested in any system that requires me to push any
additional buttons outside of notmuch and git itself. I am interested in
tools that can generate reports and help provide visibility into
things. So patchwork fixed to automatically notice when patches are
merged would be interesting. Also interesting would be support for
publishing my notmuch-based queue of patches to a web page.

-Carl


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

[notmuch] Git feature branch

[Carl Worth]

On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft  
wrote:
> I discussed this with Carl at LCA a bit and ideally we should come
> up with a way to relieve Carl of the bottleneck burden (obviously
> without stealing away his dictator hat ;)

Sounds great! Let's keep working together and find ways to help our
community work together. And I really appreciate all the help!

> I think it would make sense to move the mainline to git.debian.org
> for now, or another place where everyone can easily get an account.
> As alternatives I propose repo.or.cz. I'd prefer to stay away from
> commercial services like Github.

I'm glad to help make things work on notmuchmail.org directly. I don't
have a problem giving out shell access to people who want to help set
things up the way we want. (And prototyping things elsewhere is fine
too.)

> Once we're there, how about copying the branch structure from
> Git development[0]:
> 
>   maint/? the stable release
>   master/   ? the stablising head
>   next/ ? testing branch
>   pu/   ? patch integration branch (proposed updates)

I'm not a fan of this scheme, (or maybe I've just never quite understood
it).

When I first encountered this scheme, (when first using git), it was
never clear to me what branch I should actually run or test as a
user. Nor was it obvious which branches would be regularly rebased or
not---nor which branches had features being discussed on the mailing
list.

Here are some of my thoughts:

Instead of "maint" I'd much rather just have branches that are named
directly after the stable releases being maintained. We've done this
with the cairo repository with branch names like "1.2", "1.4", "1.6",
etc. That way it's very clear what the branch represents and it's
possible to have multiple concurrent "live" maintenance branches. But of
course, until we actually have releases, this doesn't really matter. :-)

I want to maintain a branch myself, (where I'm the only person pushing
to the branch). [This is different than what I've done with the cairo
repository where we have all core maintainer's pushing to a central
repository. I'm intentionally trying something new here.]

Obviously, that branch that I maintain is currently called "master", but
I wouldn't mind (and might actually prefer) to have it be called
"~cworth" or so. Though we have the problem that we need "master" to
point to *something*.

Beyond that, I'm quite happy to have any number of branches similarly
maintained by any other individuals. I want to get things setup so that
those will be hosted and listed alongside my branch on
notmuchmail.org. And I'll be happy to accept pull requests from
people. I expect to find people naturally gravitating to "ownership" or
particular portions of the code, where I will gain a lot of trust for
particular maintainers over the code they own.

> What patch tracking workflow should we adopt? Keep sending patches
> to the mailing list

I definitely like the patches on the list. I find that with notmuch, I
can maintain a queue of outstanding patches very effectively, (meaning,
that the queue is usable and doesn't forget even if I do get very far
behind like I am currently).

> master or pu (or even maint/next), as appropriate? Use the Debian
> bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> manager on notmuchmail.org? Use patchwork [1]?

I'm personally not interested in any system that requires me to push any
additional buttons outside of notmuch and git itself. I am interested in
tools that can generate reports and help provide visibility into
things. So patchwork fixed to automatically notice when patches are
merged would be interesting. Also interesting would be support for
publishing my notmuch-based queue of patches to a web page.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] Git feature branch

[martin f krafft]

also sprach micah anderson  [2010.01.27.1124 +1300]:
> Couldn't all of this be done without moving the existing git
> repository (don't forget that transition is a cost)? Those who
> wish to put together these proposed branches go ahead and do so,
> publishing those wherever they like (git.debian.org, gitorious,
> their own hosted git repositories, or even github) and then Carl
> can just add those as remotes as he sees fit.

I brought this up, so I should make the motivation explicit: I just
tried to relieve Carl from the burden of bottleneck. Since passing
out SSH accounts on his own machine does not really scale, I looked
elsewhere.

However, I agree that the easiest solution is just to add more
users. Potentially, Carl can make use of gitolite, I can investigate
that some time this week.

> 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.

The idea of having a tracker is quite simply to make it easier for
Carl to stay on top, and for e.g. you and I to assist him by vetting
patches in our free minutes.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

there's an old proverb that says just about whatever you want it to.

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 

[notmuch] Git feature branch

[James Rowe]

* 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

[James Rowe]

* martin f krafft (madd...@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



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

[notmuch] Git feature branch

[Jameson Rollins]

On Wed, 27 Jan 2010 11:24:15 +1300, micah anderson  wrote:
> Couldn't all of this be done without moving the existing git repository
> (don't forget that transition is a cost)? Those who wish to put together
> these proposed branches go ahead and do so, publishing those wherever
> they like (git.debian.org, gitorious, their own hosted git repositories,
> or even github) and then Carl can just add those as remotes as he sees
> fit.

I second this idea.  I've been working on quite a few projects that work
in this way, with nothing but personal distributed repos, and it works
quite well.  Especially if Carl is going to continue to be benevolent
dictator (as I agree that he should).  Everyone who has patches can just
post them to their personal repos, making sure that they're well rebased
to Carl's master, and Carl can just pull from them as he sees fit.  It's
what git is designed to do, and it actually works really well.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[notmuch] Git feature branch

[Ben Gamari]

Excerpts from micah anderson's message of Tue Jan 26 17:24:15 -0500 2010:
> On Mon, 25 Jan 2010 16:46:43 -0800, sebastian at sspaeth.de wrote:
> > > I think it would make sense to move the mainline to git.debian.org
> > > for now, or another place where everyone can easily get an account.
> > > As alternatives I propose repo.or.cz. I'd prefer to stay away from
> > > commercial services like Github.
> 
> I too prefer to stay away from commercial,non-free services like GitHub.
> Gitorious (http://www.gitorious.org/) is a great service, similar to
> Github, but with added freedom.
> 
> Currently the git repository is at git://notmuchmail.org/git/notmuch
> which seems like a fine location for it, but perhaps I missed the
> motivation for switching to a centralized repository with the added
> overhead of giving people access to commit?
> 
> Couldn't all of this be done without moving the existing git repository
> (don't forget that transition is a cost)? Those who wish to put together
> these proposed branches go ahead and do so, publishing those wherever
> they like (git.debian.org, gitorious, their own hosted git repositories,
> or even github) and then Carl can just add those as remotes as he sees
> fit.
> 
I agree. There is no good reason to switch away from the existing
infrastructure. If he wants, Carl can give regular contributors their
own repositories on notmuchmail.org if some people have difficulties
providing it themselves. After all, this is one of the strengths of
distributed version control.

- Ben

Re: [notmuch] Git feature branch

[martin f krafft]

also sprach micah anderson  [2010.01.27.1124 +1300]:
> Couldn't all of this be done without moving the existing git
> repository (don't forget that transition is a cost)? Those who
> wish to put together these proposed branches go ahead and do so,
> publishing those wherever they like (git.debian.org, gitorious,
> their own hosted git repositories, or even github) and then Carl
> can just add those as remotes as he sees fit.

I brought this up, so I should make the motivation explicit: I just
tried to relieve Carl from the burden of bottleneck. Since passing
out SSH accounts on his own machine does not really scale, I looked
elsewhere.

However, I agree that the easiest solution is just to add more
users. Potentially, Carl can make use of gitolite, I can investigate
that some time this week.

> 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.

The idea of having a tracker is quite simply to make it easier for
Carl to stay on top, and for e.g. you and I to assist him by vetting
patches in our free minutes.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
there's an old proverb that says just about whatever you want it to.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Git feature branch

[micah anderson]

On Mon, 25 Jan 2010 16:46:43 -0800, sebastian at sspaeth.de wrote:
> > I think it would make sense to move the mainline to git.debian.org
> > for now, or another place where everyone can easily get an account.
> > As alternatives I propose repo.or.cz. I'd prefer to stay away from
> > commercial services like Github.

I too prefer to stay away from commercial,non-free services like GitHub.
Gitorious (http://www.gitorious.org/) is a great service, similar to
Github, but with added freedom.

Currently the git repository is at git://notmuchmail.org/git/notmuch
which seems like a fine location for it, but perhaps I missed the
motivation for switching to a centralized repository with the added
overhead of giving people access to commit?

Couldn't all of this be done without moving the existing git repository
(don't forget that transition is a cost)? Those who wish to put together
these proposed branches go ahead and do so, publishing those wherever
they like (git.debian.org, gitorious, their own hosted git repositories,
or even github) and then Carl can just add those as remotes as he sees
fit.

> > What patch tracking workflow should we adopt? Keep sending patches
> > to the mailing list and have a few people who integrate them into
> > master or pu (or even maint/next), as appropriate? Use the Debian
> > bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> > manager on notmuchmail.org? Use patchwork [1]?

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.

micah
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [notmuch] Git feature branch

[Jameson Rollins]

On Wed, 27 Jan 2010 11:24:15 +1300, micah anderson  wrote:
> Couldn't all of this be done without moving the existing git repository
> (don't forget that transition is a cost)? Those who wish to put together
> these proposed branches go ahead and do so, publishing those wherever
> they like (git.debian.org, gitorious, their own hosted git repositories,
> or even github) and then Carl can just add those as remotes as he sees
> fit.

I second this idea.  I've been working on quite a few projects that work
in this way, with nothing but personal distributed repos, and it works
quite well.  Especially if Carl is going to continue to be benevolent
dictator (as I agree that he should).  Everyone who has patches can just
post them to their personal repos, making sure that they're well rebased
to Carl's master, and Carl can just pull from them as he sees fit.  It's
what git is designed to do, and it actually works really well.

jamie.


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

Re: [notmuch] Git feature branch

[Ben Gamari]

Excerpts from micah anderson's message of Tue Jan 26 17:24:15 -0500 2010:
> On Mon, 25 Jan 2010 16:46:43 -0800, sebast...@sspaeth.de wrote:
> > > I think it would make sense to move the mainline to git.debian.org
> > > for now, or another place where everyone can easily get an account.
> > > As alternatives I propose repo.or.cz. I'd prefer to stay away from
> > > commercial services like Github.
> 
> I too prefer to stay away from commercial,non-free services like GitHub.
> Gitorious (http://www.gitorious.org/) is a great service, similar to
> Github, but with added freedom.
> 
> Currently the git repository is at git://notmuchmail.org/git/notmuch
> which seems like a fine location for it, but perhaps I missed the
> motivation for switching to a centralized repository with the added
> overhead of giving people access to commit?
> 
> Couldn't all of this be done without moving the existing git repository
> (don't forget that transition is a cost)? Those who wish to put together
> these proposed branches go ahead and do so, publishing those wherever
> they like (git.debian.org, gitorious, their own hosted git repositories,
> or even github) and then Carl can just add those as remotes as he sees
> fit.
> 
I agree. There is no good reason to switch away from the existing
infrastructure. If he wants, Carl can give regular contributors their
own repositories on notmuchmail.org if some people have difficulties
providing it themselves. After all, this is one of the strengths of
distributed version control.

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

Re: [notmuch] Git feature branch

[micah anderson]

On Mon, 25 Jan 2010 16:46:43 -0800, sebast...@sspaeth.de wrote:
> > I think it would make sense to move the mainline to git.debian.org
> > for now, or another place where everyone can easily get an account.
> > As alternatives I propose repo.or.cz. I'd prefer to stay away from
> > commercial services like Github.

I too prefer to stay away from commercial,non-free services like GitHub.
Gitorious (http://www.gitorious.org/) is a great service, similar to
Github, but with added freedom.

Currently the git repository is at git://notmuchmail.org/git/notmuch
which seems like a fine location for it, but perhaps I missed the
motivation for switching to a centralized repository with the added
overhead of giving people access to commit?

Couldn't all of this be done without moving the existing git repository
(don't forget that transition is a cost)? Those who wish to put together
these proposed branches go ahead and do so, publishing those wherever
they like (git.debian.org, gitorious, their own hosted git repositories,
or even github) and then Carl can just add those as remotes as he sees
fit.

> > What patch tracking workflow should we adopt? Keep sending patches
> > to the mailing list and have a few people who integrate them into
> > master or pu (or even maint/next), as appropriate? Use the Debian
> > bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> > manager on notmuchmail.org? Use patchwork [1]?

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.

micah


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

[notmuch] Git feature branch

[martin f krafft]

also sprach Carl Worth  [2010.01.23.1010 +1300]:
> Anyway, I'll be on vacation for the next few days, so will likely
> not have much, (likely have not much?), time for patch merging.
> 
> But I *am* anxious to get back to the backlog. And in the
> meantime, I really appreciate others merging and sharing patches.

I discussed this with Carl at LCA a bit and ideally we should come
up with a way to relieve Carl of the bottleneck burden (obviously
without stealing away his dictator hat ;)

I think it would make sense to move the mainline to git.debian.org
for now, or another place where everyone can easily get an account.
As alternatives I propose repo.or.cz. I'd prefer to stay away from
commercial services like Github.

Once we're there, how about copying the branch structure from
Git development[0]:

  maint/? the stable release
  master/   ? the stablising head
  next/ ? testing branch
  pu/   ? patch integration branch (proposed updates)

Each of the four branches is usually a direct descendant of the one
above it. Conceptually, the feature enters at an unstable branch
(usually 'next' or 'pu'), and "graduates" to 'master' for the next
release once it is considered stable enough.

0. http://repo.or.cz/w/git.git/blob/HEAD:/Documentation/gitworkflows.txt

Sebastian, would it make sense to migrate your work into a 'pu'
branch?

What patch tracking workflow should we adopt? Keep sending patches
to the mailing list and have a few people who integrate them into
master or pu (or even maint/next), as appropriate? Use the Debian
bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
manager on notmuchmail.org? Use patchwork [1]?

Cheers,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"in all unimportant matters, style, not sincerity, is the essential.
 in all important matters, style, not sincerity, is the essential."
-- oscar wilde

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 

Re: [notmuch] Git feature branch

[sebastian]

> I think it would make sense to move the mainline to git.debian.org
> for now, or another place where everyone can easily get an account.
> As alternatives I propose repo.or.cz. I'd prefer to stay away from
> commercial services like Github.

Any of those sounds fine to me, really. No preferences. I have little
experience with git, so I can't comment on the hierarchy of branches.
Cherry-picking all those patches "up" does sound like it needs some
dedicated attention though...

> Sebastian, would it make sense to migrate your work into a 'pu'
> branch?

Not sure. My feature branch is basically just the branch I use and I have
ecclectically been adding patches that seemed useful to me and ignored
others I was not so sure about. I have no clue if Carl would want those
features/patches in master, but if yes he is free to pull it into an
unstable branch or however we want to name it.

> What patch tracking workflow should we adopt? Keep sending patches
> to the mailing list and have a few people who integrate them into
> master or pu (or even maint/next), as appropriate? Use the Debian
> bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> manager on notmuchmail.org? Use patchwork [1]?

Personally, I like how patchwork complements mailing lists for collecting
patches, so a patchwork-supported mailing list would work well for me. I
have less experience with the Debian bug tracker, not sure if a
'downstream' project can simply use it (but you would know that :-)). I
wouldn't mind to have my roundup used, but it should probably be on some
more officially-looking URL, rather than on a random personal webspace,
shouldn't it?

All  I know is that there is a great momentum behind notmuch at the
moment, and it would be great to not lose that.

Sebastian

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

[notmuch] Git feature branch

[sebast...@sspaeth.de]

> I think it would make sense to move the mainline to git.debian.org
> for now, or another place where everyone can easily get an account.
> As alternatives I propose repo.or.cz. I'd prefer to stay away from
> commercial services like Github.

Any of those sounds fine to me, really. No preferences. I have little
experience with git, so I can't comment on the hierarchy of branches.
Cherry-picking all those patches "up" does sound like it needs some
dedicated attention though...

> Sebastian, would it make sense to migrate your work into a 'pu'
> branch?

Not sure. My feature branch is basically just the branch I use and I have
ecclectically been adding patches that seemed useful to me and ignored
others I was not so sure about. I have no clue if Carl would want those
features/patches in master, but if yes he is free to pull it into an
unstable branch or however we want to name it.

> What patch tracking workflow should we adopt? Keep sending patches
> to the mailing list and have a few people who integrate them into
> master or pu (or even maint/next), as appropriate? Use the Debian
> bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> manager on notmuchmail.org? Use patchwork [1]?

Personally, I like how patchwork complements mailing lists for collecting
patches, so a patchwork-supported mailing list would work well for me. I
have less experience with the Debian bug tracker, not sure if a
'downstream' project can simply use it (but you would know that :-)). I
wouldn't mind to have my roundup used, but it should probably be on some
more officially-looking URL, rather than on a random personal webspace,
shouldn't it?

All  I know is that there is a great momentum behind notmuch at the
moment, and it would be great to not lose that.

Sebastian

Re: [notmuch] Git feature branch

[martin f krafft]

also sprach Carl Worth  [2010.01.23.1010 +1300]:
> Anyway, I'll be on vacation for the next few days, so will likely
> not have much, (likely have not much?), time for patch merging.
> 
> But I *am* anxious to get back to the backlog. And in the
> meantime, I really appreciate others merging and sharing patches.

I discussed this with Carl at LCA a bit and ideally we should come
up with a way to relieve Carl of the bottleneck burden (obviously
without stealing away his dictator hat ;)

I think it would make sense to move the mainline to git.debian.org
for now, or another place where everyone can easily get an account.
As alternatives I propose repo.or.cz. I'd prefer to stay away from
commercial services like Github.

Once we're there, how about copying the branch structure from
Git development[0]:

  maint/— the stable release
  master/   — the stablising head
  next/ — testing branch
  pu/   — patch integration branch (proposed updates)

Each of the four branches is usually a direct descendant of the one
above it. Conceptually, the feature enters at an unstable branch
(usually 'next' or 'pu'), and "graduates" to 'master' for the next
release once it is considered stable enough.

0. http://repo.or.cz/w/git.git/blob/HEAD:/Documentation/gitworkflows.txt

Sebastian, would it make sense to migrate your work into a 'pu'
branch?

What patch tracking workflow should we adopt? Keep sending patches
to the mailing list and have a few people who integrate them into
master or pu (or even maint/next), as appropriate? Use the Debian
bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
manager on notmuchmail.org? Use patchwork [1]?

Cheers,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"in all unimportant matters, style, not sincerity, is the essential.
 in all important matters, style, not sincerity, is the essential."
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Git feature branch

[Carl Worth]

On Fri, 22 Jan 2010 09:50:51 +0100, "Sebastian Spaeth"  wrote:
> My feature-branch is still located here:
> http://github.com/spaetz/notmuch-all-feature
> 
> So far things work fine for me. It would be cool if Carl would merge
> (parts of?) it.

Very much appreciated!

Thanks for putting this together and publishing it.

And I do apologize that my branch has been so stagnant lately. We've
just completed a fabulous linux.conf.au. This included lots of hallway
discussion of Notmuch, a Notmuch BOF, and a Notmuch lightning talk, but
not much of a chance to sit and review/merge the backlog of patches.

Oh, but we did succeed at getting a notmuch Debian package uploaded,
(and there's now a "debian" branch in my repository which I pulled from
the master branch of the shared notmuch repository on alioth).

Anyway, I'll be on vacation for the next few days, so will likely not
have much, (likely have not much?), time for patch merging.

But I *am* anxious to get back to the backlog. And in the meantime, I
really appreciate others merging and sharing patches.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Re: [notmuch] Git feature branch

[Carl Worth]

On Fri, 22 Jan 2010 09:50:51 +0100, "Sebastian Spaeth"  
wrote:
> My feature-branch is still located here:
> http://github.com/spaetz/notmuch-all-feature
> 
> So far things work fine for me. It would be cool if Carl would merge
> (parts of?) it.

Very much appreciated!

Thanks for putting this together and publishing it.

And I do apologize that my branch has been so stagnant lately. We've
just completed a fabulous linux.conf.au. This included lots of hallway
discussion of Notmuch, a Notmuch BOF, and a Notmuch lightning talk, but
not much of a chance to sit and review/merge the backlog of patches.

Oh, but we did succeed at getting a notmuch Debian package uploaded,
(and there's now a "debian" branch in my repository which I pulled from
the master branch of the shared notmuch repository on alioth).

Anyway, I'll be on vacation for the next few days, so will likely not
have much, (likely have not much?), time for patch merging.

But I *am* anxious to get back to the backlog. And in the meantime, I
really appreciate others merging and sharing patches.

-Carl


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

[notmuch] Git feature branch

[Sebastian Spaeth]

On Fri, 22 Jan 2010 09:09:30 +0100, Sebastian Spaeth  
wrote:
> On 01/20/10 21:00, micah anderson wrote:
> 
> > Cool! It would be useful if you provided thread-id's for each of these
> > so we could look them up and read more about them.
> 
> True, I'll try to include thread id-s in the future.

I have now listed all patches that I have added to my feature-branch
here. Where possible I have added mail id or the git source that i have
pulled from. The list is here:

http://trac.sspaeth.de/issue?@columns=title,status&@filter=status&status=6

Stuff that I carry:
- simplify "unread" tag handling in emacs UI
- refactor and improve dirs-to-ignore a bit
- Have notmuch count default to showing the total
- add a submap (on "z" for "ztash") to stash things
- When adding new messages, if they have the 'S' (seen) flag, do not add them 
to the 'unread' tag.
- 'd' should "delete" a mail

My feature-branch is still located here:
http://github.com/spaetz/notmuch-all-feature

So far things work fine for me. It would be cool if Carl would merge
(parts of?) it.

spaetz

[notmuch] Git feature branch

[Sebastian Spaeth]

On 01/20/10 21:00, micah anderson wrote:

> Cool! It would be useful if you provided thread-id's for each of these
> so we could look them up and read more about them.

True, I'll try to include thread id-s in the future.

spaetz

Re: [notmuch] Git feature branch

[Sebastian Spaeth]

On Fri, 22 Jan 2010 09:09:30 +0100, Sebastian Spaeth  
wrote:
> On 01/20/10 21:00, micah anderson wrote:
> 
> > Cool! It would be useful if you provided thread-id's for each of these
> > so we could look them up and read more about them.
> 
> True, I'll try to include thread id-s in the future.

I have now listed all patches that I have added to my feature-branch
here. Where possible I have added mail id or the git source that i have
pulled from. The list is here:

http://trac.sspaeth.de/iss...@columns=title,status&@filter=status&status=6

Stuff that I carry:
- simplify "unread" tag handling in emacs UI
- refactor and improve dirs-to-ignore a bit
- Have notmuch count default to showing the total
- add a submap (on "z" for "ztash") to stash things
- When adding new messages, if they have the 'S' (seen) flag, do not add them 
to the 'unread' tag.
- 'd' should "delete" a mail

My feature-branch is still located here:
http://github.com/spaetz/notmuch-all-feature

So far things work fine for me. It would be cool if Carl would merge
(parts of?) it.

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

Re: [notmuch] Git feature branch

[Sebastian Spaeth]

On 01/20/10 21:00, micah anderson wrote:


Cool! It would be useful if you provided thread-id's for each of these
so we could look them up and read more about them.


True, I'll try to include thread id-s in the future.

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

Re: [notmuch] Git feature branch

[micah anderson]

On Wed, 20 Jan 2010 15:00:46 +0100, "Sebastian Spaeth"  
wrote:
> As I do like some of the additional patches, I am shoving some of them
> into my "all feature" branch. I make that one available in case you
> want to pull from it. It currently carries:
> 
> Jameson Rollins: Simplify "unread" tag handling in emacs UI.
> David Bremner: notmuch.el: Refactor citation markup. Variables for minimum 
> size, button text.
> Dirk-Jan C. Binnema: notmuch-new.c: refactor and improve dirs-to-ignore a bit
> Sebastian Spaeth: add notmuch-show-delete keybinding 'd'

Cool! It would be useful if you provided thread-id's for each of these
so we could look them up and read more about them.

micah



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

[notmuch] Git feature branch

[micah anderson]

On Wed, 20 Jan 2010 15:00:46 +0100, "Sebastian Spaeth"  wrote:
> As I do like some of the additional patches, I am shoving some of them
> into my "all feature" branch. I make that one available in case you
> want to pull from it. It currently carries:
> 
> Jameson Rollins: Simplify "unread" tag handling in emacs UI.
> David Bremner: notmuch.el: Refactor citation markup. Variables for minimum 
> size, button text.
> Dirk-Jan C. Binnema: notmuch-new.c: refactor and improve dirs-to-ignore a bit
> Sebastian Spaeth: add notmuch-show-delete keybinding 'd'

Cool! It would be useful if you provided thread-id's for each of these
so we could look them up and read more about them.

micah

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[notmuch] Git feature branch

[Sebastian Spaeth]

As I do like some of the additional patches, I am shoving some of them
into my "all feature" branch. I make that one available in case you
want to pull from it. It currently carries:

Jameson Rollins: Simplify "unread" tag handling in emacs UI.
David Bremner: notmuch.el: Refactor citation markup. Variables for minimum 
size, button text.
Dirk-Jan C. Binnema: notmuch-new.c: refactor and improve dirs-to-ignore a bit
Sebastian Spaeth: add notmuch-show-delete keybinding 'd'

www: http://github.com/spaetz/notmuch-all-feature
git: git://github.com/spaetz/notmuch-all-feature.git

Sebastian

[notmuch] Git feature branch

[Sebastian Spaeth]

As I do like some of the additional patches, I am shoving some of them
into my "all feature" branch. I make that one available in case you
want to pull from it. It currently carries:

Jameson Rollins: Simplify "unread" tag handling in emacs UI.
David Bremner: notmuch.el: Refactor citation markup. Variables for minimum 
size, button text.
Dirk-Jan C. Binnema: notmuch-new.c: refactor and improve dirs-to-ignore a bit
Sebastian Spaeth: add notmuch-show-delete keybinding 'd'

www: http://github.com/spaetz/notmuch-all-feature
git: git://github.com/spaetz/notmuch-all-feature.git

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