[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Choice of bug tracker
From: |
Dmitry Gutov |
Subject: |
Re: Choice of bug tracker |
Date: |
Fri, 1 Sep 2023 00:24:12 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
On 31/08/2023 05:07, Richard Stallman wrote:
The Gitlab software ls a different issue. I gather that it is all
free software, so there is no bar to our installing it on a server and
running it. If Gitlab.com changes its policy, we could continue running
the previous version of the software, or else patch their release.
When we talk about trying Gitlab, we mean this approach. We already have
an experimental instance running on GNU's servers, after all. The
aforementioned EMBA.
Regarding using an email responder to file submissions in a server:
> The main limitation, however, is that this design requires people to
> create accounts in the system. Even just to file new reports.
If a server requires that, that is a major negative. Aside from being
a nuisance for each person to start to use, it also infringes each
user's privacy.
Worse, if the site requires that, it may also require running nonfree
Javascript to create an account. That would be morally unacceptable:
we can't direct users to run nonfree programs.
If the site does not do that now, will it start some years from now?
Will it start using Cloudflare, which requires nonfree Javascript for
users coming in through the Tor network? If the developers don't
share our values, we have to treat that as a permanent danger.
Again, we're talking about a self-hosted solution. The (apparently
solved) issue of reCaptcha was mentioned upthread (there is now a
setting which switches to a different, simpler method that doesn't use
Google's solution).
I have a possible workaround for all of that. Could we use one single
account GNU-EMAIL to file all email submissions, and record who really
sent each submission (obtained from the From field) in another data
field in the submission?
I don't know about the feasibility of saving the "From" value into
another data field in the same database, but whatever piece of code
would be running the "one single account" could potentially maintain a
database of associations between bug reports and email accounts (reporters).
But that's an open-ended feature, e.g. at some point people will want to
be able to unsubscribe from email follow-ups in those threads, and we
would be required to add that feature too (maybe even by law). We're
talking about a mailing list software, basically.
If the site developers care about us a little, they could add a
feature to use the From-field submitter, for display and search,
instead of the account name, when that latter is GNU-EMAIL.
(With a little more work they could make this feature more elegant and
general, so other projects could do likewise. Each would make its own
account for email submissions. We could release the email responder
program as a GNU package so they couid use it.)
Looking at past reports, Gitlab developers do discuss our issues and fix
some of them, but not all, and not right away. Which seems logical overall.
Speaking of privacy, though, not exposing everybody's unobfuscated email
addresses to the web is considered a privacy advantage in many contexts.
That helps avoid spam, and it helps tracking an individual across the
Web a little more difficult (because for every platform the searches
would at least have to work out the specific way every given site
obfuscates the emails, if they're available at all).
OTOH, having to create an account doesn't seem to create any additional
privacy risks, if we're only asking for email, password, and the account
verification using said email.
- Re: Choice of bug tracker, (continued)
- Re: Choice of bug tracker, Stefan Kangas, 2023/08/29
- Re: Choice of bug tracker, João Távora, 2023/08/29
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/29
- Re: Choice of bug tracker, Stefan Kangas, 2023/08/30
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/30
- Re: Choice of bug tracker, Richard Stallman, 2023/08/30
- Re: Choice of bug tracker, Eli Zaretskii, 2023/08/31
- Re: Choice of bug tracker,
Dmitry Gutov <=
- Re: Choice of bug tracker, Richard Stallman, 2023/08/30
- Re: Choice of bug tracker, Eli Zaretskii, 2023/08/31
- Re: Choice of bug tracker, Richard Stallman, 2023/08/30
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Ihor Radchenko, 2023/08/31
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Eli Zaretskii, 2023/08/31
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Ihor Radchenko, 2023/08/31
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Eli Zaretskii, 2023/08/31
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Ihor Radchenko, 2023/08/31
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Po Lu, 2023/08/27
- Re: New Package for NonGNU-ELPA: clojure-ts-mode, Dmitry Gutov, 2023/08/27