From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: Concern about new binding. Date: Sun, 07 Feb 2021 21:41:10 -0800 Message-ID: References: <20210202134950.vybbpf3iewbymfjo.ref@Ergus> <20210202134950.vybbpf3iewbymfjo@Ergus> <87zh0mmr54.fsf@gmail.com> <87tuqunw6q.fsf@telefonica.net> <835z3a5miu.fsf@gnu.org> <87pn1f2dlf.fsf@melete.silentflame.com> <87h7mn2122.fsf@melete.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36775"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) Cc: ofv@wanadoo.es, eliz@gnu.org, emacs-devel@gnu.org, Sean Whitton To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 08 06:43:06 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l8zKE-0009Sg-Eg for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Feb 2021 06:43:06 +0100 Original-Received: from localhost ([::1]:60378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8zKD-0005zz-Cb for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Feb 2021 00:43:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8zIU-0005Oo-Mm for emacs-devel@gnu.org; Mon, 08 Feb 2021 00:41:19 -0500 Original-Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]:37339) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l8zIS-0003uX-0L; Mon, 08 Feb 2021 00:41:17 -0500 Original-Received: by mail-pl1-x633.google.com with SMTP id e12so7219177pls.4; Sun, 07 Feb 2021 21:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=1oiM4W3yG5XwY20Fr8/Eco1SChEwF/+5/lK54SmbLUo=; b=ZXwTdnu+LPDEGPvzuapALWOjgG43zy0bM3ovcb1iZzyAwntA1ZKKiH0QeHBwVRIEPx iQi+DLM7bq+a5wPzK4qYaeShJANAzpjXTsVrPi9xe3rX3k2IpNfRxlSk9e8BKZ+bc1mc mb6aUYh1S2SIBuhfE/OIsqeuvHGOm8mv/7JlQE3NyEUOtfyIc5xctawPEqg1pZUdaWdj EiCXXYLmluc9KNxi56Opk2+Ru1ptU1Gn0kYUQ7NyaU05f8kLVnmz6pUvkjImu2nDGIuP 48Xrl0weyHVjVDb+Rs/OATVi3J1fI5PvXq7nCwg86d6aHXYSNc95HritcYfdT4B1F+yU P/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=1oiM4W3yG5XwY20Fr8/Eco1SChEwF/+5/lK54SmbLUo=; b=cBYT6uqgHvjP4Juz5VMKANdN+qr7FlxR8CCZR06TFlya9vgiCampj8IGTmmerKqTi8 DFwI9KWJJb9Jh0cZpbJRPU3UNmaKRQY7s6GFrFbzpGp+oYe1vcVFY7N7gNiI0Cf1wc4C f/xpP5Kn/MDQLwcq2VjXrixdkgETcxbME658wHyl1o83tcq+u9fuq2DhI8dUz6q00MQI 64mWNFzUJEryb9XhIov5lDIWBVd8oAcsJvb3e0oMP7ktsTinVInKXmoRsl9YIbVRmUXI GMkh5dYTD5mL65aU5HWUXukUHQ4sDAjY/J4XObSmLYFO2e7YPxkdlRgGMmtBDfvvfOji fb6w== X-Gm-Message-State: AOAM532oFJCkJhV/v/S4XfHqyQQeIqI/SEgiymRPMhdzVPlzYSWZDIfQ JkYMbJt01CEbFmh8SkV1Ri95SGpKGaFRoA== X-Google-Smtp-Source: ABdhPJxKmixHZVcRLPnL9dDC4te6+Xa1uQz2RGkP7Wmj6N60wdgnx2ESlY3TuE5nw0M/VGBYFc2l4w== X-Received: by 2002:a17:90a:6a07:: with SMTP id t7mr15227348pjj.194.1612762872720; Sun, 07 Feb 2021 21:41:12 -0800 (PST) Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com. [24.113.169.116]) by smtp.gmail.com with ESMTPSA id r12sm3013941pfr.86.2021.02.07.21.41.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Feb 2021 21:41:12 -0800 (PST) In-Reply-To: (Richard Stallman's message of "Sun, 07 Feb 2021 22:43:48 -0500") Received-SPF: pass client-ip=2607:f8b0:4864:20::633; envelope-from=gmatta@gmail.com; helo=mail-pl1-x633.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:264155 Archived-At: Richard Stallman 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.