[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:       Benoit Jacob <jacob.benoit.1 () gmail ! com>
Date:       2010-12-07 21:50:09
Message-ID: AANLkTinW6edAGMKCL=VCr4DmgOjDNUMap0k8nZ+2FezY () mail ! gmail ! com
[Download RAW message or body]

2010/12/7 Stephen Kelly <steveire@gmail.com>:
> 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.
>>
>> *****
>> 1. Issue tracker (Mozilla) vs. Mailing lists (KDE).
>
> Hi,
>
> Are you suggesting we ditch k-c-d in favour of a bugzilla instance? Or that
> we try to make people open issues instead of threads?

I'm suggesting that lists such as k-c-d remain open for general
discussions that don't fit well in an issue tracker, but that most
technical discussion (maybe 80% of the volume) moves to an issue
tracker.

> Do the 'I can't print
> from okular' bug reports live together and get mixed with the 'Lets do
> something about QT_FATAL_WARNINGS in kdelibs unit tests' issues? Do they
> need to be categorized/tagged by someone?

They definitely need to be categorized, so that's one very important
kind of feature to require from an issue tracker.

> As another data point, Django uses a trac instance for everything. Each
> patch lives as a ticket and gets reviewed for a long time before it hits the
> repo.
>
> I don't know if it would work for KDE, but the transition would certainly
> leave a lot of people behind who would reject the workflow and do something
> else instead.

1 ticket per patch is a bit overkill imho (that's what I don't like
about reviewboard too), I prefer 1 ticket per feature / discussion
topic. (And then have potentially many patches attached to it).

>> *****
>> 3. QA, Unit-testing, continuous testing (KDE: very little, Mozilla: a lot)
>
> Here's another impressive one as a data point:
>
> http://buildbot.twistedmatrix.com/boxes-all
>
> Many people do already run the tests and builds regularly. There was an idea
> floated to get obs and other distros doing builds anyway to use our cdash,
> but I don't know if anyone investigated or pushed it.
>
> Lots of stuff could be better unit tested, and the tests are coming. It's
> hard to retrofit them though, because they haven't always been there.
>
> Do you have concrete suggestions about infrastructure for writing more unit
> tests or is this more about running them for every commit?

I don't really have suggestions, as KDE = local GUI apps is not a kind
of software I'm used to test. In Mozilla, we're using html/js pages as
most of our tests. I'm sure that other people here have more precise
ideas about how to test KDE software. Since KOffice^WCalligra has
tests, that must be doable. i guess that having the features in a
library, as opposed of having them in the app itself, helps a ton.

Cheers,
Benoit
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]