On Mon, Oct 01, 2012 at 08:38:48PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > > Release early, release often. For major projects, weekly -rc > > releases, and stable point releases as-necessary, is a good thing. > > The release early, release often approach can be overdone. How is a > typical user supposed to know when a change is significant? I have no > problems with labeling a package as an intermediate point, but a > 'release' is normally assumed to be fully stable unless otherwise noted, > and once a week is just too much. Why bother to use a version control > system? > Thinking particularly of the kernel, a lot can change in a week during the -rc stage. Mostly, for the better. The fixes that also apply to previous _releases_ also get into stable after they have been in Linus' tree.
For many packages, you can read the release notes - for the kernel, there is usually something out there listing the major details, even if the git log is a bit impenetrable. Anyway, if there is a bad commit it can be reverted or otherwise fixed once discovered - that's what version control permits. But I disagree that any release is "fully stable" - usually, it just means that nobody has found bugs that the developers/maintainer think are important enough to delay a release. All software has bugs, many lie undiscovered for years. In applications, many other bugs hang around, sometimes for years, because the developers don't use linux. > I've wondered, in the case of the kernel, whether is would be beneficial > to release the drivers as a separate tarball on a different release > schedule. I think that's where most of the changes occur. In an > uncompressed kernel tarball, the drivers are 260M of 532M total. > Drivers change for two reasons : fixes, and changes in the rest of the kernel - the interfaces are not stable (I nearly wrote API, but drivers aren't an application). Either way, a few people use Linus' git tree for testing - a few more more people test the -rc versions when it looks as if they might be stable enough to reduce the pain (e.g. -rc3 or -rc4). Anyway, modern disks are big :) > > I don't follow systemd, no doubt some of the changes are important > > for the project, but without monitoring it I can't guess which, if > > any, impact the udev part. I'm still hoping that standalone udev > > will gain traction. > > That would require a major attitude change from the developers. IMO > they have a vested emotional interest in not separating udev. > I meant the fork created by gentoo users. I'm encouraged to see that they seem to be picking up the useful things from "upstream". ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
