On Monday 23 June 2008 01:53, Stefan Teleman wrote:
> Adriaan de Groot wrote:
> > Stefan, does CVSDude have TRAC or something similar that we could use?
>
> Yes it does, BUT:
OK. Could we use it to plan / prioritize / triage patches, new dependencies,
updates to old dependencies (for instance: upgrading exiv from 0.14 to 0.16
isn't actually needed until we want full koffice + krita filters, and so that
can be delayed; for instance, upgrading to cmake 2.6 isn't strictly needed
for kde 4.1 so it too can be delayed, but not too much)? Having something
like a roadmap would help.
> i am, as of right now, instituting a moratorium on patches not directly
> related to this project.
I hate to say it, but that kind of moratorium means we need to define "this
project" more closely. It's not written down on techbase or solaris.kde.org.
My own attempt at defining "this project" is:
- S10U5 or Nevada 70b or later Nevada release
- SPARCv9 or amd64 hardware
- kde trunk until kde 4.1 is branched off, then the branch
- kdebase + pim + sdk
The reasons for that set of definitions are:
- [stable OS release] + [developer releases]. There are other OSOL variants
but there seems to be an almost linux-like proliferation of flavors and
incompatibilities there.
- two supported hardware platforms, but only the new stuff
- fast moving, fast updating, but also simple to push fixes upstream
- basic desktop and productivity apps. Minimal required rock-solid components.
This already leaves us with four target platforms and five people (S,L,A,B,M)
to go after them. Pursuing another half dozen extra variants just doesn't
seem like a viable solution to me.
> the idea that this project (KDE4 Solaris) is going to morph into a "build
> system for every possible platform configuration" project is simply
> orthogonal to what this project is trying to achieve. we have already
> explained several times that this is not what we are trying to do here.
That's not to say that a BSfEPPC project wouldn't be useful *in general* for
OpenSolaris / Blastwave / Indiana, as we've got lots of useful Free Software
that could be built and installed elsewhere. CMake is useful outside of the
context of KDE, for instance. So's a good C++ library. So's ogg123.
> > As for -R, you wouldn't be the first pkg-config file to start emitting -R
> > so it seems good to me.
>
> we don't need this patch, we already pass -R${libdir} in $(LDFLAGS).
RIght; it's more of a "suppose someone else wants to build with capseo, then
*they* need -R" kind of thing than that we need it. I'm on the fence on this
one: in future we should be doing this to support other third-parties, but
right now .. I dunno. Probably we should be messing around as little as
possible with the dependencies so that those don't need to rebuilt much and
we can focus on KDE itself.
