I've spent some time compiling this for an off-list reply; seems a waste
to only send it to one person.
Don't be offended; look at what I say - it's not all rubbish - and apply
the bits that are useful. I do not wish to get into a lengthy debate about
it.
If you feel you MUST reply, sit on it for a day & then read it again.
> On Tue, 29 Feb 2000, John Summerfield wrote:
>
> > > On Mon, 28 Feb 2000, John Summerfield wrote:
> > >
> > > >
> > > > Come on chaps: this is three in a row. I'd like to think authors do SOM
> E
> > > > testing before submitting code. I don't see any obvious explanation for
>
> > > > code regularly not compiling;-((
> > > >
> > >
> > > It's called patching. Linus et al receive a variety of patches from many
> > > different sources, and they have to integrate them which is often no easy
> > > job. The individual patches compile fine but in combination an error
> > > creeps in. Obvious enough an explanation for you ?
> >
> > Sure. The previous one had #ifdev when #ifdef was intended. That could
> > have compiled in nobody's hands.
> >
>
> Yes, OK, there are also small parts which aren't actually compiled ... so
> what ? I think you're able to fix #ifdev aren't you ? The whole purpose of
Had the AUTHOR compiled the code, it would have been fixed before being
committed to the cvs repository.
> making the dev kernels available is to fix stuff like this ... they're not
> "technology previews", they're *under development*. Currently 2.3 is still
> slower than 2.2 as it needs balancing ... are you going to complain about
> that as well ?
>
> Or would you rather Linus spent half of the day compiling the kernel
> instead of actually working on it ?
Doesn't have to be Linus. There should be a project administrator who does
just that. Not half of every day, but sufficient for each release.
It is sensible indeed to compile a few standard configurations, ideally to
test recent changes, before publishing tarballs. The whole exercise could
be scripted and only send yea or nay messages to Linus.
It takes under 30 minutes to my P133 system to build a 2.3.45 kernel. I
don't think it would be hard to meke even this modest beast collect the
latest CVS code from wherever, compile a few configurations and, if clean,
create the patch file and tarball for the next release.
Ideally, there would be some basic functionality test, but I CAN see that
scripting this for the kernel has some special problems.
Consider how the cost of a programming error increases as it ages. I don't
know just how the LK development is managed, but I have worked on IBM
software.
A programmer makes an error,
the compiler spits it out. Cost - a few minutes at worst.
It's a logic error & the programmer has to think about it. A few minutes
to a few hours.
The programmer does not notice and it goes to the testers. It involves
several people (at least one tester and the developer) It likely takes a
day or more to fix.
The error gets past testing & QA does its thing. Errors found at this
time have to go through all the preceding steps again, and there may be
documentation changes and translations to be redone. At this time a
commercial organisation will consider letting the error ship. Errors here
cost days of work by several individuals.
The worst happens and the bug ships. It costs (prospectively) lots of
customers wasted time and money discovering, enduring and reporting the
error. I recall a few years ago, a major Australian bank lots its ATM
network for two days or so because it installed a new release of IMS,
IBM's premier DBMS at the time, and it broke under load. Backing out was
not an option, and neither could they have detected the problem before the
upgrade; be sure they DID - they had computers including IBM's biggest
dedicated to the task.
Now here we have errors that would be picked up by the most cursory test
getting out. It should never happen. This means that errors that should be
picked up by the programmer are going to the test team - those of us
foolish/brave enough to try to run it.
In the case of the compilation errors I find, they're likely to have been
published over 24 hours before I get to them; I check for patches once a
day, from a mirror. If I find an error immediately, it doesn't go out
until almost 24 hours after I got the duff code.
Assuming I'm competent to sort it out (by and large I'm not), it can be 48
hours before any fix I concoct could get to where they'll be useful, AND I
have to undo my changes before I apply the next set of patches.
When I worked on IBM software, it sometimes arose that two of us wanted to
change the same source file at the same time. By discussion, we arrived at
one of several arrangements;
1 One of us made but sets of changes
2 First in, best dressed. First completed changes asap, notified the other.
3 Second checked out w/o locking & made changes. Then checked out & locked
when possible and merged changes. It was the second person's
responsibility to ensure that the new changes didn't break anything, just
as if the first set had been there all along.
In all cases, code was expected to compile & run when checked in.
-- Cheers John Summerfield http://os2.ami.com.au/os2/ for OS/2 support. Configuration, networking, combined IBM ftpsites index.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:11 EST