[kdepim-users] open request to KDEPIM devs to address four long-standing regressions

[Kevin Krammer]

Hi Pat,

On Monday, 2011-10-17, pkbugs+kdepim at ssl-mail.com wrote:
> Hi Kevin,
> 
> On Sunday, October 16, 2011 9:47 PM, "Kevin Krammer"
> 
> <kevin.krammer at gmx.at> wrote:
> > Lets see if we can find out when these were introduced.
> > It will be easier for the developers if we can specify how a respective
> > feature worked in previous KMail versions.
> 
> I supsect that information is all in the bugs already, and that the devs
> who changed/disabled the features are well aware of them.

Unfortunately not.
It has become fashionable to "game the system" so to speak, e.g. sometimes by 
tricking other users to vote on bugs actually unrelated to that other users' 
problems or even labelling wish item lists as bugs.

Everytime one of the developers encounters one of these the overall likeliness 
of bugs getting fixes drops.
Basically developers retreat to only look at bugs that happen to themselves or 
which have been reported by another developer or sufficiently screened/pruned by 
one of the few trusted bug triagers.

Hence the importance of locating the related feature in a prior version when 
addressing regressions, because any kind of misuse of that tag unintentionally 
or intentionally will devalue the meaning of regression down to nothing.

> Getting THOSE
> devs *connected* with THOSE bugs is the challenge.

Right, and making sure they don't encounter any of the "changing the rules" 
reports.

> >> (1) An option to turn off QR codes display in KDE Kontact
> > 
> > I am using KMail 1.13.7 here ...
> 
> It's not in KMail, it's in Kontact/KDEPIM as shipped with KDE 4.7.1/2.

Kontact is a container for several components which can each be run in stand-
alone mode as well. E.g. KMail is Kontact's mail component.

Since all other items referred to KMail features I guessed that this one did 
as well.
Seems I guessed wrongly and you are referring to another component.

> There's no toggle.  They're just ON whether you like it or not.

Right, but I think you misunderstood my question. We want to avoid that the 
respective developer never looks at the report again so we need to extra 
careful to be sure when we address something as a regression.

So we need to determine which version still had the option to toggle QR code 
display OFF. The report might already contain that of course.
If we tag something as a regression without that information we risk in the 
best case that the respective developer just ignores the report, in the worst 
case all reports filed or even supported by the person doing the tagging.

> >> (2) An option to display "Favorite Folders" as a list, rather than as
> >> icons
> > 
> > could you point me to where I can toggle that?
> 
> Afaik, it's not IN KMail1.  And there's no toggle in KMail2.  It's just
> ON whether you like it or not.

Hmm. As I said I couldn't find it in KMail1 myself either, so this is a very 
good candidate of potentially not being a regression and invalidating any 
numbers of bugs from a developer's point of view (considering this an attempt 
to trick them into looking into a feature request by declaring it a high 
priority variant of a bug).

> > I thought that KMail 1.x only had list, can you point me to the option
> > where this can be toggled to icons?
> 
> Again, this is KMail2.  No toggle or option available. It simply changed
> from KMail1.

Right, but as I tried to point out above we better find that option in KMail1 
so the removal of the option can be labelled as a regression.
Otherwise is it not only likely that it will be ignored but it is also quite 
likely that any other report from persons involved in the relabelling will be 
considered equally misguided and discarded without any further investigation.

> No issue with alternative features being ADDED, as long as they're
> treated as alternatives, not as someone's idea of a mandate, and don't
> take away functionality that users prefer &/or depend on.
> 
> > Is there a setting for freely sortable folders or do I need to press&hold
> > specific modifier key?
> 
> Again, in KMail2.

I think I found the respective option in KMail1 now. The toggle seems to be 
accessible through the context menu on the folder list's header.

So this looks to be safe for tagging as a regression.

> > > (4) Fix search on IMAP folders
> > 
> > I can confirm that this works with KMail 1.13.7
> 
> Right, hence the regression.

Right, hence the need to keep the meaning of regression clean of any 
ambiguities.

> > Yeah, true. Way to few people helping with bug triaging :(
> 
> Let's give credit where credit is due.  The triagers are doing, imo, a
> pretty good job.  The collection/consolidation of duplicate bug reports,
> and even prioritization, seems to plug along.  The problem is that
> little gets done with the bugs once triaged.  Ultimately, one needs a
> developer "in" the discussion to interact with the users to get the
> information they need to figure out the problem in enought detail to fix
> it.

Exactly! Hence the increased necessity to not introduce bits of information 
that make bug reports "ineligible".

> Simply waiting around for non-developer users to magically come up
> with the development-level detail needed, without guidance, leads to
> frustration and inaction -- on all fronts.
> 
> > Assuming you don't like losing money without any change, have you tried
> > contacting one of the companies which provide services around KDE, such
> > as custom development, SLA contracts, etc?
> > 
> > There is at least one company which did quite some customer driven
> > enhancements for KMail/Kontact before.
> 
> We'd happily pay the community or foundation through memberships, or
> some such, if we could fidure out HOW to pay either, AND had the
> slightest confidence that what we asked for would get dealt with in a
> timely fashion, and pushed into a supported production-quality release.

I am pretty sure members of this list and come up with a couple of companies 
and individuals from the KDE community which have a proven track record of 
successfully delivering contract work.

> The process is broken -- many things that needing fixing aren't getting
> fixed.  That's not 'blame', that just 'is'.
> 
> We certainly pay for custom enhancements/development/etc where we need
> it.  Personally, I don't consider fixing functional regressions a
> 'customer driven enhancement'.  In this case, we're more than willing to
> contribute our time & effort to the solution where we can help.

Enhancement was just one example that came to my mind when writing my previous 
reply. I should have probably written customer driven development.
What I intended to write was that there are parts of KDE's software that have 
been developed by company members of the community on contracts for their 
customers. Features are just more visible, I am pretty certain that these 
contributions also contained fixes for issues that the respective customer 
wanted to be resolved.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20111017/5bec045c/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users