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

List:       kmail-devel
Subject:    Re: Stuff I'm working on
From:       Marc Mutz <mutz () kde ! org>
Date:       2002-09-10 21:59:40
[Download RAW message or body]

On Tuesday 10 September 2002 21:45, Aaron J. Seigo wrote:
<snip>
> > 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" 
and from the announcement of "fast development before stability", 
together with the experience that the amount of beta testing even HEAD 
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 
stability if they in turn get new features. :-(

<snip>
> > 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 
remarkably silent about what his intention is w.r.t. the branch. People 
are trying to guess whether it's meant to be a linux-ac series like 
thing or a temporary branch like aegypten_branch was or the preparation 
of a fork.

I miss a clear statement from Don about that. I _know_ that he said what 
he wants to implement there, but unless memory fails me, nothing was 
said what shall happen _then_.

All the while he was busy with off-list conversation with people. Asking 
whether they want to maintain a subsystem of his branch, stuff like 
that. So I tried to inquire what were the motives for you and others to 
work on the branch and what were your views on it's future to get a 
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 
attachment options: I remember that you sent comments about that, but I 
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 - 
patches and try to convince people about it. See the mime tree viewer 
and raw mimetypes discussion. I tried to present my view of the thing 
and as the majority was of a different opinion, I implemented what was 
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 
but a few.

Patches need some iterations before they can be applied, though. It's no 
different with my patches or Carsten's or Karl-Heinz's. That can be 
boring, I know, but it's necessary, IMO. And that's how it works for 
every other project I've contributed to.

What I recently experienced is that people tell you "It's cool that you 
are so conservative in getting patches into CVS because, you know, 
KMail is special in that people don't like their mails being eaten. 
OTOH, they are quite relaxed when Konq stops displaying their favorite 
web page". Even KOrganizer, which also stores much personal information 
is not that critical, judging from user feedback.

I then think: "Umm, _are_ we conservative? I've seen so much stuff go in 
that never should have gone in...", but you feel that how you do things 
is more or less the correct way.

But then, sometimes the same people come back a week later complaining 
about this very thing. Well, you sometime feel quite pissed upon if 
that happens :-(

I don't think it is hard to get a patch in. You just have to follow 
these unwritten rules:
1. better post you feature patch _after_ the relase, not shortly before. 
;-)
2. allow a few iterations of the patch to show that you mean it. Update 
your patch timely, so that the others don't forget what it's all about 
in the meantime.
3. If noone bothers to answer, set an ultimatum: "Will commit tomorrow 
unless someons objects" If you don't have CVS access, find someone who 
will commit it for you.

Obviously, it helps if you stayed with your previous patch (if any) 
after it has been comitted and fixed any bugs in a timely fashion.

I'm not implying that you did otherwise, mind.

Marc

-- 
They [RIAA,MPAA] are trying to invent a new crime:
interference with a business model.
                           --Bruce Schneier, Crypto-Gram 08/2002

[Attachment #3 (application/pgp-signature)]
_______________________________________________
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]