Moving pop, imap and smtp koslaves from kdebase to kdepim

[Andy Fawcett]

On Sunday 04 January 2004 17:48, David Faure wrote:
> On Sunday 04 January 2004 16:41, Stephan Kulow wrote:
> > Am Sonntag 04 Januar 2004 16:32 schrieb Ingo Klöcker:
> > > And of course the slaves will always be backwards compatible. We
> > > just want to have the option to improve the slaves for KDE PIM
> > > 3.3 in case that should be necessary.
> >
> > Ah - misunderstanding from my side. I thought you were talking
> > about 3.2.
>
> He is / we are.
> kdepim-3.3 will come before kdelibs-3.3 (see kde-pim mailing-list),
> so this is indeed about moving them before kde-3.2.

Because of the way some distros/OSes package KDE, moving thse now will 
cause non-trivial changes for the packagers.

Not all distributions break down the modules during packaging (I'm not 
going to get into a Bikeshed discussion about the rights or wrongs of 
that, Lauri covered it quite well in the "Let's make standalone Kopete 
releases" thread a month ago).

If the smtp kioslave is moved we (all packagers who don't break down the 
modules into subcomponents) would have to make kdemultimedia dependent 
on kdepim. Obviously this wouldn't be very acceptable.

> Why too late? because of translations? packaging?

I would guess both.

Having read the proposed kdepim schedule, my personal feeling is that we 
would all be better off if the PIM changes are done in a branch (you're 
already doing that I see), and that once the changes are deemed to be 
stable enough that you get the RD/docs/i18n's permission for a "one 
time only" merge back into the main branch for 3.2.

This would avoid moving code between modules (and by implication no need 
to move docs/translations), would avoid packaging changes, and would 
also prevent confusion over version numbering with regard to kdepim.

It wouldn't cause any extra work for the kdepim developers, the only 
thing it would do is require some work from docs/i18n teams to update 
for your changes.

Note: this is my opinion, and not that of the packaging team I work 
with, nor of the RD, Docs, or i18n teams. Merely a suggested 
alternative.

A.

-- 
Andy Fawcett                                     | andy at athame.co.uk
                                                 | tap at kde.org
"In an open world without walls and fences,      | tap at lspace.org
  we wouldn't need Windows and Gates."  -- anon  | tap at fruitsalad.org