[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: debbugs [was Re: Gitlab Migration]
From: |
Stefan Monnier |
Subject: |
Re: debbugs [was Re: Gitlab Migration] |
Date: |
Mon, 30 Aug 2021 12:09:47 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> Obviously no-one's working on d.g.o (for some time), but for the record:
My comments weren't really "requests for improvement" w.r.t
d.g.o, indeed.
>> - Can't search the database when I'm offline.
>> I really wish the database was stored in Git, so I could easily have
>> a clone of it.
> I can't see how this could have worked in practice, given the size of
> the database.
When experimenting with BuGit I created a Git database holding all of
debbugs.gnu.org and that worked fine. It was a few GBs large,
admittedly, so the concept would require more work to make it
possible/easy to download only a part of the database (the
representation I used does/did make it fairly easy since each issue gets
its own Git branch, the problem is more about the design of a UI and/or
heuristics to decide which issue to download and or to flush).
>> - The notion of "archived" bugs is a pain in the rear when you send a
>> new message and the message just bounces back with "the bug is
>> archived". Either get rid of it, or automatically unarchive bugs when
> I think archiving is important for performance reasons.
I definitely agree that the implementation would want to have a notion
of "active" vs "inactive" issues for performance reasons (e.g. the above
multi-GB Git clone would have shrunk a fair bit if it only included the
non-archived bugs).
> I imagine automatic unarchiving would have been easy to do, and I agree
> it would be useful. Back in the day, I wasn't so sure, eg I thought that
> mostly what would happen is that it would mean people could respond to
> very old bugs by mistake without noticing.
An automatic message in return to the author pointing out that this is
an old bug would do the job for that. No need to divert the message to
/dev/null. After all, all the other recipients will have received the
message anyway.
>> - I find it a big difficult to classify bugs. I'm not sure exactly what
>> I'd like, and maybe some of it can be done via tags and other things
>> already, but I think I'd like it if bugs could be "assigned" to persons
>> and/or to files and/or to "subsystems"
> There are the "owner" and "usertag" commands.
Indeed, the basic functionality is there, but I somehow never got to
using it. In web UIs these categorization tools tend to be shown in
such a way that I'm encouraged to use them, whereas in debbugs's email
interface I really have to go out of my way to use them.
Not sure how to do better within the scope of an email interface.
Stefan
- Re: Gitlab Migration, (continued)
- Re: Gitlab Migration, Stefan Monnier, 2021/08/27
- Re: Gitlab Migration, Eli Zaretskii, 2021/08/28
- Re: Gitlab Migration, Alan Third, 2021/08/28
- Re: Gitlab Migration, Eli Zaretskii, 2021/08/28
- Re: Gitlab Migration, Basil L. Contovounesios, 2021/08/28
- Re: Gitlab Migration, Alan Third, 2021/08/28
- debbugs [was Re: Gitlab Migration], Glenn Morris, 2021/08/30
- Re: debbugs [was Re: Gitlab Migration],
Stefan Monnier <=
Re: Gitlab Migration, Richard Stallman, 2021/08/27