Date: Sun, 17 Dec 1995 15:22:15 -0700 From: Nate Williams <nate@rocky.sri.MT.net> To: Julian Elischer <julian@jhome.DIALix.COM> Cc: current@FreeBSD.org Subject: Re: FreeBSD-current-stable ??? Message-ID: <199512172222.PAA21915@rocky.sri.MT.net> In-Reply-To: <199512171542.XAA02873@jhome.DIALix.COM> References: <Pine.BSF.3.91.951217083228.405C-100000@knobel.gun.de> <199512171542.XAA02873@jhome.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Generally I would be interested to help testing and debugging new > > FreeBSD-current features. But when reading the -current mailing list, > > FreeBSD-current, so to say FreeBSD-2.2 in it's early days, seems to be > > an instability nightmare. Perhaps this expression is a bit oversized, > > but please understand my point of view. > I do dissagree. -current is exceptionally stable for what it is... I *BEG* to differ. -Current is absolutely useless for me, and I'm running a system that it about as stock as it can get. This box ran 2.0.5 for weeks w/out problems, and I can't run for more than 5 minutes under -current. Now, if you consider that 'exceptionally stable', I guess we have some differences in how we communicate stability. > > I read in -current very often messages like, can't boot, can't compile, > > unreferenced symbols, ... and so on ... > > > Usually this is pilot error. It usually requires the user to compile more > or check their configuration..... I beg your pardon? I've been doing this for a *LONG* time (as long as most folks), and even now wearing the hat of 'release engineer' for SRI's internal BSD release. I *do* know what I'm doing and I can say that -current is completely and absolutely unusable for me. I *want* to run -current so I can help work out the bugs in it. I like the idea of -current for many reasons, two of them being: 1) It's the only fair place for new/radical changes to be integrated in 2) It gives these changes a chance to be tested However, the -current kernel tree has been broken for many people for over 6 weeks now. I remember folks complaining about getblk() hangs in early November, and I although it appears that they are fixed for some folks (and for unknown reasons), we have yet to see a version of -current since November that is has been compilable and usable for a majority of folks. I finally have given up on a -current kernel simply because my machine reboots with no panic messages or dumps if I don't have DDB installed, and hangs with DDB. I am now tracking -current only in those parts of user-land code which don't require 2.2 functionality. There have been few changes in the user-land stuff though. > Sometimes it's something due to the symbol space cleanup > going on, but I tyhink this is vastly overstated.. > the -current kernel is in a successfully compilabel state > 90% of the time.. from my commercial experience I'd say this is a > REMARKABLE achievement.. I don't mind it being a little bit broken, but when we have *serious* instability problems, it shouldn't be the goal of everyone to stuff in 'one more feature' which affects the entire system. There have been 4-5 major wide sweeping changes that affect the entire kernel sources since the tree was opened up, any one which can make the kernel unstable/un-compilable. I know for a fact that the kernel was unstable after the first couple additions, but that didn't stop folks from adding more to the tree, thus making it more difficult to track down the problem. > > Since I only have one PC and one harddisk, as many other people, > > it's not possible for me to switch to -current, because I need > > a certain level of stability. > > you should be able to do all your initial development with 2.1 Then -current has no purpose. I'll bet the number of folks who actually run -current are less than 20. This means that -current serves no purpose which couldn't be served by sending patches to one another, since the audience is extremely small. > You can also have two kernel trees (for example) and compile and run > 2.2 kernels froma 2.1 tree.. ... > you will have to compile 2.2 versions of some utilities (ps etc) > but it's quite doable.. I do it here It doesn't work very well at all. It *sort of* works, but you're not testing anything new, since all the new interesting stuff in the user-land requires a -current kernel. All the non-interesting stuff doesn't need to be tested or was tested well before it was integrated. :) > > When speaking with people like Martin Cracauer, then I get > > the impression, that possibly more people would be interested > > to help in FreeBSD developement. Perhaps developing additional > > features, too. But they only have one machine, which shouldn't > > get into a very unstable state. > > you don't need to totally upgrade.. > you can.. > 1/ do development on 2.1 You can't do kernel development on 2.1 since the kernel has changed radically in -current. > 2/ make a chroot tree, filled with 2.2 binaries Which works for all the non-important user-land stuff. > 3/ use the 2.1 reee with a 2.2 kernel for testing > -current is by definition kinda unstable.. it's a feature, not a problem.. I agree that -current can be uncompilable for short times, and unstable for short times, but 6 weeks is way too long. There are *bugs* in the kernel which were known about 6 weeks ago which still haven't been addressed, but 'progress' has gone out without progress being made. > > If there is a brand new driver with a risk of crashing the systemm > > it should be added and tested there. > No the code that is SO green that it cashes the systems should be tested in > people's private trees.. Obviously this hasn't been done. When reports of crashes come in, the developers attitude has been 'it works for me, I'm going to assume it's pilot error', rather than 'here is how you can work with me to find the problem'. Not to single you out alone, but your 'JREMOD' changes were announced one day, installed into the tree the next day, and then you complained that folks weren't giving you feedback less than 48 hours after they were put in. First of all, the tree was unstable *before* the changes went in, so folks weren't running -current until those were fixed. Then, those folks that were supposed to quickly get the new sources, compile up new kernels, and test them out in less than 48 hours and give you valid feedback? I don't think that's fair to either the developers or the users. Now, this *is* a volunteer project and everyone is free to do what they wish, but that doesn't give folks cause to put in their 'pet project' into the tree no matter what state the tree is in. > > If the new driver doesn't cause crashes or such it shoud move to > > FreeBSD-current, to introduce it to a larger audience that is > > willed to test the bleeding edge. > i.e just like now.. I doubt we have the number of folks running -current that we had for the 1.X releases. I doubt we have the number of folks running -current that we had since the 2.0 release. > I run -current... > I don't have problems.. > if it aint broke don't fix it.. That's the attitude I'm seeing. "If I don't see any problems, there must not be any problems." Is this the same Julian Elischer who complained for months that 'FreeBSD must have a problem since the same hardware runs OSF fine and crashes repeatedly under FreeBSD'? How come it's fine to act this way when it doesn't affect you directly, but it's not when it affects you? > what we have now is working fine... > if you can't cope with the TINY hickups happenning I don't consider these TINY anymore. I can see the tree being broken for weeks, but *IF* it's broken then the free for all that's happened in the tree shouldn't occur. Kernel folks, the kernel is broken w/regard to a large number of folks who try to run it. I think we have a number of folks who are willing to work with you to make it better, but there isn't any co-operation from you. We need your help to make it better, and telling folks "it works for me, it must be something you've done" is only making the problem worse. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512172222.PAA21915>