Lukas Oboril wrote: > Hi > > On Mon, Jun 23, 2008 at 9:35 AM, Adriaan de Groot <groot at kde.org> wrote: > >> 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 >> > S10U5 at first and there should be SVR4 packages. > *recent* Nevada - it is pretty hard to say and do it, because Nevada > moving is pretty fast. > > I thinks that S10Ux should be a base and whole dude stuff should be > defined up on state of S10Ux, because lots of things is > missing on S10 instead of *recent* builds of Nevada. We can simply > eliminate stuff in Makefile, which we would to build on Nevada or not. > Nevada will on the edge everytime, because it is devel branch. S10 is > stable branch and it's a bit easier (thanks to Stefan) building on S10 > then Nevada. > > This is typical mail or IRC: Hi, this is not working on Nevada XY.... > hmmm in my build XZ works. Hmmm where it is wrong. Neverending looking > for changes between Nevada's builds what's change. It takes a lot of > time... :) > > > > >> - SPARCv9 or amd64 hardware >> > +1 > > >> - kde trunk until kde 4.1 is branched off, then the branch >> - kdebase + pim + sdk >> >> > +1 > > >> 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 >> > +1 > >> - fast moving, fast updating, but also simple to push fixes upstream >> - basic desktop and productivity apps. Minimal required rock-solid >> components. >> >> > +1 > > >> 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. >> >> > +1 > > >>> 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. >> >> > +1 > > > L > > > > Agreed. Targeting SXDE (B70B) and Solaris 10 U5 for builds is best, buidlding on them as well. For SPARC and x86 of course. I'd recommend internal testing will be done on future Solaris U's, and every few B's of Nevada. Do not try and build or target 2008.x right now, it's incomplete and unstable to build for as far as I'm concerned. If you have the resources it's fine to try the binaries, perhaps building stop-gap dependencies where they fail on 2008.x but having 6 platforms to start with is a bit crazy. If you add 2008.11, SXDE 01/08, B92, then you're in for a world of hurt.
James
