Date: Tue, 13 Mar 2001 17:36:26 +0000 From: Paul "=?iso-8859-1?Q?Richards=F2?=" <paul@originative.co.uk> To: Kris Kennaway <kris@obsecurity.org> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_output.c Message-ID: <3AAE5A9A.341F634F@originative.co.uk> References: <20010312160321.B95497@mollari.cthul.hu> <200103130307.TAA41551@gndrsh.dnsmgr.net> <20010312193452.A2927@mollari.cthul.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > On Mon, Mar 12, 2001 at 07:07:26PM -0800, Rodney W. Grimes wrote: > > > On Mon, Mar 12, 2001 at 09:58:53AM -0800, Rodney W. Grimes wrote: > > > > > In message <200103112315.AAA79776@info.iet.unipi.it>, Luigi Rizzo writes: > > > > > >> It's been in since last October. I guess that noone's using dummynet in > > > > > >> -current at the moment. > > > > > > > > > > > >it is just another example that for some things the "commit to -current > > > > > >first, wait at least 3 days before MFC" is totally useless and if > > > > > >we want to have these things tested we need to commit them where > > > > > >they are used. > > > > > > > > > > The "wait at least 3 days" is for catching obious blunders. > > > > > > > > > > If you want testing in -stable, publish a patch for stable and > > > > > ask people to test it for you. > > > > > > > > Perhaps this should be stated as a requirement in the handbook? Drop > > > > the 3 days thing, it doesn't seem to be doing us any good anyway. > > > > > > Nah, that's a bad idea. As PHK states, waiting before merging to > > > -stable catches stupid bonehead mistakes, which happen too frequently > > > to ignore this. > > > > I suspect that a published and tested patch to -stable before an MFC > > would catch more ``bonehead mistakes'' than the 3 day wait does. > > Okay, now I'm confused as to what you're advocating. Certainly, > expecting people to manually apply and test patches for every MFC is > too much. Most changes are too small to warrant that, but still carry > a risk of breaking something obvious or non-obvious, that a brief > testing period would stand the chance of catching. The whole -stable thing is falling apart. We should accept that there are two quite diverse systems, in a similar way to say Apache has done things or Samba. With 200 and growing committers then there are a lot of people working outside the main OS, e.g. docs and ports that need a stable environment where applications level development can take place. That's probably what -stable has or is becoming, whereas -current is next generation stuff, like Apache 2.x and Samba-TNG, where no-one expects it to work and radical re-architecting is taking place. I think it'd be much better if -stable became the development branch, since as far as I'm concerned it's already too unstable for production use. I can't use -stable ports on my 4.0 live server because there have been too many architectural changes between 4.0 and 4.3. That's broken project management and is screwing customers who want to use FreeBSD in the "real world". All I wanted to do was install an amanda client to back it up and in order to achieve that basic task I'd have to upgrade the whole OS (or give up on ports but it's a major failing none the less). The 4.x branch of the development tree is supposed to be interoperable but significant development is taking place on it. This becomes a nightmare when you have a heterogenous network of 4.X machines, instead of them being at different patchlevels they're different OSs!! Migrating a product from 4.0 to 4.3 requires redevelopment which is ridiculous. If -stable becomes the development platform where new drivers are written, existing sub-systems are tweaked and application developers and documenters work then there's a reasonably stable but moving platform to work with. The longer term restructuring can then take place in -current, without any regard to backwards compatibility (necessarily anyway) and freedom to work without the pressure of keeping it functional on a day to day basis and also over a longer time frame if required. The last release before -stable then becomes the branch that is genuinely stable, occasional patches are made for it to fix bugs that absolutely do not cause any incompatibilities or risk instability through new functionality; this is where things are heading with security patches anyway. To all intents and purposes, that's where we're at now but we're not acknowledging that fact and organising ourselves accordingly. Paul Richards To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AAE5A9A.341F634F>