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

List:       kmail-devel
Subject:    Re: KMail devel process
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-09-11 15:00:17
[Download RAW message or body]

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

On Tuesday 10 September 2002 08:01, Ingo Klöcker wrote:
> About the search stuff: The results of a search should be presented in a
> virtual folder. It should be possible to save the search results resp.
> the corresponding virtual folder and it should be possible to
> re-initiate a search. The search dialog itself should be stripped from
> the result list and more than two conditions should be allowed.

these were basically my thoughts as well... vfolder stuff is apparently on the 
way, so that should help, and we can reuse the rule widgets from the filter 
dialog ...

> Unfortunately I never had time to look at this patch. I'm glad that it
> will finally be included.

> Hmm, maybe the difference is that KMail has more core developers who
> have to be convinced of the usefulness of a patch than other parts of
> KDE.

yes, and this is part of it. the other part of it as that the core devels tend 
to be a bit more pressed for time, a bit less communicative than some of the 
other project maintainers, and a bit less willing to flex and "try things 
out" (in part because of a perceived need to keep kmail 100% stable 100% of 
the time)... and this is stunting kmail development.

of course, now that we have 2 branches going on, this may be a moot point. the 
blocker has been routed around?

> > is this bad? i dunno... but this is how it is. if you and the other
> > core hackers weren't aware of this situation, now you are.
>
> I don't think it's bad that more than one developer has a look at
> external patches. 

how about: at least one developer looks at external patches? often even THAT 
would be better than what happens. i remember posting a series of patches and 
following up on them a couple of times an nobody even looked at them until i 
finally committed them.

expecting multiple people to OK something when often the reality is that noone 
looks (for reasons of time or desire or whatever) is obviously a problem. an 
improvement even would be: make sure every patch gets at least scanned and 
looked at and by the OK of even one of the core devels it can go in?

> The problem with external patches is that the quality
> ranges from ugly as hell to beautiful.

IME this hasn't been a factor in the treatment of individual patches.

> JFYI, they in both cases branches were created because of the tight
> schedules of those projects. In both cases they have/had to begin
> working on their projects and thus making heavy changes to the code not
> to soon before a KDE release. Obviously it wasn't possible for them to
> put their unfinished code into the soon-to-be-released HEAD branch.

my point is that it obviously works as a way to keep kmail stable in HEAD 
while advancing with agressive development elsewhere.

> The problem with a perpetual development branch is that just before the
> releases when all developers are needed to fix all outstanding bugs a
> lot of developers will like it better to implement yet another cool
> feature in the development branch. Why do you think we have a feature

let me pedantic for you, then: development considered too risky for the 
stability of KMail in HEAD (which, btw, i think is a complete red herring, 
but it is the wishes of the maintainers...) can occur in a branch, which will 
then be merged back to head upon stabilization. such merges would occur in 
coordination with release schedules, and only be done once stabalization was 
reached in the branch.

as many branches as needed for as many "risky developments" can be openned, or 
it can be held to one or two branches at a time. the branches would be open 
for much more free-wheeling commits focussed on a small set of goals (e.g. 
not open hunting season for patches, but goal oriented).

kind of exactly what the aegypten branch was and what the new kroupware branch 
will be.

clearer?

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

iD8DBQE9f1qB1rcusafx20MRAv19AJ0ZNwcqzFxnsZy7LzJdMzy6mkSSBQCdGwin
GPA0d4CtoxleqE9YolIutDY=
=/bCR
-----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]