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