Re: bug reporting instructions

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Tue, 05 Aug 2025 08:34:59 +0200
Newsgroups	gmane.comp.gnu.inetutils.bugs
Message-ID	<[email protected]>
Bruno Haible via Bug reports for the GNU Internet utilities
<[email protected]> writes:

> Simon Josefsson wrote:
>> The savannah issue tracker?  I'm using it, but I find the
>> availability issues with savannah together with the really dated UX and
>> technical design (is it possible to export savannah issues in any
>> standardized format?) is making me consider alternatives.
>> 
>> I would prefer to leave the centralized software hosting world.
>> Forgejo/codeberg definitely isn't their yet.  But I see using it as one
>> likely way forward to get to a decentralized approach.
>
> A decentralized approach means stagnation. Simply because making a change
> to a decentralized software is 10 times more complex than making it to a
> centralized service. I mean, if Forgejo version Y introduces a feature that
> Forgejo version X does not have, how do the two communicate? The developers
> not only have to keep around old compatibility code forever; they also have
> to design fallback rules and such. Whereas in a centralized service the
> developers just upgrade their code and possibly execute a database schema
> change command, and are done with the change.
>
> If you want examples, look at
>   - why email is functionally still at the same level as 1990,
>   - what it takes for the Bitcoin community to implement a protocol change,
>   - how quickly e.g. Slack and Signal as centralized services could evolve
>     their features.
>
> So, any decentralized tracker that you start using today will have a
> "really dated UX" 10 years from now. Simply because they can't innovate
> easily.

I'm not fully convinced -- the email analogy is a good one, because
there the interchange format is fairly stable but UX development can
happen independent of the interchange format.  The UX of e-mail clients
has evolved a lot since the 1990's but the underlying interchange format
is still similar.

What has been missing for issue tracking is a stable and standardized
interchange format.  This means the UX and issue tracking format gets
intermingled, and that's what causing the stagnation.

Having centralized systems leads to stagnation in another way.  Before
Slack and Signal there has been tons of earlier centralized chat
systems, and most of them had a phase of rapid development and then just
faded away.  ICQ anyone?

So this means that, yes, the issue tracking interchange format needs to
be stable and "stagnate" in the same way e-mail is.  But it doesn't mean
the UX's has to be locked to the format in the same way we have today
with savannah/gitlab/etc.

This is mostly academic and fairly subjective though, I think we are far
away from seeing any real progress in this area, and we will be stuck
with centralized issue tracking for many years (or forever).

/Simon
signature.asc (application/pgp-signature, 1.2 KB)