[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:       "David Jarvie" <djarvie () kde ! org>
Date:       2010-12-08 14:09:38
Message-ID: 1a8dba7e392c754e0c807b795d890b34.squirrel () www ! sensical ! net
[Download RAW message or body]

On Wed, December 8, 2010 8:38 am, Kevin Ottens wrote:
> On Wednesday 8 December 2010 02:51:46 Aaron J. Seigo wrote:
>> On Tuesday, December 7, 2010, Benoit Jacob wrote:
>> > *****
>> > 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.
>
> Note that it piggy back to unit tests IMO. If a commit causes a regression
> caught by a unit test it should be reverted indeed. If that happens it's
> mainly a problem during the reviewing phase and so on. Going beyond than
> that
> could indeed discourage development contribution (unit tests are easy
> enough to run before you send the patch to be a good compromise).

For smaller commits, it seems reasonable to demand that they don't cause
regressions. For larger commits, it won't always be possible to test
sufficiently for regressions before committing - there may be too many
affected apps if a change is made in the libraries, and a single developer
can't be expected to have the time or knowledge to test multiple apps.
This may apply much less to Mozilla than it does to KDE.

Another important consideration is that major changes being developed will
often have to play catch-up before they are committed, the patches having
to be modified frequently as changes are made to the libraries and
applications affected. To insist that no regressions occur would mean that
such patches might never be committed, by part-time developers at least.
As long as there is time for testing before the next KDE release, most
regressions can be caught afterwards, and that's probably the best that
can be hoped for.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm

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