[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:       Cyrille Berger Skott <cberger () cberger ! net>
Date:       2010-12-08 14:25:55
Message-ID: 201012081525.55439.cberger () cberger ! net
[Download RAW message or body]

On Wednesday 08 December 2010, David Jarvie wrote:
> 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.

This is one of the reason behind the move to git, a developer can work easilly 
with a group of other developer to iron out the issues before it get merge. 
Unlike svn, where you would have either a branch that would be tricky to get 
up-to-date, and that no one would be following, or have a big uncommited 
patch.

With git (or any other modern DVCS ;) ), you would create a branch, makes your 
big changes, share your branches for all to see, and interested people take 
your branch and improve it, until it is ready for merging.

As for change in kdelibs breaking unit tests in other modules, it should not 
be a requirement to test all dependencies, the test that needs to pass are the 
one from the module where you are making changes.

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