Hi, I would like to share some hopefully interesting thoughts, from a comparison of a few things in KDE and in Mozilla, in the hope that it helps KDE borrow good ideas from elsewhere.
***** 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. ***** 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. ***** 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. ***** 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). ***** 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. * The KHTML/WebKit issue. I understand that WebKit, even just the Qt-provided version, has more developers than KHTML has, therefore it's the natural choice for KDE applications going forward. What I don't understand is that nobody seems to see the huge value in KHTML as a project. OK, it's probably not going to be the default Web engine in KDE for the time being if you want to guarantee your users a top-class experience; but I hope very, very much that you keep KHTML around, possibly as an optional non-default-install component. Indeed, there are very few credible open source Web engines around here: Gecko, WebKit, KHTML. If I were a volunteer looking for a project to contribute to, KHTML would be an incredibly strong candidate: small enough to be approachable, still a credible web engine (I can't believe how well it works in 4.5 given how complex web apps have become) and contributing to KHTML allows one to learn extremely valuable skills (web technologies). KDE should totally push KHTML as one of the very best developer learning experiences of any open source project, for prospective contributors. And learning is a huge aspect of open source development. And who knows, if you do this, first you'll get new people into KDE development, second you might find that in several years KHTML is revived. I estimate that 50 dedicated developers people is the minimum to get a modern web engines going. * KDE still needs a plan for the case where web apps might win the "war" against local apps. Experiences about HTML backends to Qt would be exciting. * 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. Cheers, Benoit >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
