--Boundary-02=_Utmf9i7D5ofLcIt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Tuesday 10 September 2002 21:45, Aaron J. Seigo wrote: > > Result: Don is where he wanted to be from Stage I on. He did harm > > the KMail project on the way, mind, since his branch is buggy as > > hell and KMail/HEAD loses testers big time. > > "buggy as hell" is, as a long term description, a lie and > disingenuous as an implication of care and quality. see above for > explanation why. It's what I projected from Don's attitude towards "trivial big fixes"=20 and from the announcement of "fast development before stability",=20 together with the experience that the amount of beta testing even HEAD=20 gets is not enough to find even all showstopper bugs. > if it remains "buggy as hell" nobody (or at least few) will use it, > thereby not harming HEAD at all. It's somtimes interesting how much people are willing to pay in=20 stability if they in turn get new features. :-( > > At which point do you stop supporting him, if ever? > > wrong question, because i'm not supporting Don. i'm taking advantage > of a bad situation by using it as a means to accomplish something > good. I understand your point now, thanks. > correct question: when do i stop supporting the branch? > answer: when it becomes nothing more than a political farce or is bad > for the overall future of KMail and/or KDE. this is something i've > discussed at great length and frankness with don and others in > private email to the point that i am satisfied that the branch > currently does not present a threat but an opportunity for > advancement. That's what it all boils down to, isn't it? Communication. Don has been=20 remarkably silent about what his intention is w.r.t. the branch. People=20 are trying to guess whether it's meant to be a linux-ac series like=20 thing or a temporary branch like aegypten_branch was or the preparation=20 of a fork. I miss a clear statement from Don about that. I _know_ that he said what=20 he wants to implement there, but unless memory fails me, nothing was=20 said what shall happen _then_. All the while he was busy with off-list conversation with people. Asking=20 whether they want to maintain a subsystem of his branch, stuff like=20 that. So I tried to inquire what were the motives for you and others to=20 work on the branch and what were your views on it's future to get a=20 hold on what people think who work on it. I didn't expect such a heated mail or it being sent to the list. Thanks for answering, though... > > - What makes you supporting his branch in the first place? > > Discontent with the way KMail is developed? What's wrong? > > kmail needs attention payed to its UI. based on past discussion of > things on the kmail list such as the multiple methods of handling > attachments (i count no less than 16 possible combinations, based on > two sets of 4 options that are set in two completely different areas > of the UI!), i have discovered that the current kmail developers are > unable to grasp the need for such changes and are unwilling to allow > them to occur. If you are talking about the mime part tree viewer and the inline/iconic=20 attachment options: I remember that you sent comments about that, but I=20 can't find a patch from you in my archive :-( > and that's cool. i'm not the maintainer. i humbly and quietly bow to > their wishes, insight and desires. no matter how wrong they are. You don't need to. People should defend their ideas or - better -=20 patches and try to convince people about it. See the mime tree viewer=20 and raw mimetypes discussion. I tried to present my view of the thing=20 and as the majority was of a different opinion, I implemented what was=20 obviously a good compromise. That's how decison-making happens in KMail. > but now there is a branch where i can explore the many needed UI > changes with a fairly free hand. i can not do this in HEAD even if i > wanted to, which i don't because i find fighting to get patches into > HEAD KMail tiresome. i have the stomach and energy for about one > KMail patch per release given the struggle it is to put even the most > trivial of items into HEAD. I'm sorry if you have gotten that impression. :-( The patches I found from you are mostly in KMail :-) Search dialog, fancy fancy headers, kio_smtp, hide attachments, to name=20 but a few. Patches need some iterations before they can be applied, though. It's no=20 different with my patches or Carsten's or Karl-Heinz's. That can be=20 boring, I know, but it's necessary, IMO. And that's how it works for=20 every other project I've contributed to. What I recently experienced is that people tell you "It's cool that you=20 are so conservative in getting patches into CVS because, you know,=20 KMail is special in that people don't like their mails being eaten.=20 OTOH, they are quite relaxed when Konq stops displaying their favorite=20 web page". Even KOrganizer, which also stores much personal information=20 is not that critical, judging from user feedback. I then think: "Umm, _are_ we conservative? I've seen so much stuff go in=20 that never should have gone in...", but you feel that how you do things=20 is more or less the correct way. But then, sometimes the same people come back a week later complaining=20 about this very thing. Well, you sometime feel quite pissed upon if=20 that happens :-( I don't think it is hard to get a patch in. You just have to follow=20 these unwritten rules: 1. better post you feature patch _after_ the relase, not shortly before.=20 ;-) 2. allow a few iterations of the patch to show that you mean it. Update=20 your patch timely, so that the others don't forget what it's all about=20 in the meantime. 3. If noone bothers to answer, set an ultimatum: "Will commit tomorrow=20 unless someons objects" If you don't have CVS access, find someone who=20 will commit it for you. Obviously, it helps if you stayed with your previous patch (if any)=20 after it has been comitted and fixed any bugs in a timely fashion. I'm not implying that you did otherwise, mind. Marc =2D-=20 They [RIAA,MPAA] are trying to invent a new crime: interference with a business model. --Bruce Schneier, Crypto-Gram 08/2002 --Boundary-02=_Utmf9i7D5ofLcIt Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9fmtT3oWD+L2/6DgRAreHAKDJx4RXj28QQq+/u45HA9jX3ZJRGwCdGH9U an5JMmaR9BTIy4VtGjO5FGQ= =XJd+ -----END PGP SIGNATURE----- --Boundary-02=_Utmf9i7D5ofLcIt-- _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail