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

List:       kmail-devel
Subject:    Re: Stuff I'm working on
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-09-10 19:45:59
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

WARNING: what follows is honest, candid and contains a few curse words. 
don't let your children or those who are allergic to any of the preceding 
forms of communication read this mail.

;-)

On Tuesday 10 September 2002 12:55, you wrote:

<snipped long and accurate history of events along with some predictory 
statements>

> OK, please tell me where my simple logic fails to grab the situation

right where it starts getting involved in the politics of the situation.

i really don't give a SHIT about your politics. 
nor do i give a SHIT about michael's politics. 
and i don't give a SHIT about don's politics, either.

now, i do care very much for writing code (principles) and having fun 
(payment). which makes me feel that the way this has all gone down sucks big 
donkey nuts. and i mean BIG donkey nuts, because the flames neither resulted 
in me writing more code nor has it been fun to endure (even from the 
sidelines). but what could i, or anyone not embroiled in the stupid, childish 
and foolish POLITICS of it all do? nothing.

but from here on out i sure as hell CAN do something: make a positive 
environment given the situation. this is often referred to as "making 
lemonade out of lemons". if you find this attempt at positivity offensive, i 
couldn't care less. don't even bother bringing your politics to me, because 
i'll walk right over them with a single finger waving goodbye back to you.

i hope that makes my position very clear on the matter of partisanship.

> Don is a maintainer of a feature-rich, but completely buggy branch (his
> own words were to sacrifice stability for rapid development, mind!). he

a) i'm running the make_it_cool branch right now, as will all the people 
working on it. that's already been discussed. if it breaks, we'll know it and 
be motivated to fix it. this is NO different than any other part of KDE, 
which i also run the HEAD devel versions of for DAY TO DAY work.

b) the stability sacrifice is a short-term play to allow rapid development. it 
will be followed by a period of stabilization to catch anything that was left 
unperfect during the fast devel stage. this is project management 101, not 
some daring new software escapade.

> comes back with "I'd like to merge make_it_cool into HEAD. Objections?"
> The "people maintaining head" don't want to rush in all changes at once.
> See what Aegypten did to KMail (and still does). Don again makes it an
> all-or-nothing thing. The HEAD people are forced to refuse and start
> working on merging some stuff.

this isn't the only option. there are several other options, most of which 
include some variation of:

 o merging patches and fixes from HEAD to branch (and/or vice versa)
 o allowing branch to become HEAD eventually
 o allowing the two to diverge significantly in capabilities and aim.

so it remains to be seen if this more like the linux kernel devel/stable 
branches, more like the egcs/gcc fork, or more like the emacs/xemacs fork. 
but the conclusions you present are not the obvious end point of this 
exercise.

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

if it remains "buggy as hell" nobody (or at least few) will use it, thereby 
not harming HEAD at all.

if it isn't buggy as hell, then the best software will win. and by win, i mean 
any of the following:

 o the two merge
 o the two diverge and have happy, successful, seperate future lives
 o one becomes dominant due to technical superiority and the other withers 
away

to quote perl jam: "it's evolution, baby!"

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

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.

> Where's the point  that makes you think: Hey, something is wrong here?

the moment people keep asking me about the fucking politics involved. that's 
happened from both BRANCH and HEAD people, so i can't decide based on that 
alone. therefore, i'm making my decisions based on other issues that i 
actually care about.

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

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.

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. 

if the HEAD maintainers like the UI changes (which i hope they will) then they 
can be ported over. if not, they can stay in the branch. at least i get to do 
what needs to get done SOMEWHERE.

peace out. *two chest thumps* ;-)

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9fkv31rcusafx20MRAnJGAJ9teai/64Rq4CjC0ZWdHOB6Y8x0OACgojhU
IJeqhQwer858PFoRMFRnmWo=
=PcRa
-----END 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]