At Wednesday 07 November 2007 13:03, you wrote:
> Am Mittwoch 07 November 2007 schrieb Thomas Zander:
> > On Wednesday 07 November 2007 11:34:05 Sebastian Kügler wrote:
> > > On Wednesday 07 November 2007 09:51:50 Tom Albers wrote:
> > > > It's news to me too.
> > > >
> > > > I don't think this should be done this way. kdesupport follows kdelibs
> > > > release path.
> > > >
> > > > So they should not use trunk kdesupport to work on the next version. In
> > > > case they want to work on the next version, maybe they should move to
> > > > extragear/libs like any other application/library.
> > >
> > > We need to document that then (adding qca2 to the techbase build
> > > instructions then). If we switch to a released qca in this state, it'd
> > > also need some testing.
> >
> > Wasn't the original reason for kdesupport to put code there that was
> > required for building KDE?
> Somewhen in '98 - yes. But that doesn't mean the original reason for
> kdesupport is still the current one.
>
> And no, our policy is that we only put into kdesupport what is not available
> elsewhere.
I think that thanks to our releases up to now, all distro's have packaged
qca(2) now, that's why I proposed to move it to extragear now.
> > In light of that concept the stable version should stay in kdesupport. I
> > doubt Tom wanted to remove it from kdesupport.
Well, more or less. Either there is a stable - essential/required - version in
kdesupport and a development branch somewhere else or qca moves to
extragear/libs and releases tarballs reguallary which are the requirement for
kde.
What I would not like is a version of qca in kdesupport which *can not* or
should not be used to compile kdelibs (as seem to be the case now). kdesupport
should support kdelibs at any time, hence follow its release schedule.
Toma
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team
