[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Choice of bug tracker

From: Visuwesh
Subject: Re: Choice of bug tracker
Date: Fri, 01 Sep 2023 12:45:21 +0530
User-agent: Gnus/5.13 (Gnus v5.13)

[வெள்ளி செப்டம்பர் 01, 2023] Dmitry Gutov wrote:

> [...]
> The "minimum blood" would be mumi because from what it seems like it
> retains all the email interactions and adds some moderately better
> looks when viewed on the web on top of that. As well as faster search.
> But since it has the least "familiarity" factor among all of the
> discussed solutions (and features, of course, and usability testing,
> and etc...), the ability to attract more and more diverse users and
> developers though modern tooling would correspondingly be lower.
> There is a sweet spot somewhere, but I don't have any scientific
> argument for its position. Though if I try to imagine myself 10-15
> years younger (rather difficult), the grading would most likely be
> Github > Gitlab >> Bugzilla > mumi >> Debbugs. Add a pound of salt, of
> course.

You don't have to imagine yourself younger because I was eighteen or
nineteen when I first posted a bug report to debbugs.  ;-) Not sure if
this is your target audience though.
I did not have problems with sending the mail to the right address but
knowing whether my mail reached the mailing list/debbugs was an issue
since I could not see it pop up in the bug-gnu-emacs mailing list
archive.  Much later I learnt that there is a manual approval process
for fresh email addresses and that's why my acknowledgement mail was
sent some 10 hours later (I went to sleep after submitting said bug
report).  If there was a message along the lines of, “Your message has
been received and will be forwarded to the Emacs developers once your
email address has been manually approved to check whether your mail is
spam or not” I think the first experience would have been smoother.

As for submitting patches, I much much much much prefer the Emacs way™.
It is so much better than forking the repo, creating a new branch,
fighting with Git to merge/rebase and push properly without --force (I
still don't know how to do the latter FWIW). And don't get me started on
amendments after creating the PR...  For Emacs, I can develop the patch
however I want and simply attach it to a mail---I cannot emphasise how
much simpler and effortless this feels.  It is a good thing that Emacs
actually prefers patches as assignment over `git send-email'---nothing
is more of a pain than setting up an email client especially in a
CLI/TUI setting.  When you have only used the GMail/Yahoo web client for
email, all the terminologies that the man page and the tutorials throw
at you simply flies over your head and you give up.  Now, the most
common mail provider Gmail has made it a huge PITA to use a custom email
client as well...

So let me reiterate: I find it so comforting that Emacs accepts patches
(1) via email, and (2) as attachments.

> There should also be SourceHut on this scale, but I don't know where
> to put it.

Cannot comment on how everyone else uses Sourcehut but my experience was
slightly better than Debbugs because I got instant feedback from the
mailing list archive and Philip accepts patches as attachments.  ;-)
Generally, I don't find their web UI all that useful since they drop the
entire message after the attachment.  I am not sure if there are plans
to fix it since Sourcehut people prefer `git send-email' AFAIK.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]