Tag: KDE, KDE / Home

KDE

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
Home » KDE

  • KMail policy regarding closing bugs

    5 answers - 577 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    Hi,
    For the upcoming bug triage next Saturday, I was wondering if there is some
    policy/guidelines to follow when closing bugs as INVALID or WNTFIX.
    For example, in my opinion, invalid bug reports are reports with insufficient
    information and no response for longer than >1 year. Maybe we should tighten
    the interval a little more to 9 months or something.
    A WNTFIX is harder to determine as not being a maintainer, so I need some
    help on that.
    Will there be a KMail maintainer (Ingo, Till, ) around next Saturday?
    Kind regards,

  • No.1 | | 1155 bytes | |

    Hi Ingo!
    Am 26.10.2006 um 22:55 schrieb Ingo K:

    In any case, I'm not so sure whether it makes so much sense closing
    KMail bugs because a year from now KMail will hopefully be replaced by
    something completely different (based on Akonadi and completely
    modular; yes, I'm dreaming).
    []
    TH, most of those bugs are almost impossible to fix with the current
    architecture.

    Modularity is the key word for me. I fear that we don't have the time
    to rewrite Kmail from ground up. Thus, I think about a valid path to
    improve modularity without loosing an already working mail client.
    Currently I try to get my feeds into this KDE-Pim stuff and I had a
    very brief look into the sources of KMail. I don't had the time to
    analyze the details, but the sources doesn't look that bad for me.
    I'm sure that I overlooked the problematic aspects in the code (as
    said: I don't had the time to look into the details). Thus I would
    really happy if you (or somebody else) would be so kind to give me
    some short hints where to look at.

    Thanks! :)

    Mfg., Dr. Stefan Eilers

  • No.2 | | 805 bytes | |

    Wed, Nov 01, 2006 at 07:42:56PM +0100, Stefan Eilers wrote:
    Hi Ingo!
    Am 26.10.2006 um 22:55 schrieb Ingo K:
    Hi Stefan,

    Modularity is the key word for me. I fear that we don't have the time
    to rewrite Kmail from ground up.
    I don't want to discourage you but rewriting KMail from ground up is the
    only solution we have to keep up with Thunderbird, or Evolution.

    The code base has grown over years and too less time was invested in
    refactoring, so in the current state as soon as you touch one piece of
    code a side effect may appear somewhere else without noticing it.

    course it is possible to do the refactoring, but it takes a lot more
    time (since you have to figure out _all_ code pathes inside kmail) than
    rewriting it

    Ciao,
    Tobias

  • No.3 | | 973 bytes | |

    Hi Tobias!
    Am 02.11.2006 um 17:22 schrieb Tobias Koenig:

    >
    >Modularity is the key word for me. I fear that we don't have the time
    >to rewrite Kmail from ground up.
    I don't want to discourage you but rewriting KMail from ground up
    is the
    only solution we have to keep up with Thunderbird, or Evolution.

    Well I'm sorry to hear this.

    The code base has grown over years and too less time was invested in
    refactoring, so in the current state as soon as you touch one piece of
    code a side effect may appear somewhere else without noticing it.

    Do you have some examples? I would like to look into the code to get
    a sense for this problem.

    course it is possible to do the refactoring, but it takes a lot
    more
    time (since you have to figure out _all_ code pathes inside kmail)
    than
    rewriting it

    Thanks for the warning :)

    Mfg., Dr. Stefan Eilers

  • No.4 | | 567 bytes | |

    Fri, Nov 03, 2006 at 07:15:08PM +0100, Stefan Eilers wrote:
    Hi Tobias!
    Hi Stefan,

    >The code base has grown over years and too less time was invested in
    >refactoring, so in the current state as soon as you touch one piece of
    >code a side effect may appear somewhere else without noticing it.

    Do you have some examples? I would like to look into the code to get
    a sense for this problem.
    I'm not a KMail developer, but Till and Ingo should give you a couple of
    examples.

    Ciao,
    Tobias

  • No.5 | | 1572 bytes | |

    Heya Stefan,

    Friday 03 November 2006 19:15, Stefan Eilers wrote:
    Hi Tobias!

    Am 02.11.2006 um 17:22 schrieb Tobias Koenig:
    >Modularity is the key word for me. I fear that we don't have the
    >time to rewrite Kmail from ground up.
    >
    I don't want to discourage you but rewriting KMail from ground up
    is the
    only solution we have to keep up with Thunderbird, or
    Evolution.

    Well I'm sorry to hear this.

    The code base has grown over years and too less time was invested
    in refactoring, so in the current state as soon as you touch one
    piece of code a side effect may appear somewhere else without
    noticing it.

    Do you have some examples? I would like to look into the code to get
    a sense for this problem.

    course it is possible to do the refactoring, but it takes a lot
    more
    time (since you have to figure out _all_ code pathes inside kmail)
    than
    rewriting it

    Thanks for the warning :)

    There are a few discussions and summaries to be found in the archives of
    this list, and the kmail-devel one. I'll try to dig something up and
    give you some more detail hopefully this weekend. I'm in the middle of
    moving house to Berlin, atm, so things are hectic.

    Cheers,

    Till

    kde-pim mailing list
    kde-pim (AT) kde (DOT) org

    kde-pim home page at http://pim.kde.org/
    PGP SIGNATURE
    Version: GnuPG v1.4.2 (GNU/Linux)

    0vYYXBfVIzrzWLI1v5rj6hc=
    =DI9R
    PGP SIGNATURE

Re: KMail policy regarding closing bugs


max 4000 letters.
Your nickname that display:
In order to stop the spam: 0 + 0 =
QUESTION ON "KDE"

EMSDN.COM