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

List:       kmail-devel
Subject:    Re: RFC: TLS default enabled/disabled?
From:       "Aaron J. Seigo" <aseigo () mountlinux ! com>
Date:       2001-05-21 19:02:06
[Download RAW message or body]

hi..

> I still simply can't understand why we should have to pay the price of
> changing to a completely different way of storing information about POP and
> IMAP accounts, if we actually want to have SMTP authentification which is
> something completely different.

well, it looks like there might be some resolution to this coming? if so, 
then great ... my code right now is working with the current kmail identities 
and doesn't have any big issues beyond kio_smtp. however, one might suggest a 
more open attitude towards new ideas involving considering whether a new way 
would be better as opposed to simply whether it would be different.

> >  3) development of kmail right now happens mostly through large patches
> > so if you sit on large changes for any apreciable amount of time, it
> > becomes a nightmare (e.g. its not easy to keep your patch integrated
> > w/others and then someone commits some huge patch that they were
> > developing out of cvs for the last several weeks and there are conflicts
> > everywhere. bah)
>
> I think large changes require large patches.
> Also our opinion is, that the code in CVS should be always ready for
> general use, as long as there is no very good reason against that.

i appreciate your opinion on this, but i respectfully disagree. CVS is not 
for the storage of final pieces of work. it is mainly useful for facilitating 
_development_. when doing the kio_smtp stuff i had 2 versions of kmail on 
disk: the one in the build dir and a known stable version in my $PATH. that's 
a very easy way to find stability . that said, obviously large half-finished 
pieces of work should not be checked in to the main branch  (that's what CVS 
branch/joining is for), but waiting until something is "production ready" 
before commiting can only reduce the number of eyes that are on the code. it 
also makes getting involved w/kmail dev somewhat more inconvenient as one 
needs to do what cvs normally does _for you_: e.g. keeping track of where 
changes are going on, applying patches for testing, etc...

why have CVS at all if i end up doing its job by hand anyways? 


> At least I can't remember any big conflicts that would have required more
> than ten minutes of merging in the past time. Also as long only one single
> person works on SMTP, there should no problem appear.

maybe i don't have the time or the desire to manually merge patches and solve 
conflicts when CVS could help me avoid all that if only it was used properly.

> Your help is really very appreciated, however it is probably in general a
> bad idea to start coding, before the design issues are discussed.

i did talk about the design issues (here on the list and privately with 
others such as Neil whos patch i started with and Alex who has been writing 
kio_smtp) and got little useful feedback in return. the useful feedback which 
i did get (mostly from don IIRC) i used in my coding decisions. so right now 
in my kmail everything save a few config options in the kmail config gui and 
a fully usable kio_smtp are there and it is implemented as close to what the 
kmail devs would like to see from the bits of relevant discussion that were 
had and the rest of the source code that i've read in kmail. if your proposed 
change to kio_smtp makes it into CVS my code will work just fine w/out 
alteration.

the issue right now is waiting for the kio_smtp thing to shake out; its not 
about "starting coding before the design issue are discussed"  because that 
is not what happened.

my desire to develop on a project lessens when:

 o developers don't want to discuss the issues that need to be discussed
 o developers can't talk to each other about thing w/out it devolving into 
silly public bickering (witness the threads on kde-devel and the talk of 
"marketing decisions" and "microsoftian tactics". what RUBBISH!)
 o project maintainers decide to make development more difficult or require 
more time by not using the tools at hand to the fullest potential (e.g. CVS)


right now i do not care to involve myself in the kio_smtp/kmail issue  until 
a final solution has been agreed upon by the developers involved. once that 
is accomplished i will finish my patch up, test it, and send it to the list. 
until then i wait, and while i wait i do other things. no big deal.

-- 
Aaron Seigo
_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

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