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

List:       kmail-devel
Subject:    Re: RFC: TLS default enabled/disabled?
From:       Michael =?iso-8859-1?q?H=E4ckel?= <Michael () Haeckel ! Net>
Date:       2001-05-21 20:16:16
[Download RAW message or body]

On Monday, 21. May 2001 21:02, Aaron J. Seigo wrote:
> 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.

Ok in general we unfortunately have an unhappy developer who finally said, 
that we can do with kio_smtp, what we want to. Well, he was already unhappy 
with the KMail developers before, so this problem not really new.
Sorry, but I simply can't agree to everything someone who is neither KMail 
developer nor KMail user absolutely considers to be necessary for a mail 
client he anyway doesn't like. At least Don shared the option with me and I 
think there were also a few others.

> 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?

I can't really see, what you have to do by hand.

Simple keep a directory
kdenetwork/kmail
and copy of it in
kdenetwork/kmailtest

You can run "cvs up" in both directories and usually this works without 
problems. At least I did this with some patches even over months.

I didn't say, that the code in CVS has to be bugfree, but it should be no 
means be that broken, that other developers have to suffer from the problems 
in a different part of KMail.

> 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.

At least I can't remember any big changes in KMSender and KMIdentity in the 
past weeks, so I don't really understand where you had conflicts.

> > 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

Well, actually I though, Don cares for this issue already, so I didn't care 
much about it. Non blocking sending was, what he worked on latest. I'm also 
happy, if I don't have to care for everything. Now I seem to have to, since 
he is away. I wonder, what would happen, if I would go for two months on 
holidays. 

I also didn't realise, where there could be a that big problem with the 
dependance on these profiles and I thought, is was clear, that we don't want 
that.

> 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.

Well, if you have it already and it works, it would be nice to see the patch 
of course. Then I can tell you more.

> 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.

I think this is done now.

> 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!)

Unfurtunately it appears to be difficult to discuss with reasonable arguments 
with some people. This was by no means the first discussion I had with Alex.
Maybe it was I mistake, that I tried to show him, how he always talkes about 
KMail by talking in the same way about kio_smtp. This probably was the 
biggest "fight" I had since I develop for KDE and in general I would of 
course also prefer, if that would go without such things.

>  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)

Can you please tell me any example, where you had a merging conflict due to 
this with your patch up to now?

> 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.

Again, I think that this final solution in now there, even if probably no the 
best possible one.

Regards,
Michael Häckel

_______________________________________________
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]