Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)
Giovanni Biscuolo writes: > AFAIU mumi does not (still?) have ad authentication/authorization, > right? > > If so how do you plan to deal with users posting SPAM or similar > unappropriate content? It only sends email on behalf of commenters, so we’re using the same email mechanism to deal with spam. -- Ricardo
Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)
Hello Ricardo, Ricardo Wurmus writes: > Giovanni Biscuolo writes: > >> […] actually Debbugs or Mumi web interfaces are read-only: you cannot >> open a bug report or comment it, you have to send an email; this is a >> _feature_, not a bug since we don't need a _complex_ web based >> authentication+authorization system for bug reporters/commenters. […] > > Mumi actually does support commenting on the web: > > > https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/web/controller.scm#n145 > > It’s just been disabled because messages ended up being stuck in the > queue and nobody could make enough time to debug this. Uh, I didn't know mumi have that feature AFAIU mumi does not (still?) have ad authentication/authorization, right? If so how do you plan to deal with users posting SPAM or similar unappropriate content? Thanks! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)
Giovanni Biscuolo writes: > […] actually Debbugs or Mumi web > interfaces are read-only: you cannot open a bug report or comment it, > you have to send an email; this is a _feature_, not a bug since we don't > need a _complex_ web based authentication+authorization system for bug > reporters/commenters. […] Mumi actually does support commenting on the web: https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/web/controller.scm#n145 It’s just been disabled because messages ended up being stuck in the queue and nobody could make enough time to debug this. -- Ricardo
Debbugs CLI client (was Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)))
Hi,
On Mon, 04 Sep 2023 at 23:06, Arun Isaac wrote:
> But, meanwhile, I wish to remind everyone that we already have a mumi
> CLI client that takes away some of the pain of dealing with Debbugs. It
> operates fully on the command-line and does not require Emacs at
> all. This CLI client has so far been undocumented. So, I thought it
> helpful to document it and put it into the manual. I have sent a patch
> to https://issues.guix.gnu.org/65746
Please also note that Debbugs has a CLI client. It’s Perl scripts
targeting the Debbugs instance of the Debian project therefore they need
some tweaks as replacement of URLs, IIRC.
https://salsa.debian.org/debian/devscripts
For instance, the help message reads:
--8<---cut here---start->8---
$ bts -h
Usage: bts [options] command [args] [#comment] [.|, command ... ]
Valid options are:
-o, --offline Do not attempt to connect to BTS for show/bug
commands: use cached copy
--online, --no-offline Attempt to connect (default)
-n, --no-actionDo not send emails but print them to standard output.
--no-cache Do not attempt to cache new versions of BTS
pages when performing show/bug commands
--cacheDo attempt to cache new versions of BTS
pages when performing show/bug commands (default)
--cache-mode={min|mbox|full}
How much to cache when we are caching: the sensible
bare minimum (default), the mbox as well, or
everything?
--cache-delay=seconds Time to sleep between each download when caching.
-m, --mbox With show or bugs, open a mailreader to read the mbox
version instead
--mailreader=CMD Run CMD to read an mbox; default is 'mutt -f %s'
(must contain %s, which is replaced by mbox name)
--cc-addr=CC_EMAIL_ADDRESS
Send carbon copies to a list of users.
CC_EMAIL_ADDRESS should be a comma-separated list of
e-mail addresses.
--use-default-cc Send carbon copies to any addresses specified in the
configuration file BTS_DEFAULT_CC (default)
--no-use-default-ccDo not do so
--sendmail=cmd Sendmail command to use (default /usr/sbin/sendmail)
--mutt Use mutt for sending of mails.
--no-mutt Do not do so (default)
--smtp-host=host SMTP host to use
--smtp-username=user } Credentials to use when connecting to an SMTP
--smtp-password=pass } server which requires authentication
--smtp-helo=helo HELO to use when connecting to the SMTP server;
(defaults to the content of /etc/mailname)
--bts-server The name of the debbugs server to use
(default https://bugs.debian.org)
-f, --force-refreshReload all bug reports being cached, even unchanged
ones
--no-force-refresh Do not do so (default)
--only-new Download only new bugs when caching. Do not check
for updates in bugs we already have.
--include-resolved Cache bugs marked as resolved (default)
--no-include-resolved Do not cache bugs marked as resolved
--no-ack Suppress BTS acknowledgment mails
--ack Do not do so (default)
-i, --interactive Prompt for confirmation before sending e-mail
--force-interactiveSame as --interactive, with the exception that an
editor is spawned before confirmation is requested
--no-interactive Do not do so (default)
-q, --quietOnly display information about newly cached pages.
If given twice, only display error messages.
--no-conf, --noconfDo not read devscripts config files;
must be the first option given
-h, --help Display this message
-v, --version Display version and copyright info
Default settings modified by devscripts configuration files:
(none)
Valid commands are:
show [] [ | | | : ]
[= ...]
show [] [src: | from:] [= ...]
show [] [tag: | usertag: ] [= ...]
show [release-critical | release-critical/... | RC]
bugs [] [ | | | : ]
[= ...]
bugs [] [src: | from:] [= ...]
bugs [] [tag: | usertag: ] [= ...]
bugs [release-critical | release-critical/... | RC]
select [: ...]
status [ | file: | fields:[, ...] | verbose] ...
clone [ ...]
done []
reopen []
archive
unarchive
retitle
summary []
submitter [ ...]
reassign [ ...] []
found []
notfound
fixed
notfixed
block by|with [ ...]
unblock by|with [ ...]
merge [ ...]
Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)
Hi all Arun Isaac writes: [...] > I have been following the conversation with much interest. There seems > to be a developing consensus that we should switch to sourcehut. I fear that the switch would _not_ solve many of the problems tagged as "cognitive overhead"; the problem is "the workflow", not the tool. «All forges suck, _no one_ sucks less» :-D (it's a joke!) Please forgive me if I insist and/or repeat myself (and others) but: 1. sourcehut is a suite of (alpha) applications: what set of applications we should switch to? 2. given that all *.sr.ht applications are alpha [1], would the Guix packages for applications listed in 1. be maintainable in the _near_ future? Also we need to package them as Guix _services_ to be useful. 3. given current resources, where do we plan to host the new services? Are current Guix sysadmins human resources enough to give _support_ to the new services? Please consider that «Currently, the only officially supported method for installing sr.ht software is through packages on Alpine Linux hosts. [...] the installation and deployment process can become a bit more involving. In particular, many sr.ht services have their own, unique requirements that necessitate extra installation steps», unless we package them for Guix (point 2.) 4. git.sr.ht (the "forge"?) implements an email based patch workflow management and _not_ a web based pull-request workflow, it's documented here: https://man.sr.ht/git.sr.ht/#sending-patches-upstream; so git.sr.ht will _not_ help Guix adding a web based PR workflow, for that we need _other_ forges, for example GitLab, Gitea/Forgejo (other?) 5. what about "git request-pull" [2] to enable a PR workflow for Guix? It seems completely ignored by all the "forges" or am I wrong? Unfortunately AFAIU it runs only as CLI, there is no web or GUI interface for that 6. in what aspect todo.sr.ht (the issue tracker) is better than Debbugs (via multiple interfaces)? AFAIU nothing in that application is so much better than what Guix actually use; actually Debbugs or Mumi web interfaces are read-only: you cannot open a bug report or comment it, you have to send an email; this is a _feature_, not a bug since we don't need a _complex_ web based authentication+authorization system for bug reporters/commenters. Please also consider that the emacs Debbugs interface is very useful, I'd miss a similar interface for todo.sr.ht (but there is a CLI for sourcehut web services) 7. last, but not least: a public-inbox instance (https://yhetil.org/) helps a lot people who is not subscribed to a mailing list with email replies (e.g https://yhetil.org/guix-bugs/87il8qrm53@gmail.com/#R) **and** patch downloading; IMHO it should be officially provided by Guix > I am all in favour of any decision the community comes to on this. I just hope the decision comes after an analysis of each single problem, otherwise there is a chance that different tools will not solve the problems [...] > So, I thought it helpful to document it and put it into the manual. I > have sent a patch to https://issues.guix.gnu.org/65746 Very good work, thanks Arun! Happy hacking, Gio' [1] https://man.sr.ht/packages.md [2] https://www.git-scm.com/docs/git-request-pull -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)
Hi all, I'm glad we're having this difficult but necessary conversation. I have been following the conversation with much interest. There seems to be a developing consensus that we should switch to sourcehut. I am all in favour of any decision the community comes to on this. But, meanwhile, I wish to remind everyone that we already have a mumi CLI client that takes away some of the pain of dealing with Debbugs. It operates fully on the command-line and does not require Emacs at all. This CLI client has so far been undocumented. So, I thought it helpful to document it and put it into the manual. I have sent a patch to https://issues.guix.gnu.org/65746 Regards, Arun
