Bugreporting barrier is too low with the new Dr. Konqi

Ingo Klöcker kloecker at kde.org
Fri Nov 13 22:03:36 GMT 2009


On Friday 13 November 2009, Darío Andrés wrote:
> Re-sending because the mail subject got changed and it missed the
> original thread

I really don't want to disillusion you, but this is problem only exists 
in GMail (and similarly incapable email clients). KMail (and other 
standard compliant email clients) do not have this problem. In KMail 
your reply was properly threaded below the message you replied to.


Regards,
Ingo (proud former maintainer of KMail who does not understand what 
people like about this email client from Google which doesn't even 
support the most basic mail related mechanisms like proper standard 
compliant threading ;-) )


>
> 2009/11/12 Darío Andrés <andresbajotierra at gmail.com>:
> > 2009/11/11 Darío Andrés <andresbajotierra at gmail.com>:
> >> On Tue, Nov 10, 2009 at 6:23 AM, FiNeX <finex at finex.org> wrote:
> >>> In data martedì 10 novembre 2009 02:53:04, Darío Andrés ha 
scritto:
> >>>> Another idea I got in order to reduce the noise to developers:
> >>>> [...]
> >>>
> >>> I like the idea: usually when I have some time for triaging bugs
> >>> I pick up the latest N bug reported and I read them all. Usually
> >>> bugs reported from drkonqui are dups or "NEEDSINFO". Anyway they
> >>> are mostly filled under the right product. Why not set a flag
> >>> "automatically submitted" so developers can filter them out and
> >>> triagers can filter them in?
> >>>
> >>> Something like "waiting for human check" ?
> >>
> >> May be I start liking this idea. Creating the bug report under the
> >> corresponding product but with a special status
> >> NEEDSINFO/WAITINGFORAPPROVAL or a special keyword would allow:
> >> - Developers will get notified about them, but they should be able
> >> to ignore them if they like to. (just exclude such reports from
> >> your query searches, and ignore your mails if they have "Reported
> >> using DrKonqi")
> >> - Reports will be under the right product from the start (I will
> >> look forward implementing the online mapping feature)
> >> - Open bug reports count will not increase until the triagers
> >> confirm that they are valid issues (pre-filter system)
> >> - Having a keyword or a special state makes searching for the
> >> untriaged bugs a lot easier too.
> >>
> >> + Improving duplicate handling in DrKonqi itself
> >>
> >> All the discussions about changing bugtracking system are a bit
> >> beyond me so I won't suggest anything yet...
> >> BTW, thanks to all for the feedback about the current system, it
> >> is greatly appreciated and I will look forward improving the
> >> situation.
> >>
> >> @FiNeX: this discussion comes from kde-core-devel, so be sure to
> >> send your replies to that list too so everyone can see them.
> >
> > Mh, it seems that bugzilla won't accept entering bugs with a closed
> > state. We could implement a patch or use a keyword instead
> > (something like "automatic_unverified_report"). What do you think ?
> > Devs can ignore reports with that keyword in their queries, too bad
> > we can't fix the statistics :-\ (or may be we can fix them,
> > patching them)
> >
> > I have been also wondering if we could implement a remote agnostic
> > interface, so DrKonqi will be able to communicate with bugs.kde.org
> > system regardless of the bugtracking system (useful if we ever
> > migrate to another system, and to write a better implementation to
> > retrieve the bugs' data  (parsing HTTP after POST/GET HTTP requests
> > is ~nasty~ (current way)).
> > With a custom (and own) interface we could provide a stable remote
> > API for DrKonqi even for stable (not trunk) KDE versions (bugzilla
> > xmlrpc is unstable API, we can't rely on it, bugzilla upgrades will
> > break it).
> >
> >> Cheers
> >> Darío A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091113/0f42210c/attachment.sig>


More information about the kde-core-devel mailing list