[nSLUG] Jigdo File
dteed at artistic.ca
Wed Mar 5 13:30:37 AST 2003
On Wed, 5 Mar 2003, Ben Armstrong wrote:
> Readjust your set. It does not mean broken. This is a misconception
> perpetuated by dozens of whipped-together projects that appear on freshmeat
> and elsewhere that really never should have been made public in the first
> place. The version# of these projects is irrelevant. Some of these
> projects may well be >1.0 because the developers have their own equally
> private meaning for what "1.0" is (most often "this is the first release of
> my software") The common theme is that the developers didn't give any
> thought to proper testing, debugging and QA before they went public. To me,
> a release isn't a release until the software is useful at least to some
> subset of users.
No, < 1.0 = beta it is a conception formed from using Beta versions
of many packages, including Netscape circa 1994, Internet Explorer
when it was still known as Spyglass, NCSA Mosaic, and more recently
with open source tools.
I don't spend any time at freshmeat - my open source beta
experiences are almost purely from packages provided with stable
releases of Linux.
I don't know where this "private meaning" is coming from. What I'm
talking about with version numbers is common practise in all
commercial software vendor releases. I can't think of one
for-profit company that sells software at less than 1.0 (well,
at least they would chase any early sales with updates/patches).
There are some packages that seem to never reach 1.0, and in those
cases I'd say the developer may have goals that are beyond reach, or
they just don't want to take on the responsibility.
> > We need some consistancy, and I don't
> > believe this has to be different for open source than for commercial.
> Shaky limb. You asserted "version# less than 1.0 means ..." and then
> explained your own private meaning, not one commonly accepted by everyone.
> You say here "traditionally means beta". Sorry, it may be a commercial
> software "tradition" but it's also a commercial software "tradition" to
> overinflate version#s and release buggy crap to the world as a "final
> release" before it's really ready. Why not be honest instead? "We need
No one has a specialty in releasing buggy software. It is everywhere,
no matter what the political stripes. The reasons why it is
released in that state are different, but the buggy packages
are everywhere - open source and commercial.
There is little point to this type of "honesty" when we are forced
to use a package in early adoption as with the case of jigdo or
in the case of mod_perl 1.99 and Apache 2.0 provided in Redhat 8.0.
I'd rather have the option to download the full ISO than be forced
to find Woody via the busted jigdo.
> some consistency?" Bah. Who is "we"? When I volunteer to develop free
"We" is the entire community of open source software users. If the
users don't exist, the developers might as well be playing Starcraft.
"We" depend on reliable software to get through our day and not come out
looking like fools to our bosses who gave us the option to use whatever
toolset we thought was most productive. When I fought with jigdo
for a couple of hours, that wasn't productive. Perhaps this is
something that needs to be remembered. Linux isn't just about
your home computer giving the boot to Windows. It is used
in business, and in that context the priorities can be different
and assert a different set of values.
I don't want to be forced into using something with poor
reliablity, and that is what happened in the case of jigdo.
Perhaps the version numbers mean nothing in betaness in the open source
community. Perhaps that is how something as unreliable as jigdo
became a mandatory application for Debian ISO retreival.
Perhaps the open source developer community (including commercial
vendors like Redhat) need to rethink how beta software is deployed.
More information about the nSLUG