[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:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2010-12-08 1:51:46
Message-ID: 201012071751.46828.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday, December 7, 2010, Benoit Jacob wrote:
> 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.

thanks :)

> *****
> 1. Issue tracker (Mozilla) vs. Mailing lists (KDE).

this is largely cultural and probably is of very low utility to try and change 
significantly. there are arguments pro and con to each way of doing it. it's 
like code formatting rules. ;)

while we can all agree that "no structure" is insane, what that structure 
should look like can vary with equal resulting success.

that said, KDE has continued to increase the use of formal structure with 
things such as review board in recent times, with more and more mailing list 
(or worse: straight-to-commit-fix-it-later) chatter moving to that. ditto for 
the wikis, which are now used quite a bit for project planning and recording.

is it the best thing possible? probably not (best is always a high bar). but 
it's something that fits the culture around kde. we have better things to 
screw with that are less likely to pull the whole rug out from under us. 
communication is not something to be toyed with lightly.

> *****
> 2. Can one tell volunteers contributors what they should be working
> on? (KDE: no, Mozilla: yes)

a nice bit of philosophy. imho:

should we communicate what is needed to be worked on? yes.
should we make it "cool" to work on what is needed by offering support and 
positive reinforcement? yes.
should we tollerate those who refuse to do so? yes.
do we always know what is needed? no.
can we always know what is needed? no.

several projects within kde do engage in both guidance as well as group agenda 
setting. in that specific way, it's not quite the kde of 5 years ago.

"However, KDE could do more to communicate what actually needs to be done"

do you have some concrete applicable suggestions?

> *****
> 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

agreed. care to donate some resources? :)

>  * unit tests must be automatically run, frequently.

agreed; people are working on automated unit test set ups for kde. we have 
more variance than mozilla does however, which means this:

>  In mozilla,
> everything is built and the unit tests run on 10 configs everytime you
> push to the repository, see http://tbpl.mozilla.org/

would be great. given our resources and the variety of our targets, highly 
unlikely for now. in future, perhaps.

>  * regressions must never be tolerated. if a commit causes a
> regression, back it out. 

ah, blanket statements. as a rule of thumb: good idea. rigidly followed: 
stupid, as it's an awesome way to discourage development contribution.

> If a big set of changes need to go through a
> bad intermediate state, develop it e.g. in a separate git repository.

common sense, yes. hard until we have git, though ;)

> *****
> 4. Crash reports handling (KDE: poor, Mozilla: good)

yes, much could be improved here. it has already gotten better, but there are 
gaps left. good news is that they are being filled rather than just remaining. 
i don't think your suggestion to use server side tracking is helpful at all 
for KDE given our target platforms, but the "making it easier to triage" can 
not be said enough in general :)

the auto-duplication finder in dr. konqi as well as the hand-holding-the-user-
through-the-steps-to-make-a-proper-report are great.

and in some ways, Mozilla has a far, far easier task and so can benefit from 
things that we can probably only dream about. :/

> *****
> 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.

that doesn't particularly mesh neatly with KDE's current focus. not in an age 
where we have ownCloud on the one side, mobile on the other, and desktop focus 
still there too.

>  * KDE hopes that the user will want to use web content integrated
> into local applications.

we don't actually hope for it, we have users that do so and quite enjoy it. 
it's not a silver bullet for every situation, however; it's a realization of 
where it makes sense, it makes sense. the dichotomy between "this is web" and 
"this is not web" is utter nonesense; some things "are web", some things "are 
local" and many things are a mix in between.

> 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.

for some things, yes. and that's ok.

<snip>

> top-class experience; but I hope very, very much that you keep KHTML
> around, possibly as an optional non-default-install component. Indeed,

that isn't up to "us", that's up to the KHTML team. they continue to work on 
it, and as long as they do then it will remain around, probably in future as 
an optional component as you described.

> 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.

you know what they call someone who does the same thing over and over 
expecting the results to be different?

>  * 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.

no, they wouldn't be. unless we wish to write web apps using Qt. because 
simply putting a desktop app into a web browser doesn't make it appropriate 
for web deliver (or even feasible). web apps and desktop apps are not written 
in the same way because the fundamental underlying computing architecture is 
different.

if web apps "win the war" (a statement with far too much black and white in it 
for my tastes, but whatever), then we just move on. if people are indeed very 
well served and don't want anything else, then we don't need to bash our heads 
against a wall of non-existent users. :)

>  * 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.

agreed (it's not just deployment that adds to the popularity, but it's a 
significant part of it)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

["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]