Subject: Re: Responsability (Was: autoconf at last)
From: Thomas Fletcher (thomasf@qnx.com)
Date: Wed Aug 02 2000 - 13:53:49 CDT
On Wed, 2 Aug 2000, Goran Thyni wrote:
> On Wed, Aug 02, 2000 at 08:34:31AM -0400, Thomas Fletcher wrote:
> > Now I hope that the autoconf that you have built is=20
> > flexible enough to be used for other platforms outside
> > of the unix tree.=20
>
> How would I know until people try it?
> It is build wth GNU autoconf/automake and should run
> all unix-like systems and CygWin.
>
> linux,bsd,solaris etc
> and qnx, beos, macos x, cygwin
>
> don't know about:
> macos 9, borland/ms IDEs
That wasn't the point of my question. My question is that
yes while autoconf will run on the plaforms you listed ...
beos and qnx both have separate branches than the "unix"
branch in the Abi tree. Does you patch only work with the
unix branches, or did you create autoconf/GNUMakefiles for
all of the "non-unix" platforms on which autoconf does
run. This is my question ... and what in turn sparked the
long comment about keeping the tree green.
> the goal of ease cross-platform maintainence and development.
> Until we have a stable autoconf build system we have to
> maintain the old system, but the befits are much greater
> then a temporary extra work, IMHO.
Ok fine, let's imagine that the autoconf build is stable.
What do we do about platforms where autoconf doesn't run?
Right now it is very feasible to bring AbiWord up on any
platform where you can get gnumake to run. Of course for
the MacOS < X stuff we didn't use gnumake but used the
Metrowerks project files (and also at one point there was
a Visual Studio build). So already we are having to maintain
the makefiles and the projects. I just want to be clear
about the fact that your intention is to install autoconf
makefiles to eventually get rid of the abi makefiles which
are currently in place. Is that right?
(I am only mildly leaning against autoconf, I'm sure I'll
be very pleased with the end result when it is all working).
> > If we were to really be living by the Tinderbox rules,
> > no one of the platforms would be able to have _any_
> > new features put in until we were green across the=20
> > board. This is the reason we have Tinderbox and the
> > reason we have a mailing list, and people who have
> > write access should take this commitment to keeping the
> > build clean very seriously (this isn't to accuse anyone
> > of not taking it seriously ... just a reminder to us all).
>
> <strong opinions ahead>
> =2E.. and stall the development into eternity.
>
> Breakage is *a good thing*.
> No progress =3D no breakage
>
> If this a the methology which should be used my short essay
> on advogato had even more truth to it then I thought when I=20
> wrote it.
I read your essay ... interesting reading, and I'm glad that
you decided to step up and take part in helping AbiWord
develop.
What I don't agree with is the fact that a mistake checked
into some cross platform code will cause my build to break,
meaning that my development on platform specific code can
no longer continue. In the meantime other people (who
perhaps haven't cvs up'ed) commit more code into the burning
tree. Their code may be just fine, but it means that now
I have to go and check not just the last checkin, but possibly
many different source updates to see why the f#*k I can't
get my build finished.
I'm not talking about stopping feature development, if you
add a new dialog and I'm too slow to code it up for QNX, well
it sucks to be me. I'm talking about writing good clean code
that works once it is checked into CVS. I don't want to
be updating from CVS and getting broken code in the
cross platform areas.
> * Let tinderbox go red, fix your platform to green.
> * When it is time for a release slow down new features
> and concentrate on clean-up/bug fixing.
> * Release it
> * Let's go feature crazy again, tinderbox go red.
Then using tinderbox for people adding/stubbing
features on other platforms (I'm on unix, I'll
stub the dialog on windows) becomes next to impossible
if you don't endeavour to keep the build gree.
> CVS-code should not have to be release quality code=20
> between code freezes. CVS code is for developers only.
> </strong opinions ahead>
No here we agree, but I strongly believe that shared
CVS repositories should ALWAYS compile. I keep a
personal CVS repository to save the things I'm in
flux on that aren't ready for prime time.
Thomas
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
This archive was generated by hypermail 2b25 : Wed Aug 02 2000 - 13:53:08 CDT