[Kroupware] kroupware - kde 3.2 ??

[Bo Thorsen]

On Tuesday 05 November 2002 15:37, Zack Rusin wrote:
> On Tuesday 05 November 2002 02:00, Matthias Kalle Dalheimer wrote:
> > > Kalle: Can you please comment on your intentions with regards to
> > > merging?
> >
> > Now that the situation has changed, I would suggest that we merge
> > right after KDE 3.1 is released.
>
> Technically merges will be pretty straight-forward because we do keep
> most of the branches in sync. What does worry me a lot is the coming
> KMail merge mainly because when we were discussing it, all KMail
> developers wanted to go with the make_it_cool approach of integrating
> with KOrganizer (KMail as KPart, integration via outside shell like
> Kaplan). Now it looks like we'll be merging kroupware in the HEAD with
> things we never wanted. So I guess, I just wanted to know what is the
> census on that and whether (believe me my hands are shaking as I'm
> writing this) should some changes from make_it_cool be merged into
> kroupware before the merge with the HEAD.

We are currently discussing this. We know that the kroupware approach=20
isn't the one that will be there when the smoke clears, so the question=20
is only what will happen while merging and while we must still keep the=20
deadline.

So far we have come to the conclusion that as much as possible will be=20
merged right after HEAD opens again. Then kroupware_branch will hold the=20
korg-in-kmail code only (hopefully) since this is probably the only thing=
=20
not acceptable.

Most of the other kroupware stuff is not coupled directly to kmail so thi=
s=20
should be readily mergeable with the Kaplan approach.

The one task we have in kroupware now is stability - we need production=20
quality. And it will most likely be too high a risk to merge what we have=
=20
and then switch to Kaplan now. As long as Kaplan requires make_it_cool=20
stuff, this part will definately not be done.

BTW, the reason we chose the present approach over kaplans was that we=20
knew we could do this. Kaplans approach was much harder to find out if it=
=20
could be made to work within the short time frame we had since it=20
required larger fundamental changes. I think all of us kroupware people=20
actually agree that Kaplan looks and feels more natural.

Bo.

--=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark