[Top] [All Lists]

fwd: Re: Project flow...

Subject: fwd: Re: Project flow...
From: Andreas Busse <>
Date: Tue, 21 Nov 1995 08:44:13 +0100
Hi all,

Paul Antoine sent me this directly (cause he can't post to the list).
Why actually?

Anyway, I believe this is of general interest again, so I hope
you don't mind, Paul, if I post my answer.

 > Hi Andy,
 > As you probably know from Stoned, I can read the list, but not post
 > which is *very* frustrating because I have been doing a *lot* of work
 > in the last couple of weeks on the DECStation port. I will therefore 
 > send this to you directly:
 > > Glad to see a substantial response to my concerns :-)
 > > So...
 > Well, I do worry, and I want Linux for MIPS to be a reality.
 > > With the current "project flow", if one can call it so, I doubt 
 > > that we can make any realistic estimations on what takes how much 
 > > time. Fact is that max. 10% of the people on the list do 90% of 
 > > the work, and IMHO not always the "right thing", myself included.
 > This is a very general project management problem: one of the key
 > roles in being a project manager of technical people is in setting
 > short-term goals, otherwise technical types tend to go off and
 > do what it most interesting to them.

Sure, I know. In my past life at Waldorf I always was on both sides,
on the technical and on the management side. With Linux/MIPS, I
rather find myself on the management side since I have little time
to spend in technical things. And even if, I prefer "better-than-
nothing" solutions over none at all. Those of us who are able to
take a look at commercial source trees (no names here :-)) will
agree that this code often looks ugly. But it seems to work!

 > > I actually gave up trying to manage the Linux/MIPS project because
 > > I didn't had the feeling that someone cares about what I say or
 > > not. Anyway, doesn't matter.
 > Well, I do!  But as Managing Director, I only sometimes get a little
 > time to work on this.
 > > But if I had to decide about further activities just as with a
 > > commercial project, I would say: It failed, forget about it.
 > The most important role that I thought was being fulfilled by
 > Ralf was that of 'master source tree co-ordinator'.  Linus has done
 > this for the rest of the tree - we need someone to do it for MIPS
 > until there is enough of the tree for Linus to take over.

Actually, this is the only point I'm not worrying about. Ralf did
a good job with maintaining the kernel source tree, although he 
also tends to super-optimized code.

 > > Fortunally this is no commercial project, but if everyone on the
 > > list would think about the project and his specific parts as if it 
 > > would be one, things might change. The general rule of thumb 
 > > shouldn't be "is it fun?" but "does it help?" to work on a specific
 > > part of Linux/MIPS. Otherwise it'll never become real fun :-(
 > This is very true.  I have been very frustrated with the stuff that has
 > been made available.  I have tried 5 or 6 times to get the 1.2.x tree
 > patched up with *no* failed patches to 1.2.11, but I cannot.  The
 > patches are bizarre, and simply won't patch one after the other
 > without considerable work.  

I can make a full 1.2.11.x archive available, if you like. Just
let me know.
 > This leads me to your next point, with
 > which I totally agree:
 > >  > At a first glance we need to consider:
 > >  > - availability of a robust crossdev env.
 > Which must be available in BINARY form - I don't want to have to 
 > recompile the compilers!

That's what I say :-)

 > >  > - the ubiquitous MILO in some reincarnation
 > >  > - support for console and disk
 > Both of the above also need the source code re-organisation I spoke
 > of in one of my mails.  I would do it, but I'm damned if I can get
 > a source tree that looks like the one Ralf etc. are working on, because
 > as I said above, the bloody patches don't work as I think they should
 > i.e. CLEANLY!
 > >  > - port of the basic utilities
 > Again, they need to be in binary form.

Also agreed. I don't want to play around with sources that I'm not
working on. It's just waste of time.

 > > It is, of course, very important that Ralf works on GCC. But I 
 > > really cannot understand why there's still no reliable binary 
 > > distribution. I don't think that one person should hack GCC and 
 > > another one puts it together. We've seen that with gcc-2.6.3 -- 
 > > the binary I've made had a bug resulting in a keyboard driver 
 > > problem. Nobody noticed that simply because everyone grabs the 
 > > source and builds his own compiler. Why???
 > I agree! Thanks for putting up the binary fo 2.6.3 - it saved me 
 > *lots* of time.
 > > Similar with Milo: Months ago I asked for patches since Milo
 > > is more than due for an update. What have I got? Nothing. 
 > Well to be fair, some people do have a lot to do in the 'outside'
 > world, but yes, a simple release of 'what you know', whether it
 > be source in alpha, or a bit of doco is *very* important to the
 > other people that might be working on it with you.  Matt Messier
 > refused to release any of his work until he'd got it going a
 > bit better.  I had time to work on it, he did not, and has not got
 > back to me, which meant that I had to go off on my own.  

