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

List:       kde-pim
Subject:    Re: [Kde-pim] Commit policy for kdepim HEAD
From:       Mark Bucciarelli <mark () easymailings ! com>
Date:       2004-08-23 14:42:29
Message-ID: 200408231442.29891.mark () easymailings ! com
[Download RAW message or body]

On Tuesday 17 August 2004 21:10, Zack Rusin wrote:
> On Tuesday 17 August 2004 16:59, Cornelius Schumacher wrote:
> > Zack, it's you who missed the point. As there is no stable kdepim
> > release after 3.2, using HEAD is equivalent to using latest stable
> > kdepim with all the new features.
>
> No, that's not the point in question here. I was all about having a
> seperate kdepim 3.3 release because the one in kde 3.2 wasn't ready.
> Now I want hard evidence that it's actually necessary for anything.
>
> So far no one gave one good reason why it would be required. In fact
> scrap the "required", give me a clue as why you think it would be a
> good idea at all.

In some ways, this is a moot discussion--after all, despite best 
intentions, pim 3.3 was not released before kde 3.3.

But I can see four reasons for keeping the option open:

(1) Pim is changing fast, and it is missing some major stuff--Jan Pascal's 
(sp?) exchange resource is one example.  The proko2 stuff is another 
example.  The Novell stuff may be another one.  I expect pim will keep 
changing faster.  Packagers will appreciate simpler packaging.

(2) There is more risk in upgrading libs+base+pim than pim alone.  Bugs are 
a some function of the number of lines of code changed.  You cannot 
guarantee that a libs + base upgrade will not break something.  If you 
have a lot of people relying on KDE to get their work done, this risk (or 
percieved risk, if you prefer) is important.

(3) Other than one mention of kConfigXT, I've not seen any description of 
what benefits accrue to pim from upgrading libs + base.  Or why these 
benefits would compell an existing or potential KDE user to risk upgrading 
everything.

(4) It is easier to hack when I don't have to rebuild KDE libs and base.  
This may attract more developers.  For example, I know a karm user was 
able to experiment with building debian unstable packages for pim head b/c 
of the 3.2 compatibility.

(5) Other than minor details like a more complicated versioning, how does a 
seperate pim release hurt base and libs?

Regards,

Mark
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]