Bruce Dubbs wrote:
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
Jeremy Henty wrote:
Bruce Dubbs wrote:
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
Fernando de Oliveira wrote:
--- Em seg, 1/10/12, BLFS Trac escreveu:
Changes (by bdubbs@…):
* status: new = closed
* resolution: = wontfix
Comment:
I'm going to mark this as wontfix. IM manages to do a
sub-point
(major.minor.point-subpoint) release way too often.
It feels
On Mon, Oct 01, 2012 at 05:41:49PM -0500, Bruce Dubbs wrote:
Perhaps 6.7.10-0, and then only next point release?
Yes, 6.7.10.x, 6.7.11.x or 6.8.x.x, etc.
rant I'm getting a bit tired of some of these packages developers that
don't really understand software engineering. One major task
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
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
Ken Moffat wrote:
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
