Comments on: eglibc doesn’t believe in releases http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/ Wed, 21 Oct 2009 21:31:01 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: rektide http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-30 rektide Fri, 02 Oct 2009 17:37:29 +0000 http://mirell.org/?p=42#comment-30 Trunk is stable; its not a hard concept to grok. I use Boo, a python-inspired CLR language, and it has a similar model to eglibc, it sounds like. Boo occasionally kicks out releases, but everyone uses SVN, and reports issues against the SVN revision number. It should "just work" and if its not working, make sure to update, and see if its still not working. If you need to start some advanced destabilizing work, get a branch. Theres colossally large suite to test against regression, and if something does regress, write a suite for it and never deal with the problem again. I see nothing wrong with this notion of a live code-base. Trunk is stable; its not a hard concept to grok. I use Boo, a python-inspired CLR language, and it has a similar model to eglibc, it sounds like. Boo occasionally kicks out releases, but everyone uses SVN, and reports issues against the SVN revision number. It should “just work” and if its not working, make sure to update, and see if its still not working. If you need to start some advanced destabilizing work, get a branch. Theres colossally large suite to test against regression, and if something does regress, write a suite for it and never deal with the problem again. I see nothing wrong with this notion of a live code-base.

]]> By: website http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-29 website Fri, 02 Oct 2009 15:23:39 +0000 http://mirell.org/?p=42#comment-29 Thats true for any project that is sensibly managed and use care in choosing what to backport onto the stable branches. Thats true for any project that is sensibly managed and use care in choosing what to backport onto the stable branches.

]]> By: Mark Miller http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-28 Mark Miller Thu, 01 Oct 2009 21:51:06 +0000 http://mirell.org/?p=42#comment-28 Except they don't tag. They make branches for eglibc 2.8, 2.9, et cetera, but those are also moving targets. And the developers even recommend not focusing on a branch, merely on trunk, which is even more of a moving target. Except they don’t tag. They make branches for eglibc 2.8, 2.9, et cetera, but those are also moving targets. And the developers even recommend not focusing on a branch, merely on trunk, which is even more of a moving target.

]]> By: Coder http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-27 Coder Thu, 01 Oct 2009 21:49:33 +0000 http://mirell.org/?p=42#comment-27 If the EGLIBC commiters create a tag for each major release within SVN why is that not sufficient? You can then checkout that tag, and work with it. Yes you'll have to look somewhere to determine which is the latest tag [can't be that difficult] If the EGLIBC commiters create a tag for each major release within SVN why is that not sufficient? You can then checkout that tag, and work with it. Yes you’ll have to look somewhere to determine which is the latest tag [can't be that difficult]

]]> By: Mark http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-26 Mark Thu, 01 Oct 2009 21:35:33 +0000 http://mirell.org/?p=42#comment-26 Dont worry. They will ignore you. They will claim that their target audience is only distributions, never any single user. Been there, heard that. Moving on ... Dont worry. They will ignore you.

They will claim that their target audience is only distributions, never any single user.

Been there, heard that.

Moving on …

]]> By: Rob Landley http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-25 Rob Landley Thu, 01 Oct 2009 21:13:28 +0000 http://mirell.org/?p=42#comment-25 > They are not an end-user product I agree that paragraph is a useless statement. Since when is the stock_glibc_ an end-user product "useful to build on their own without the rest of the system"? By that argument, glibc itself shouldn't bother to have releases. (Once again, "my project is _special_!") Here's a follow-up to the duct tape programmer, by the way. One from the guy who wrote the book with the Zawinski interview Joel was replying to: http://gigamonkeys.com/blog/2009/09/28/a-tale-of-two-rewrites.html And one from Zawinski himself: http://jwz.livejournal.com/1096593.html > They are not an end-user product

I agree that paragraph is a useless statement. Since when is the stock_glibc_ an end-user product “useful to build on their own without the rest of the system”? By that argument, glibc itself shouldn’t bother to have releases. (Once again, “my project is _special_!”)