You're perfectly right -- a lot of work has been done already. But
it wasn't coordinated so probably none of us can tell someone where
the project as a whole actually stands.

 > At least I can now boot using tftp!


 > > Console: Well, console works for me. It's slow, yes. But is this 
 > > a problem? Are there any critical applications that need a super-
 > > optimized console driver? 
 > NO!
 > > What should be fixed is the lowres problem on the Magnum. And
 > > if the fix increases speed, wonderful! But the problem is not that
 > > it is slow, or am I wrong?

Well, then. I don't want to repeat myself, but we really should be
a goal to fix problems before trying to optimize low-priority parts
of the project.

 > > Disk: Yeah, would be great if we had a scsi driver, at least for
 > > the Jazz family. Volunteers welcome! I would throw code and docs
 > > after him!
 > You did so much good work on the DMA - I thought you were close to
 > having the ethernet driver going, and that the SCSI would follow
 > shortly thereafter.  Most of the chips are the same as those on
 > the PC (even in the DECStation the ethernet is lance, and the SCSI
 > is NCR 59C94), so what's the problem with everyone working on this?

Well, the Jazz ethernet chip isn't a lance (it's a Sonic) but I
must admit that I should spend more time into the driver. Regarding
SCSI: I'm willing to help whereever necessary. The DMA stuff isn't
that complicated as one might think, so...

 > > Basic Tools: Guess we shouldn't even think about this before we 
 > > have a scsi driver. Or do we want to run everything from a 
 > > 16 Meg ramdisk? Heard about SoftRam for Windows?  We should
 > > port it to Linux/MIPS :-)
 > Network booting would get everyone's compile-link-load-test cycle
 > working faster, I would think.

You're right. As I already wrote, I claim to be responsible for the 
Ethernet driver and will try to finish it soon. However, for the moment
I prefer to make the project running again. Otherwise we won't need
the ethernet driver at all :-)

 > > Any comments?
 > I think you see that I agree with you totally.  I am very frustrated
 > with the DEC port, because there is too little documentation:
 >      How do I get a clean source tree?
 >      What is the structure of a DEC partition table?
 >      Why are there so few bloody comments in the source code?

You mean, in the kernel? I agree. Even for non-commercial code, it's
rather non-documented at all. It's always the same...

 > I have *lots* of alpha patches for R3000 support, but they are against
 > my 'broken' 1.2.11 source tree, and I was waiting for Ralf to release
 > the 'master' 1.3.xx source tree that we can work on, so I could integrate
 > my patches with that before releasing them, simply 'cos it's easier for
 > me to do it than someone else.

Are you sure? Again, you can have a complete and working 1.2.11.x
tree. Extract your patches and patch them in again.

 > My limited access to this mailing list makes it hard, but I have lots
 > to report 'cos I've spent about 40-50 hours on the DEC port in that 
 > last few weeks (it helped that my partner had University exams :-).
 > So - please don't give up, but let's appoint people in some key
 > roles, say:
 >      Ralf - maker of robust cross-dev tools
 >      Andy - keeper of the source tree
 >      Stoned - chief of Oily port
 >      Paul - chief of DEC port
 > etc.  What do you think?

Hmmm. I have a problem with being the keeper of the source trees.
If I could choose, I would split it like that:

        Ralf -  maintainer of kernel and compiler (WITH binaries, please!)
        Stoned - maintainer of Milo
        Paul - maintainer of the DEC port
        me - Device drivers and "general management"

What I'm missing is someone who takes care of documentation. We
have a web server at FNET, but the pages are probably totally out
of date. The way FNET works make it impossible for me to keep them
up to date since when the server was at Waldorf I was used to add 
a word or sentence here and there, sometimes many times a day. 

And what I'm still missing is a volunteer for the SNI box. This
new guy on the list (Michael Rausch), wouldn't he perfectly
suited for this? I mean, there are already so many people with
Jazz boxes, why one more?

Fact is that I was asked for more publicity -- YOU CAN HAVE IT!
But I WILL NOT sign this agreement with SNI as long I feel that 
it will finally produces trouble only!


Andreas Busse                      |
Soft N Hard GbR                    | Phone: +49 2636-970105
Im Hufen Boden 16, D-53498 Waldorf | Fax:   +49 2636-970106

<Prev in Thread] Current Thread [Next in Thread>