Re: Concern about new binding.

[Matt Armstrong <matt@rfc20.org>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > notmuch has a system for committing tags on messages under a namespace
>   > to a git repository.  So any contributor could tag a message as
>   > "emacs:interface_change" and then your local notmuch would be configured
>   > to include messages tagged with that in the same view as emacs-devel
>   > messages.
>
> For such a repo to operate, it would have to be used by a community.
> If enough people use it, it could do its job.
>
> How would I fetch new messages from that repo so as to actually read
> them?
>
> (I am not sure what notmuch is.)

I think to understand this sufficiently well, one must understand
notmuch's basic design.

(notmuch is under the GPL and I believe it is run as a GNU project --
when I submitted patches they asked me for FSF papers -- but don't hold
me to that)

At its core notmuch is a search engine over an email store. The email
store must be one file per message, stored on the local disk. Notmuch
"crawls" that and maintains a database that supports fast retrieval much
like a search engine does. On top of this there are email clients --
initially just for Emacs, others followed. The searches can query over
the message body, the usual header fields, and a set of user specified
tags. This architecture is fast enough that no server needs to run -- it
operates as a command line utility, where each search is a separate
invocation. I am omitting many subleties the sake of brevity.

Notmuch is popular among people who prefer processing their email with
tags/labels, instead of folders. In notmuch, a message's tags are
primary, and its location on disk is secondary (but it, too, can be a
search criteria if desired).

Because notmuch supports custom tags on messages, it can also be used to
keep track of arbitrary states associated with messages, such as read,
unread, flagged, etc. In addition to this, the user can use (mostly)
arbitrary strings as tags. With this flexibility it is not a stretch to
imagine a user treating their notmuch mail store as a bug database.

From there, you could also imagine https://debbugs.gnu.org/ re-written
to use notmuch to store its state. This leads me to
https://notmuchmail.org/nmbug/ -- which is effectively just that. The
notmuch project uses itself to manage its own bug database. Developers
interact with the database using notmuch, change state by modifying tags
on messages, and synchronize those tags using a synchronization approach
built on top of git.

For this to work well, individuals need:

 a) a full local copy of the email history for the bug system.
 b) a current copy of the tags (the bug db metadata)

The primary difference between this notmuch base bug database and Emacs'
current debbugs is distributed git vs a central server.

Which brings me to: if the point is to make certain kinds of bugs more
discoverable, adding that feture to debbugs is another option. For
example, if the bugs tagged "interface change" were interesting, debbugs
could send updates for such bugs to an "interface change" mailing list
that interested people could subscribe to.

Personally, I think these ideas are okay to contemplate, but I suspect
these approaches are more work than the benefits they bring. In all
projects I've ever worked on there has never been a clear algorithm for
separating what should and should not be discussed in a broader
audience, and the core maintainers are constantly having to balancing
the need to just make a decision vs. the desire to cultivate an
inclusive decision making process.