[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Koko in KDEReview
From:       Halla Rempt <boud () valdyas ! org>
Date:       2021-05-04 14:54:15
Message-ID: 2447323.ElGaqSPkdT () selday
[Download RAW message or body]

On Tuesday, 4 May 2021 16:26:22 CEST Nate Graham wrote:

> Again, my point was not that everything about GLI is universally better 
> than everything about BZ. Just that most things are mostly better in 
> most ways that most of us care about. 

List them? I cannot think of a single thing that's good...

> I'll acknowledge that some things 
> are worse. But GLI is at least developed upstream so there is the 
> possibility of improvement. With BZ, not so much.
> 
> ---
> 
> FWIW I think it might make more sense to put information like the OS in 
> the issue text itself--encouraged via a bug reporting template--than it 
> is to use tags for that. In GLI, you can edit comments and even the 
> original text, so anything that's missing can be added later, unlike in 
> BZ. This mutability in GLI reduces the need for dedicated mutable text 
> fields and comboboxes for this that and the other thing, the way BZ has. 
> It's all kind of a workaround for the fact that you can't edit the 
> original text of the bug report in BZ.

Gawd, that would be _horrible_. I especially would hate "mutable" text. Great recipe \
for losing information. And having stuff like OS in the text makes, of course, any \
kind of search hell. And you'd never get consistency, even with templates.


> 
> However those are implementation details we can probably hash out later.
> 

I REALLY hope this later will NEVER come. I would probably set up my own bugzilla \
instance somewhere else, sooner than use gitlabs ridiculous excuse for an issue \
tracker.


-- 
https://www.krita.org


[prev in list] [next in list] [prev in thread] [next in thread]