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 k
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
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
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
>
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
pr
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.
>
> I'm getting a bit tired of some of these packages developers that
> don't really understand software engineering. One major tas
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
