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

List:       kde-devel
Subject:    Re: Thoughts from a former KDE, currently Mozilla developer
From:       Thiago Macieira <thiago () kde ! org>
Date:       2010-12-08 16:55:17
Message-ID: 201012081655.oB8GtOea005164 () mgw-sa02 ! nokia ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Em Terça-feira, 7 de Dezembro de 2010, às 11:22:47, Benoit Jacob escreveu:
> *****
> 1. Issue tracker (Mozilla) vs. Mailing lists (KDE).
> 
> KDE uses a Mailing list for most its development discussion, and only
> uses trackers (bugzilla, reviewboard) for specific tasks (user bug
> reports, patch review).
> 
> Mozilla uses a (modern, well-configured) bugzilla for almost
> everything including 90% of development discussion.
> 
> My point here is not to advertise bugzilla specifically (though I love
> it), but issue trackers in general.
> 
> An issue tracker, contrary to a mailing list, allows to efficiently
> keep track of what TODO items remain to be done, how they must be
> prioritized, etc. It also is much more convenient for core
> contributors because it allows them to handle issues later, so they
> can reclaim control of how they spend their time, instead of having to
> constantly handle the flow of emails.

Hi Benoît

Thanks for your suggestions. A couple of comments from me:

The issue tracker and the mailing lists are not mutually exclusive things. The 
issue tracker is a very good tool for, well, tracking issues -- bug reports, 
suggestions, even feature planning, requirements, unrelated tasks, etc. In 
some projects, it's also used for controlling the integration system (like 
WebKit). This I support and I think KDE should use more often.

One feature missing in Bugzilla is proper rich formatting, like a wiki.

The mailing list is where discussions happen and decisions are made.

Code reviews currently happen on mailing lists and that's how I prefer it. 
Some projects, apparently like Mozilla, do it all on the issue tracker. WebKit 
does it.

For Qt, what I'm trying to find is a system that integrates the review system 
to the mailing list. Something like we have for kde-bugs-dist: two-way, with 
enough information so people can filter incoming emails.

If I can't find such a system, I'll settle for a system with easy command-line 
access and mailing list logging (one-way only).

> *****
> 2. Can one tell volunteers contributors what they should be working
> on? (KDE: no, Mozilla: yes)
> 
> A common bit of KDE wisdom is that you can't tell volunteers what they
> should be working on, since they are volunteers. Mozilla is much more
> proactive in deciding what needs more attention, and what is just a
> waste of time, and that applies to everyone regardless of
> volunteer/employee status. Here I'm not saying that Mozilla got it
> right and KDE got it wrong, because the fact is that KDE has an order
> of magnitude more volunteer developers than Mozilla has, and that
> could partly be related to that. However, KDE could do more to
> communicate what actually needs to be done, for the benefit of those
> volunteers who are interested in investing their time in what's most
> useful. It's nice making everyone feel that they can "be KDE" but the
> truth is that you are much more KDE when you work on what KDE really
> needs.

There's a huge difference in that Mozilla is mostly developed by the Mozilla 
Corporation, which is owned by the Mozilla Foundation. The Corp. people are 
paid to work on what the Corp. wants them to, which in turn takes their cue 
from the community suggestions (among other sources).

That said, however, one thing that KDE can do better is to collect the 
suggestions, trends, requests and organise them for the volunteer 
contributors. I've seen many a contributor who wants to do something but 
doesn't know where. A little guidance could do wonders.

> *****
> 3. QA, Unit-testing, continuous testing (KDE: very little, Mozilla: a lot)
> 
> Let's face it, KDE has always been deficient in the QA department. In
> order to ensure good QA, it needs:
>  * a lot more unit tests than it currently has (Kate in SC 4.5.0 was
> horribly buggy)
>  * unit tests must be automatically run, frequently. In mozilla,
> everything is built and the unit tests run on 10 configs everytime you
> push to the repository, see http://tbpl.mozilla.org/
>  * this means investing in some build hardware. There are cloud
> services for that, too.
>  * regressions must never be tolerated. if a commit causes a
> regression, back it out. If a big set of changes need to go through a
> bad intermediate state, develop it e.g. in a separate git repository.

That's a laudable goal and one we do for Qt. We can't test every push, though, 
simply because that doesn't scale. I have some material I'm preparing that 
I'll share on this subject by the end of the year.

KDE is much futher back in that. It's not reasonable to say jump from where 
KDE is to where Mozilla or Qt are. It needs to be a gradual process, with a 
plan.

For us in Qt, we've had unit tests running for over 7 years. But it wasn't 
until last year that we had a system that tested the incoming changes and 
blocked them if a regression happened. Even then, the coverage is very low 
(around 60% on average) and there are many unstable tests.

And a proper build farm can cost in the range of millions of dollars. I doubt 
we can find such a farm for KDE. Donated resources and distributed reports are 
our only option.

> *****
> 4. Crash reports handling (KDE: poor, Mozilla: good)
>  * Have a look at Socorro, Mozilla's crash report tool:
> http://crash-stats.mozilla.com/products/Firefox
>  * Crashes are grouped by signature so you get prioritization for free
>  * For each crash you get a call stack, a modules map...
>  * If KDE wants that, it needs to sort the difficult issue of how to
> get symbols. The logical approach is to work with distros here.
>  * I've come across this: https://wiki.kubuntu.org/Apport . Quote:
> "Apport reports include a core dump in a compressed and unencoded
> format". If this is true then I don't get 1) how you can attempt to
> upload a potentially huge core dump, and 2) how you handle the obvious
> privacy issue here (if "unencoded" means unencrypted then this is
> horrible; if not, there's still a huge privacy issue, the user may not
> want anyone, not even the developer, to be able to see his credit card
> number).

Already discussed. Crash reports only work if you build the software and 
distribute it in binary form. So it works for downstream (the distros), but 
not for KDE.

And there's the privacy issue. I'll never upload a crash dump of Konqueror, 
kded, kwalletd, kmail or 10 other software I use daily. Even a kwrite crash I 
wouldn't upload if I were typing some notes of a confidential meeting with a 
client.

> *****
> 5. KDE's approach to the Web
>  * KDE, being a local desktop project, can only believe/hope/target
> that the user wants local rich applications. That's OK, not up for
> discussion.
>  * KDE hopes that the user will want to use web content integrated
> into local applications. That's more speculative, but not something I
> can really argue against. My belief is that web content is very hard
> to dissociate from the browser while retaining a good user experience,
> and it's only getting worse.

HTML5 and local "webby" applications are somewhat changing that. But I agree 
with you, personally, that web applications are hardly the rich interfaces I'd 
like to use.

Ever noticed what happens when you accidentally click twice on a "Next" 
button, like a presentation viewer? Local app: goes two pages down; Web app: 
first click is discarded.

>  * KDE could learn a lesson from the popularity of web apps. Web apps
> aren't really better than local apps, but they're far easier to
> deploy. Where distros still struggle to offer 1-click install, web
> apps offer 1-click use. So PackageKit/PolicyKit are very exciting
> here, but this needs to be taken to the next level. The day that
> you'll be able to guarantee to developers that KDE apps benefit from a
> 1-click-use system (of course after some authentication) you'll have a
> very powerful selling point to get them to develop KDE apps, not just
> Qt apps, say.

Deployment is a huge issue, I agree with you. That's not for us to solve 
though.

Distributions have solved this problem neatly.


-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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