[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Integrated subset of make_it_cool
From:       Carsten Burghardt <cb () magic-shop ! de>
Date:       2002-12-31 14:39:35
[Download RAW message or body]

Am Dienstag, 31. Dezember 2002 11:35 schrieb Alexander Kellett:
> Hiya Carsten,
>
> On Tue, Dec 31, 2002 at 06:38:00AM +0100, Carsten Burghardt wrote:
> > > Now I am quite happy to engage in this activity myself if it is
> > > productive. But KMail's development had staganated and my changes
> > > have been and are being obstructed for political rather than
> > > technical reasons.
> >
> > That is not correct and you should know that.
>
> which part?, the fact that kmail's development _had_ staganated
> or the fact that the kmail mailing list has probably contained
> more political posts than ones with technical content in the
> last few months?

That "changes have been and are being obstructed for political rather than 
technical reasons". Just show me one patch that was rejected because of such 
reasons.

> > But this is not the way it works. The features your're implementing are
> > for the users, that is correct. But why do you think that your code is
> > perfect and without bugs that could be found by reviewing?
>
> personally i don't see any problem with commiting early. the main
> problem i see with kmail development is that very useful features
> have not gone in even while patches have been available for months.
> simply (from my outsider point of view) because the patches couldn't
> be "proved perfect". this is completely against the "natural" commit
> style of open-source. imo. you should have many eyes watching commits,
> not stopping them.

A small example from me: my patch for the subscription is not perfect but 
ready to go in. I simply don't want to commit it because of the current 
chaos.

> anyway. i think src code should be in a constant state of flux and
> problems like stability and correctness should be addressed via regression
> tests rather than patch review. anything that improves code quality should
> go in by default :)

Will you tell that the user when their emails are busted or when they can't 
use the client anymore because it crashes on reply? 

> > Take mozilla as an example. Every single patch has to be approved by the
> > maintainer of the particular part and by the maintainer of the
> > (sub)project. And mozilla doesn't seem to stagnate.
>
> mozilla is pretty stagnant imho.
> its only due to the large amount
> of (paid?) developers that it
> makes any progress.
>
> but this is all this my opinion of course ;-)
>
> Alex
> _______________________________________________
> KMail Developers mailing list
> kmail@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kmail

-- 
Dipl.-Inf. Carsten Burghardt
PGP: http://www.magic-shop.de/Carsten_Burghardt.asc

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]