Date: Fri, 30 Apr 1999 20:51:15 +0100 From: paul@originative.co.uk To: dfr@nlsystems.com, dillon@apollo.backplane.com Cc: peter@netplex.com.au, mreimer@vpop.net, freebsd-current@freebsd.org Subject: RE: solid NFS patch #6 avail for -current - need testers files) Message-ID: <A6D02246E1ABD2119F5200C0F0303D10FF1D@octopus>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Doug Rabson [mailto:dfr@nlsystems.com] > Sent: 21 April 1999 20:14 > To: Matthew Dillon > Cc: Peter Wemm; Matthew Reimer; freebsd-current@freebsd.org > Subject: Re: solid NFS patch #6 avail for -current - need > testers files) > > > I wonder if it would be too radical to suggest that the > release cycle for > 4.0 be *much* shorter than the 3.0 cycle. Maintaining two > branches gets > worse and worse as time goes on and it just becomes a waste > of programmer > time. If we are reasonably careful with the 4.0 tree, I think a 4.0 > release could be branched off it after 3.2 or maybe 3.3. > > It seems to me that merging a complex set of changes (such as > the VM fixes > or the new-bus work) from 4.0 to the 3.x branch would tend to > produce a > system which was less stable than the 'natural' environment for the > software which is being merged across. > I wonder if it would be too radical to suggest a third branch :-) I know of an increasing number of people who are not tracking -stable anymore because it's losing its reputation of stability. The main reason being that changes are pushed across from -current with little or no testing in -stable. I think -stable should have very conservative commit rules, only bug fixes, no feature creap. For the commercial users this is what they want, they're not interested in the newer features, they want what they already to have to work more reliably. There is however a more vocal group of people who chase features and they adhere to the rules and don't run -current to get them but increasingly their pressure has meant that -current features are hitting -stable very quickly. I think there should be three branches: 1) -current, usual rules apply, may toast your box at any moment, don't use unless you're prepared for such eventualities. 2) -beta, the place where new features migrate from -current when they seem to be working ok. Still potentially flakey but isn't expected to toast your machine. Users need to put up with problems but it should be an useable platform for a lot of people. It gets new features quickly. 3) -stable, only changes made to this branch are bug fixes, no new features added ever. I think -current has largely become -beta with the problem that when it does hit bad spots the "beta users" complain far too loudly than they really have the right to. The user base should be shifted as follows 1) -current has very few (relatively) users, only those developers who work on the OS (i.e. not ports) code. 2) The vast majority of people who run -current at the moment should really be running -beta. 3) -stable is for those who don't "track" FreeBSD. They upgrade only when a release takes place and not even at every release. These are mostly commercial users or home users who really aren't into the OS and just want a working box. In terms of workload I don't think it would have the major impact that people fear. Merges back to -stable should be *very* rare and so should not amount to any significant workload. Most of the merges we do to -stable at the moment should really be done to -beta so the workload there would be the same. Possibly even more radical than a third branch.... Change the -current list into -beta and form a new -current list that requires signing (figuratively not literally) an agreement that you accept -current may seriously hose you. Only allow people who have agreed these terms to post to the list, it would still be open for everyone to follow. This should reduce the number of whining messages on the development list from people who shouldn't really be running the development branch. Paul Richards Originative Solutions Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6D02246E1ABD2119F5200C0F0303D10FF1D>