--nextPart8336994.fZuJuEOTM1
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 18 February 2005 06.43, Aaron J. Seigo wrote:
> On Thursday 17 February 2005 10:08, Stefan Teleman wrote:
> > which works on most platforms. my understanding is that for KDE 4, BC
> > with KDE 3 needs not be maintained. so, i am offering to fix the
> > things which don't happen to work on Solaris. but, there's also Linux
> > and FreeBSD. so, i was asking if, in case we run into a situation
> > where something works on Linux but not Solaris, or FreeBSD, or
> > vice-versa, could we work together to try to find a common solution,
> > rather than relying on separate source code patches. when necessary,
> > by abstracting the OS-dependent interfaces, for example. i do realize
>
> i think this has always been the desire and goal, we've just lacked people
> to act as intermediaries between some of these pools of downstream patches
> and the official KDE sources. if you're willing to do this for Solaris,
> then that would be awesome. all it takes is for someone on Solaris to post
> a patch saying "this makes it work, i'm not sure it breaks on other OSes"
> to get feedback, fixes.

You know, when we post patches for FreeBSD, it's usually a handful of the=20
usual suspects that will test them, if anyone does at all. We get much=20
quicker feedback by just committing them.  If it breaks Linux, someone is=20
pretty quick to tell us (not that we do so intentionally, any more than the=
=20
majority of developers go out of their way to break FreeBSD). =20

Additionally, there have been several cases of patches to make things work =
for=20
us actually fixing the same issue Solaris, or Tru64 or whatever, and vice=20
versa.  A lot of what we do is not so much 'make it go on FreeBSD' as 'make=
=20
it not Linux specific', and that helps everyone out long term.

So, a small plea: If you see these kind of patches and you are *not* using =
the=20
platform in question, it's still very useful to have them tested before the=
y=20
go into CVS.  Knowing what it doesn't break, is just as useful as knowing=20
what it does, maybe more so.

Stefan: I'm going to guess that like the changes we make, the majority of t=
hem=20
fall into a small handful of common fixes (for instance, adding headers tha=
t=20
are included implicitly on Linux, working around glibc'isms and libs like t=
he=20
gnu math libs, busted configure checks and dealing with hardcoded paths tha=
t=20
oughtn't be, and the occasional unbashifying of a script)  We (well, mostly=
=20
Adriaan) must have fixed pretty much the same timezone miscalculation bug=20
about 34 times over, sometimes multiple times in the same app as it is=20
rewritten and the previous error creeps back in.    I'd be very surprised i=
f=20
a whole lot of your patch set isn't the same handful of things, over and=20
over.

Maybe we should start writing the common cases and their fixes down somewhe=
re,=20
so we have a resource to point developers to if we find we're fixing the sa=
me=20
problems over and over.  Education does work, so does being visibly involve=
d,=20
and pushing things upstream as soon and as often as possible.

Regards,
=2D-=20
Lauri Watts
KDE Documentation: http://docs.kde.org
KDE on FreeBSD: http://freebsd.kde.org

--nextPart8336994.fZuJuEOTM1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)

iD8DBQBCFd2d/gUyA7PWnacRAi6pAJ9LMV/XO11iJjXeMxTpp59Kul5R4ACfXAbs
eKMxsC6YrSEnkrW3ToLGiHg=
=yKhq
-----END PGP SIGNATURE-----

--nextPart8336994.fZuJuEOTM1--