[Kde-pim] Cleaning up obsolete features

Sun Aug 2 10:24:49 BST 2015

On Saturday 01 August 2015 14:32:27 laurent Montel wrote:
> Le Friday 31 July 2015, 23:16:15 Volker Krause a écrit :
> > On Friday 31 July 2015 22:38:42 laurent Montel wrote:
> > > Le Friday 31 July 2015, 19:26:24 Volker Krause a écrit :
> > > > Hi,
> > > > 
> > > > over the past 19 years KMail has accumulated a few features that have
> > > > been
> > > > needed and useful at some point, but have become obsolete for various
> > > > reasons. They clutter the UI and increase the amount of code that has
> > > > to
> > > > be
> > > > maintained. At the PIM meeting at Akademy we therefore discussed to be
> > > > slightly more aggressive than so far in cleaning this up.
> > > > 
> > > > Examples of things that are already gone:
> > > > - tip of the day (got out of fashion after the 90s)
> > > > - local sendmail support (not shipped/installed by modern distros)
> > > > - system speaker beep notifications (dysfunctional with semi-recent
> > > > hardware)
> > > > 
> > > > Here's a few more ideas:
> > > > - application-local network proxy settings, seems of questionable
> > > > value
> > > > with most network I/O actually happening elsewhere. System proxy
> > > > settings
> > > > should cover this.
> > > > - there's 5 checkboxes to enable different Outlook/Exchange
> > > > compatibility
> > > > aspects of iTip messages. If that's needed at all nowadays, there
> > > > should
> > > > be
> > > > just one.
> > > 
> > > Indeed.
> > > 
> > > > - configurable host name for SMTP, even changeable per identity??
> > > 
> > > It was ask from user.
> > > 
> > > > - external composer editor support
> > > 
> > > It's unit tested.
> > > So why remove it ?
> > > 
> > > > - customizable Message-Id prefix
> > > > - show user agent in fancy header option, if you really care about
> > > > that,
> > > > look at the message source. Same for the "all headers" header style.
> > > > 
> > > > More ideas? Objections? :)
> > > 
> > > Objections of course.
> > > I don't see why we need to remove feature which works ?
> > > 
> > > How we will explain to user that we removed features ?
> > > 
> > > I don't understand idea to remove feature which works ?
> > 
> > The tip of the day feature also did work, still I think it made no sense
> > to
> > keep that ;)
> 
> Yep but it was not changed from long time and it was an obsolete technology
> (and as you wrote it was just used by kontact). So ok for removing it.
> 
> > It's not about removing things that work and are used. It's about not
> > wasting time on maintaining stuff that doesn't.
> 
> How will you define that this specific feature is not used ?
> 
> I am ok to remove obsolete technology or technology which doesn't work with
> actual hardware as beep feature.
> 
> But removing code as ' "all headers" header style ' will not cleanup code or
> makes it easy to maintain kmail.
> It's just a little class in messageviewer.
> If you want to reduce code we need to remove all style so ok we will reduce
> code so it makes sense to reduce code (but it doesn't make sense to do it :)
> )

You are right, the maintenance gain by just removing the "all headers" mode is 
minimal, and I definitely don't want to remove the entire header styling, that 
makes no sense indeed.

The reason I listed it is that I see "all headers" in the same category as 
"tip of the day", it probably made sense 15 years ago, before the mail 
transport systems injected two dozen headers on the way. See attached 
screenshot how this looks nowadays, it fills my entire screen height just with 
headers.

There's definitely use-cases for looking at all headers (like when creating 
filters), but we have the source view for that. And if you need specific 
headers for a certain workflow, the custom styles are the far better option I 
think (which probably didn't exist yet when "all headers" was added).

So, we have a feature that doesn't really offer any value anymore IMHO, but we 
prominently advertise  it in the menu. That is my main concern here, it 
clutters the UI and doesn't give a nice impression to the user.

> But for me the real problem is not to reduce code, but perhaps be able to
> have more developers and we need to have developer will work during all the
> year and not just during sprint or akademy.
> 
> Because if we remove some part of code but we don't have more developer I
> don't see how it will improve situation no ?
> 
> To improve the situation we need real maintainer for several part of code
> for example for all resources because for the moment as we have a lot of
> part of code which are not maintaining.
> I read a lot of bug report about kmail but it's not kmail but some bugs in
> resources for example.
> 
> Removing codes can be sense sometime but if nobody fixes existing bug it
> will not improve the situation.

Fully agree, deleting code is obviously not the answer for every problem :)

Recruiting more developers definitely should be the main priority. For this I 
think we need an attractive product, which means bug fixes and performance 
optimizations, but also new features (as you wrote elsewhere in the thread) 
and user experience improvements. And we need regular releases, getting into 
the 15.08 release therefore was very important IMHO.

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmail-all-headers-style.jpg
Type: image/jpeg
Size: 65342 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20150802/222420d1/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20150802/222420d1/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/