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 for 
> version control is for developers to put in changes and let things 
> percolate so QA or others in the development process can test things 
> out.  Making a release once a week and letting the community report 
> problems reflects poorly on the developers.
> 
> Other packages that seem to fall into the same trap are git, systemd, 
> and even the kernel.</rant>
> 
> There are major packages seem to do a lot better: glibc, gcc, xorg, kde, 
> gnome, apache, bind, binutils, util-linux, etc.  Unless there are major 
> security flaws, once every six months seems about right.
> 
 As someone who follows the kernel list (ok, often I just skim it),
I take the view that the kernel (and git, which gets its releases
reported on the kernel list) are doing things well.  In particular,
Greg is doing an excellent job for the current stable kernels - as
are the maintainers of the older stable kernels, although those
don't impact on what is in the LFS book.

 Release early, release often.  For major projects, weekly -rc
releases, and stable point releases as-necessary, is a good thing.

 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.

 Going back to ImageMagick, they seem to be stuck in decimal
numbering, and almost every change results in a new release.
With their current release numbering, it's pure guesswork whether
any particular version will be good - most are ok, and the
vulnerable ones get pulled, but in many ways it's just a rolling
release.

ĸ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

Reply via email to