Koko in KDEReview

[Albert Astals Cid]

El dimarts, 4 de maig de 2021, a les 0:36:57 (CEST), Carl Schwan va escriure:
> Le mardi, mai 4, 2021 12:21 AM, Albert Astals Cid <aacid at kde.org> a écrit :
> 
> > El dimarts, 4 de maig de 2021, a les 0:07:19 (CEST), Carl Schwan va escriure:
> >
> > > Le lundi, mai 3, 2021 4:35 PM, Harald Sitter sitter at kde.org a écrit :
> > >
> > > > On 23.04.21 01:00, Carl Schwan wrote:
> > > >
> > > > > > > > > -   please get a bugzilla produce created for it
> > > > > > >
> > > > > > > Not a fan of that. This will ends up exactly like the www bugs, something
> > > > > > > that I look into every 6 months. We already have many issues opened in
> > > > > > > invent and it's working fine for us.
> > > > > >
> > > > > > Did I miss something? The last agreement I recall was that we are using
> > > > > > bugzilla for bugs and gitlab for tasks for the time being. If even as
> > > > > > developer I have to go hunting where $project tracks their bugs I'm sure
> > > > > > not going to be a happy camper.
> > > > > >
> > > > > > > Also we don't use KCrash.
> > > > > >
> > > > > > Shouldn't you?
> > > > >
> > > > > The problem is that DrKonqi doesn't really work on Plasma Mobile and I don't think
> > > > > this justify getting locked up in using Bugzilla. If having a bugzilla product
> > > > > is really required, we can request one but I can't guarantee that I will look at it
> > > > > more often than I look at the kde-www bug reports in bugzilla (every 6 months).
> > > >
> > > > Let's consider it required then.
> > > > If you don't care about crash reports that's your choice I guess, but it
> > > > does kinda call into question the product quality since you also don't
> > > > have an alternative system to the kcrash-drkonqi-bugzilla caravan. Quite
> > > > clearly koko would have benefited from crash tracking and since the only
> > > > solution we presently have for that is the aforementioned stack it quite
> > > > clearly also would have benefited from being on bugzilla to receive
> > > > those crash reports and potentially move to other products if the crash
> > > > is not in koko. After all, crashes get submitted to the product that
> > > > crashed, not the library of the top most frame.
> > > > I have to be honest, it is a bit surreal to even have to argue this. I
> > > > get thorough enjoyment out of throwing tomatoes at the current system
> > > > but to actively pretend that the problem-domain of crashing software
> > > > doesn't exist so you don't have to look at bugzilla sure as heck doesn't
> > > > solve anything. In particular since you pitched koko as convergent and
> > > > useful on the desktop.
> > > > If all that's stopping you from embracing crash tracking is drkonqi then
> > > > I am happy to tell you that sticking a mobile-suitable UI on top
> > > > shouldn't be all that difficult ;)
> > >
> > > Would you be open to an MR adding GitLab support to DrKonqi?
> >
> > We don't use gitlab for user bug reports.
> 
> Do you have a link to the policy? I looked into https://community.kde.org/Policies
> and I found nothing. https://manifesto.kde.org/commitments.html says that we
> should only use online service hosted by KDE, but as far I know invent is hosted by
> KDE.

"The project stays true to established practices"

The established practice in KDE is clearly using bugzilla for bugs. 

Cheers,
  Albert

> 
> Also considering that bugzilla is almost unmaintained, that should be something
> to reconsider if there is really such policy. For info, the Bugzilla UX initiative
> died when the lead developer was fired by Mozilla. And the Harmony project which is
> trying to bring back the improvements from BMO (the Mozilla internal fork) is
> progressing at an abysmal pace. Bugzilla itself had its last code contribution one year
> ago.
> 
> Cheers,
> Carl
> 
> >
> > Cheers,
> > Albert
> >
> > > > HS
> 
> 
>