Here’s a follow-up to the duct tape programmer, by the way. One from the guy who wrote the book with the Zawinski interview Joel was replying to:

http://gigamonkeys.com/blog/2009/09/28/a-tale-of-two-rewrites.html

And one from Zawinski himself:
http://jwz.livejournal.com/1096593.html

]]> By: Mark Miller http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-24 Mark Miller Thu, 01 Oct 2009 17:44:54 +0000 http://mirell.org/?p=42#comment-24 Okay, end-users will report bugs initially upstream to the Debian/Ubuntu/Gentoo/et cetera distribution maintainers, who have to interface between Mr. Drepper/et al and their folks for glibc. But that's just insulating the problem. Debian or whichever distribution had to grab a random repository checkout, and basically fork it from the repository, and <strong>closely monitor</strong> both the mailing list and the repository. I'll agree, if I'm the glibc/gcc/et al maintainer for Debian, I probably should keep a fairly close eye on that, to an extent. But there is no easy markings of, "Okay, here's the next stable drop", at all. From the point of view of someone who was looking at adding eglibc support to a software project, which requires building from source, it's troublesome. I have to basically ask on the list, "What should I bother looking at as far as stable?" Because trying to cross-compile a C library is painful enough without having to deal with instable checkouts. Related, I still love Joel on Software's recent statement, <strong>Shipping is a feature. A really important feature. Your product must have it</strong>, from <a href="http://www.joelonsoftware.com/items/2009/09/23.html" rel="nofollow">The Duct Tape Programmer</a> Lastly, yes, the fact that it appears to be a random shot process to reproduce a tarball of the repository, is extremely disturbing. Okay, end-users will report bugs initially upstream to the Debian/Ubuntu/Gentoo/et cetera distribution maintainers, who have to interface between Mr. Drepper/et al and their folks for glibc.

But that’s just insulating the problem. Debian or whichever distribution had to grab a random repository checkout, and basically fork it from the repository, and closely monitor both the mailing list and the repository. I’ll agree, if I’m the glibc/gcc/et al maintainer for Debian, I probably should keep a fairly close eye on that, to an extent. But there is no easy markings of, “Okay, here’s the next stable drop”, at all.

From the point of view of someone who was looking at adding eglibc support to a software project, which requires building from source, it’s troublesome. I have to basically ask on the list, “What should I bother looking at as far as stable?” Because trying to cross-compile a C library is painful enough without having to deal with instable checkouts.

Related, I still love Joel on Software’s recent statement, Shipping is a feature. A really important feature. Your product must have it, from The Duct Tape Programmer

Lastly, yes, the fact that it appears to be a random shot process to reproduce a tarball of the repository, is extremely disturbing.

]]> By: Lucas http://mirell.org/2009/10/01/eglibc-doesnt-believe-in-releases/comment-page-1/#comment-23 Lucas Thu, 01 Oct 2009 17:34:09 +0000 http://mirell.org/?p=42#comment-23 I believe your comment about this "release" style making it hard to reproduce releases or identify versions is partly a red herring. It is a red herring, because end users will certainly have versions of the library. For example, the machine I'm using now has GNU libc version "2.9-25" installed. That is nonsense to the glibc hackers, but it is meaningful to Debian. I can report bugs against version "2.9-25" of glibc to my distro, and they will handle dealing with mapping that somehow to the upstream. OTOH, from your quote, it seems that there is no easy way to refer to a single source checkout, and that is disturbing. I mean, even with the Linux kernel, I can refer to a git commit ID. I believe your comment about this “release” style making it hard to reproduce releases or identify versions is partly a red herring.

It is a red herring, because end users will certainly have versions of the library. For example, the machine I’m using now has GNU libc version “2.9-25″ installed. That is nonsense to the glibc hackers, but it is meaningful to Debian. I can report bugs against version “2.9-25″ of glibc to my distro, and they will handle dealing with mapping that somehow to the upstream.

OTOH, from your quote, it seems that there is no easy way to refer to a single source checkout, and that is disturbing. I mean, even with the Linux kernel, I can refer to a git commit ID.

]]>