Discussion:
Debian versioning scheme (r1 vs .1)
(too old to reply)
Morten Brix Pedersen
2002-11-04 18:05:09 UTC
Permalink
Hi list,

This is not meant to be flamebait, but simply something I was thinking
about after reading Joey Hess post to debian-devel-announce regarding
Debian woody 3.0r1.

I am wondering why updates to the Debian GNU/Linux distribution uses the
much alternative versioning syntax, such as 2.2r7, 3.0r1 etc.

In my opinion, 3.0.1 is a much clearer and more commonly used syntax.

..or is it just me who thinks the latter is much nicer?

- Morten.
Federico Di Gregorio
2002-11-04 18:11:19 UTC
Permalink
Post by Morten Brix Pedersen
Hi list,
This is not meant to be flamebait, but simply something I was thinking
about after reading Joey Hess post to debian-devel-announce regarding
Debian woody 3.0r1.
I am wondering why updates to the Debian GNU/Linux distribution uses the
much alternative versioning syntax, such as 2.2r7, 3.0r1 etc.
In my opinion, 3.0.1 is a much clearer and more commonly used syntax.
.or is it just me who thinks the latter is much nicer?
go search the archives.
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact ***@debian.org
INIT.D Developer ***@initd.org
We are all dust, Saqi, so play the lute
We are all wind, Saqi, so bring wine. -- Omar Khayam
Clint Adams
2002-11-04 18:14:31 UTC
Permalink
Post by Morten Brix Pedersen
I am wondering why updates to the Debian GNU/Linux distribution uses the
much alternative versioning syntax, such as 2.2r7, 3.0r1 etc.
CD vendors felt that the #.#r# syntax benefitted them more, and some
people in the project thought it would be nice to accommodate them.
Post by Morten Brix Pedersen
..or is it just me who thinks the latter is much nicer?
No, not just you.
Noah L. Meyerhans
2002-11-04 18:17:01 UTC
Permalink
Post by Morten Brix Pedersen
I am wondering why updates to the Debian GNU/Linux distribution uses the
much alternative versioning syntax, such as 2.2r7, 3.0r1 etc.
In my opinion, 3.0.1 is a much clearer and more commonly used syntax.
Version numbers are arbitrary and meaningless. It is simply a
designation, and we happen to have a standard for ours. Perhaps it's
good that we're not using a commonly used syntax, because although the
syntax may be common, the meaning may not be.
Post by Morten Brix Pedersen
..or is it just me who thinks the latter is much nicer?
Everybody has their own opinion. Personally, I don't mind the r*
system, but I'd like to do away with "point" releases. I think we
should have Debian version 1, version 2, 3, 4, etc. When you only
come up with a new release once a year at best, all releases are "major"
releases. The change from Debian 2.1 to 2.2 was just as major as from
2.2 to 3.0.

In a sense, nobody in Debian actually cares about the version numbers at
all anyway (at least not as I've described them) since we just call
releases by their codenames anyway. Using codenames is essentially the
same thing as what I'd like to see with version numbers. Every time a
new major release comes out, it gets a new code name. I think it'd be
more consistant if we gave it a completely new version number as well,
but I don't care enough to push for this change.

noah
--
_______________________________________________________
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html
martin f krafft
2002-11-04 19:15:38 UTC
Permalink
Post by Noah L. Meyerhans
Everybody has their own opinion. Personally, I don't mind the r*
system, but I'd like to do away with "point" releases. I think we
should have Debian version 1, version 2, 3, 4, etc. When you only
come up with a new release once a year at best, all releases are "major"
releases. The change from Debian 2.1 to 2.2 was just as major as from
2.2 to 3.0.
I think if Debian releases 4.0 after 3.0r6 or whatever, then we will
lose credibility (think: there was never an ms office x.y with x >=
6 and y > 0), and we've never used the 0 after the dot. So either we
go to

Debian III r1

or

Debian 3.1 (instead of r1)

or we use 3.0r? for now and call the next release

Debian 3.1r?

I kind of prefer the last, it also requires no immediate change, just
some consideration when we'll release the next.

Uh, you know that January is coming up and we are on a biannual
schedule, right? Can we release in January, please?

Lastly, I agree with Noah: I don't care about what the version is that
I am running, as long as it's reasonable current and Debian...
--
.''`. martin f. krafft <***@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Michael Banck
2002-11-05 19:53:04 UTC
Permalink
Post by martin f krafft
Debian III r1
or
Debian 3.1 (instead of r1)
or we use 3.0r? for now and call the next release
Debian 3.1r?
I guess it's the RM's toss or somebodies. I couldn't care less.
Post by martin f krafft
Uh, you know that January is coming up and we are on a biannual
schedule, right? Can we release in January, please?
Fix/Implement debian-installer for that.

Michael
Joel Baker
2002-11-04 22:09:38 UTC
Permalink
Post by martin f krafft
Uh, you know that January is coming up and we are on a biannual
schedule, right? Can we release in January, please?
*snort* *giggle* *breaks down in gales of laughter*

Biannual? By last report, it was more like bienneal, and not looking to
change any time in the forseeable future. If you want an actual release
schedule, Debian is far from the place to be looking.

For what it's worth, I must grant that point releases have occured with
reasonable regularity, and do at least a little to help the situation
(though the whole "no new features" thing mitigates the usefulness of it in
alleviating the pain of running stable - but then, that isn't really the
philosophy in use by those currently doing them, so this isn't suprising,
and is not necessarily a bad thing).

There have been a lot of proposals on "fixing" this, including at least
one that I wrote. But they all boil down to one simple problem:

Many people do not want to change "we'll release it when it's ready" to
"we'll release what is ready".

Unless and until that is changed (and it's a matter of opinion, really,
and philosophy, meaning you can't really ever settle the argument, so
a GR isn't likely to do much except waste people's time), Debian will
continue on it's current path. The only person who really has the authority
to decide that, short of a GR, seems to be the RM. Whose philosophy has
been expounded, and does not seem likely to be changed if it hasn't been
already.

Personally, I'd love to *not* have NetBSD support in Sarge - *if* that
happens because Sarge comes out in a sane timeframe, and NetBSD simply
hasn't gotton things hashed out by that point.

Currently, it's looking like we'll have quite a bit of time, at the
current rate, to get it ready for the next release. I would call this a
silver-plated lead lining.

(And, FWIW, I asked one of the d-i folks what could be usefully done with a
week or two to spare, that was *not* NetBSD related, since I value timely
releases more than what toy name we happen to be using for the release that
postdates NetBSD being ready; while I do work on it, the answer seemed to
indicate that it's currently in a "nine women cannot make a baby in one
month" state...)
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
***@lightbearer.com http://users.lightbearer.com/lucifer/
martin f krafft
2002-11-05 00:15:19 UTC
Permalink
Post by Joel Baker
Post by martin f krafft
Uh, you know that January is coming up and we are on a biannual
schedule, right? Can we release in January, please?
*snort* *giggle* *breaks down in gales of laughter*
Biannual? By last report, it was more like bienneal, and not looking to
change any time in the forseeable future. If you want an actual release
schedule, Debian is far from the place to be looking.
The thing about Debian is that it's what we make of it. Period. So if
we want that, we can do it.
Post by Joel Baker
Many people do not want to change "we'll release it when it's ready" to
"we'll release what is ready".
Define 'ready'?

I am quite aware of the Debian philosophy, and it's the reason I am
here and actively engaged with the project. But I don't see any reason
why there can't be a freeze state of testing every couple of months,
bugs worked away, and a new release put out. That's really what the
three stage system is designed for.

Whatever, flame to /dev/null please. I am just saying how Debian could
be made better (and expressing my willingness to help, as always...)
--
.''`. martin f. krafft <***@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Joel Baker
2002-11-05 00:37:14 UTC
Permalink
Post by martin f krafft
Post by Joel Baker
Post by martin f krafft
Uh, you know that January is coming up and we are on a biannual
schedule, right? Can we release in January, please?
*snort* *giggle* *breaks down in gales of laughter*
Biannual? By last report, it was more like bienneal, and not looking to
change any time in the forseeable future. If you want an actual release
schedule, Debian is far from the place to be looking.
The thing about Debian is that it's what we make of it. Period. So if
we want that, we can do it.
As I said in the part of the message you trimmed - getting sufficient
concensus to implement a GR saying that we want biannual releases is likely
to be nigh impossible.

And anything short of that won't fix it, because the only folks who have
control over it don't think it's broken.
Post by martin f krafft
Post by Joel Baker
Many people do not want to change "we'll release it when it's ready" to
"we'll release what is ready".
Define 'ready'?
Not my job. That's up to the RM. In fact, it's a large part of what the RM
does. For the current round of 'ready', see the last "Bits from the RM" on
d-d-a.
Post by martin f krafft
I am quite aware of the Debian philosophy, and it's the reason I am
here and actively engaged with the project. But I don't see any reason
why there can't be a freeze state of testing every couple of months,
bugs worked away, and a new release put out. That's really what the
three stage system is designed for.
I don't see any *fundamental* reason why we couldn't, either. If you read
the rest of the message, it should be clear, in fact, that I'd love to
see it happen. But the last estimate (which, as always, should never be
taken as gospel, and should probably be assumed to be conservative if past
history holds) was that 18 months *from now* could well be an *optomistic*
timeframe.

We have declared that we won't ever use the installer from Woody again,
among other things, with no replacement that is even to the "alpha-test
could-eat-your-system no-promises keep-both-pieces not really a release"
stage. Good or bad, it's the call of the current RM, and has been made.
Post by martin f krafft
Whatever, flame to /dev/null please. I am just saying how Debian could
be made better (and expressing my willingness to help, as always...)
Convince the RM, or get a GR passed. Write a good GR and it will have my
vote, but getting one that has any chance of success is beyond my current
level of political acumen.
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
***@lightbearer.com http://users.lightbearer.com/lucifer/
Anthony Towns
2002-11-05 07:24:31 UTC
Permalink
Post by Joel Baker
I don't see any *fundamental* reason why we couldn't, either.
Try installing sarge right now.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Joel Baker
2002-11-05 08:30:01 UTC
Permalink
Post by Anthony Towns
Post by Joel Baker
I don't see any *fundamental* reason why we couldn't, either.
Try installing sarge right now.
Try taking quotes completely out of context.

"Fundamental reason", as I used it, was meant to indicate something on the
order of a law of nature. Decisions to abandon (problematic) old software
before the replacement even *exists* in any meaningful fashion do not
qualify.

Again, I assert: the only thing which truly prevents Debian from having an
actual release schedule is the utter lack of interest in changing way in
which we decide when to do a release.

In other circles, "we have six months until we try to release again" means
that if the installer takes 18 months to write, you assume that you do not
have it for 3 release cycles. Other things may happen to cause the cycle to
slip, often unforseen (and exceeding normally accounted for) last-minute
delays, but they don't *assume* that 18 months is a viable release cycle.

And it is proven to function, and work. Debian's method is also proven
to function, and work... up to a point. I say that empirical evidence
indicates that we have reached the point where it is no longer tenable as
it is.

Prior to Woody, I heard the refrain "testing will fix this, but it hasn't
had a chance to sit between major releases to prove it". Okay, valid
argument. Now that it's sitting between major releases, it may well be
true that we could freeze and release much faster (having not yet tried
to do it, I can only say 'it appears likely'). So we... make choices that
guarantee another 2-year release cycle.

Seriously: can you name at least one other significant (let's say, oh, 1000
users as a reasonable minima; certainly we have far more, as do most things
folks would consider major), evolving (as opposed to mature) project which
makes feature-upgrade releases once every 2 years, and is considered at all
successful?

I can name only one off the top of my head - TinyFugue. Which is steadily
having people switch away from it to other clients that offer the same
basic function, because it hasn't even remotely kept up with features. I
wouldn't say it is a success any longer, so much as "the only client of
it's capabilities on most Unix boxes". That seems to be much of the staying
power it has, and is steadily becoming less true as other clients advance
to fill the void.

I mean, we're not talking about the window manager flavor of the week, or
SpamAssassin, or the Linux development branch when it's in kernel of the
week mode. Things like BIND, Sendmail, and Apache all have regular feature
upgrades... and due to Debian's policies on stable (which are otherwise
perfectly sane and reasoanble), we end up with badly outdated versions of
even such slow-change tools.

A private conversation had a rather telling comment in it, the other
day; another developer noted that much of the pressure to actually get a
release out the door seems to have vanished, with the advent of 'testing';
most developers run at least that, on any workstation, and there were
significant numbers of servers upgraded to it during the final months of
Woody's preparation, because it was more feasible to track the updates and
manually watch for security fixes than it was to try to update all of the
software that needed to be updated from a potato system with software two
years out of date.
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
***@lightbearer.com http://users.lightbearer.com/lucifer/
Anthony Towns
2002-11-05 09:34:51 UTC
Permalink
Post by Joel Baker
Post by Anthony Towns
Post by Joel Baker
I don't see any *fundamental* reason why we couldn't, either.
Try installing sarge right now.
Try taking quotes completely out of context.
"Fundamental reason", as I used it, was meant to indicate something on the
order of a law of nature.
Getting boot-floppies ready has taken on the order of a year since at
least slink. debian-installer has been going as a project for almost
two years, and is still a *long* way off being ready.

Problems getting the installer ready sure seem like a force of nature
from where I sit.

Seriously, you can philosophise all you want, but that's not going to
change anything. Which is another property of forces of nature, I suppose.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Andreas Metzler
2002-11-05 09:41:37 UTC
Permalink
Joel Baker <***@lightbearer.com> wrote:
[...]
Post by Joel Baker
In other circles, "we have six months until we try to release again" means
that if the installer takes 18 months to write, you assume that you do not
have it for 3 release cycles.
Iirc nobody was willing to maintain boot-floppies for another release.
Post by Joel Baker
Other things may happen to cause the cycle to
slip, often unforseen (and exceeding normally accounted for) last-minute
delays, but they don't *assume* that 18 months is a viable release cycle.
And it is proven to function, and work. Debian's method is also proven
to function, and work... up to a point. I say that empirical evidence
indicates that we have reached the point where it is no longer tenable as
it is.
Prior to Woody, I heard the refrain "testing will fix this, but it hasn't
had a chance to sit between major releases to prove it". Okay, valid
argument. Now that it's sitting between major releases, it may well be
true that we could freeze and release much faster (having not yet tried
to do it, I can only say 'it appears likely'). So we... make choices that
guarantee another 2-year release cycle.
[...]

That is too simple. In every release cycle there seems to be at least
one major thing that has to get in and needs more than 6 months for
implementation and proper testing with a big audience. Take e.g. the
gcc-3.2 transition[1] or every perl-update. Debian has neither got
the resources nor the *testers* to move this part to separate trees
(unstable_gcc3.2", unstable_perl5.8, unstable_gcc3.2+perl5.8,
"unstable - the release-candidate.")
Post by Joel Baker
another developer noted that much of the pressure to actually get a
release out the door seems to have vanished, with the advent of 'testing';
You might be correct.

cu andreas
[1] BTW, how is its status?
--
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Joey Hess
2002-11-06 01:05:33 UTC
Permalink
Post by Joel Baker
As I said in the part of the message you trimmed - getting sufficient
concensus to implement a GR saying that we want biannual releases is likely
to be nigh impossible.
I'd like to tack a rider onto the "release every 6 months" GR that fixes
the value of pi at 3.14 please.
--
see shy jo -- heh, he said "GR".
Anthony Towns
2002-11-05 07:23:33 UTC
Permalink
Post by martin f krafft
Uh, you know that January is coming up and we are on a biannual
schedule, right?
I must have missed that memo.
Post by martin f krafft
Can we release in January, please?
If you get a working installer up for all machines Debian supports by
the end of last week.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Michael Stone
2002-11-05 11:30:33 UTC
Permalink
Post by martin f krafft
I think if Debian releases 4.0 after 3.0r6 or whatever,
We shouldn't release 4.0, we should release 4. And the next one should
be 5, and then 6. The minor number is absolutely meaningless and should
be abandoned. For other distributions it might have a meaning (e.g.,
redhat tends to support security only for the final minor number in the
last major series--but our minors are completely arbitrary and have no
such encoded meaning.)
Post by martin f krafft
then we will lose credibility
That's ridiculous. We should not cater to anyone foolish enough to think
a version number means anything.

Mike Stone
Emile van Bergen
2002-11-05 11:55:47 UTC
Permalink
Hi,
Post by Michael Stone
Post by martin f krafft
I think if Debian releases 4.0 after 3.0r6 or whatever,
We shouldn't release 4.0, we should release 4. And the next one should
be 5, and then 6. The minor number is absolutely meaningless and should
be abandoned. For other distributions it might have a meaning (e.g.,
redhat tends to support security only for the final minor number in the
last major series--but our minors are completely arbitrary and have no
such encoded meaning.)
Well, as long as the scheme is used, there's at least the freedom to
indicate smaller or larger steps of progress among releases.

This may have no meaning for computers, but it may have for humans
("Let's see now, Debian has released a version with a new major number,
there should be quite some changes. I'm curious, maybe I should give it
another try").
Post by Michael Stone
Post by martin f krafft
then we will lose credibility
That's ridiculous. We should not cater to anyone foolish enough to think
a version number means anything.
It may not have a solid, concrete definition, but even in Debian's case,
incrementing the major or minor version may convey some information in
the communication between developers and users.

Even if the meaning of bumping the minor instead of the major version
number is limited to saying "this is a smaller change than one that we'd
bump the major number for", you'd loose that bit of information if you
abandon it. I don't see any compelling reason to do that.

There's been a lot of complaint, but I really don't think Debian's
version numbering it's that bad, I even think it makes sense. I also
like the 'r', it makes it clear that it's the same thing, really the
same thing, just a new [r]evision of it, with some bugfixes.

Cheers,


Emile.
--
E-Advies / Emile van Bergen | ***@e-advies.info
tel. +31 (0)70 3906153 | http://www.e-advies.info
Peter Mathiasson
2002-11-05 13:54:02 UTC
Permalink
Post by Emile van Bergen
Post by Michael Stone
We shouldn't release 4.0, we should release 4. And the next one should
be 5, and then 6. The minor number is absolutely meaningless and should
This may have no meaning for computers, but it may have for humans
("Let's see now, Debian has released a version with a new major number,
there should be quite some changes. I'm curious, maybe I should give it
another try").
If Sun can have it booth ways (ie. 2.8 = 8), we can too. And then everyone's
happy, right?
--
Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu
GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228
Steve Dunham
2002-11-05 16:27:21 UTC
Permalink
Post by Peter Mathiasson
Post by Emile van Bergen
Post by Michael Stone
We shouldn't release 4.0, we should release 4. And the next one should
be 5, and then 6. The minor number is absolutely meaningless and should
We probably should call it Debian '04, given our schedule slips. :)
Post by Peter Mathiasson
Post by Emile van Bergen
This may have no meaning for computers, but it may have for humans
("Let's see now, Debian has released a version with a new major number,
there should be quite some changes. I'm curious, maybe I should give it
another try").
If Sun can have it booth ways (ie. 2.8 = 8), we can too. And then everyone's
happy, right?
It's also SunOS 5.8.


Steve
***@cse.msu.edu
Adrian 'Dagurashibanipal' von Bidder
2002-11-05 14:57:05 UTC
Permalink
On Tue, 2002-11-05 at 12:55, Emile van Bergen wrote:

[Debian versioning]
Post by Emile van Bergen
Well, as long as the scheme is used, there's at least the freedom to
indicate smaller or larger steps of progress among releases.
This may have no meaning for computers, but it may have for humans
("Let's see now, Debian has released a version with a new major number,
there should be quite some changes. I'm curious, maybe I should give it
another try").
Could one of the old time Debianers give the major steps that were taken
with each release? Then it would at least be possible to get an idea of
how big the difference between a major and a minor version increase was
in the past.

I've only just started with Debian, so I can only do

potato (2.2) --> woody (3.0)
- XFree 4
- KDE 2
- 6 -> 11 arches
woody (3.0) --> sarge (?.?)
- gcc 3 as default compiler
- gnome 2
- KDE 3
- new installer

cheers
-- vbi
--
this email is protected by a digital signature: http://fortytwo.ch/gpg

NOTE: keyserver bugs! get my key here: https://fortytwo.ch/gpg/92082481
Tim Dijkstra
2002-11-05 15:50:04 UTC
Permalink
On 05 Nov 2002 15:57:05 +0100
Post by Adrian 'Dagurashibanipal' von Bidder
Could one of the old time Debianers give the major steps that were
taken with each release? Then it would at least be possible to get an
idea of how big the difference between a major and a minor version
increase was in the past.
Although I'm not a DD, I think you can find that info here:
http://www.debian.org/doc/manuals/project-history/

grts Tim
Richard Braakman
2002-11-05 16:09:38 UTC
Permalink
Post by Adrian 'Dagurashibanipal' von Bidder
Could one of the old time Debianers give the major steps that were taken
with each release? Then it would at least be possible to get an idea of
how big the difference between a major and a minor version increase was
in the past.
?? -> 1.1 (there was no 1.0)
AFAIK this was the a.out -> ELF transition. Also, of course, moving
from 0.x to 1.x means "there are no major parts missing".

1.3.1 -> 2.0 (bo -> hamm)
libc5 -> libc6 transition

2.2 -> 3.0 (potato -> woody)
Introduction of "testing" distribution

I think it's appropriate to use major version numbers for large
structural changes and when compatibility is broken, and to use
minor increments for everything else. Since Debian places a heavy
emphasis on backwards compatibility (at least it used to), we haven't
had many reasons to bump the major number.

Regardless of my own opinion, however, I'm happy to let the release
manager decide. It's one of the few perks of a stressful job :-)

Richard Braakman
Joey Hess
2002-11-06 01:01:00 UTC
Permalink
Post by Richard Braakman
?? -> 1.1 (there was no 1.0)
AFAIK this was the a.out -> ELF transition. Also, of course, moving
from 0.x to 1.x means "there are no major parts missing".
1.3.1 -> 2.0 (bo -> hamm)
libc5 -> libc6 transition
2.2 -> 3.0 (potato -> woody)
Introduction of "testing" distribution
And remember that there was some dissention about using 3.0 for woody,
partly because there was no such major upgrade in it. Aside from woody,
we've had very good reasons for incrementing the major versions, I guess
only time will tell if breaking that precedent as we did for woody will
make the whole versioning scheme "completely arbitrary" or not.

Of course, this whole discussion may be somewhat moot if nobody ever
figures out how to go about the gcc 3.0 transition (which may warrent a
major version bump if we ever do it).
--
see shy jo
Colin Walters
2002-11-06 17:28:32 UTC
Permalink
Post by Joey Hess
And remember that there was some dissention about using 3.0 for woody,
partly because there was no such major upgrade in it.
I think becoming the most portable free OS is worthy of a big version
number bump...
Wichert Akkerman
2002-11-06 18:54:59 UTC
Permalink
Post by Colin Walters
I think becoming the most portable free OS is worthy of a big version
number bump...
We have some major catching up to do with NetBSD if we want to
accomplish that..

Wichert.
--
_________________________________________________________________
/***@wiggy.net This space intentionally left occupied \
| ***@deephackmode.org http://www.wiggy.net/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Nathan Hawkins
2002-11-06 20:28:18 UTC
Permalink
Post by Wichert Akkerman
Post by Colin Walters
I think becoming the most portable free OS is worthy of a big version
number bump...
We have some major catching up to do with NetBSD if we want to
accomplish that..
AIUI, the plan is to simply absorb them. ;-)

More seriously, one of the long-term effects of the work that Matthew
Garrett and Joel Baker are doing with netbsd-i386 is that it should
become possible to pick up as many netbsd archs as people want.

---Nathan
Joel Baker
2002-11-06 22:51:16 UTC
Permalink
Post by Nathan Hawkins
Post by Wichert Akkerman
Post by Colin Walters
I think becoming the most portable free OS is worthy of a big version
number bump...
We have some major catching up to do with NetBSD if we want to
accomplish that..
AIUI, the plan is to simply absorb them. ;-)
More seriously, one of the long-term effects of the work that Matthew
Garrett and Joel Baker are doing with netbsd-i386 is that it should
become possible to pick up as many netbsd archs as people want.
....

... as long as there is someone willing to put in the groundwork of getting
such a thing bootstrapped. Which is a much smaller project than what we're
doing, but still fairly non-trivial. I consider this a good thing, really;
it will provide backpressure against bloating the archive for the same of
a handful of users, at least unless one of them happens to be very good at
it (which, basically, puts it in the same position as quite a few of the
non-i386 Linux arches :)

I don't know that I'd say Debian is the most portable free OS; I would
say, however, that the split is probably 90/10, between "folks who
support making Debian more portable and cleaning up code" (apart from any
religious issues over NetBSD or FreeBSD or whatever else), and "folks who
really could care less". Since I probably spend more time than is perhaps
warranted griping about other matters, I would like to pause here, and say
something to that 90%:

Thank you.

For all the things I think could be better, I really couldn't ask for a
group more supportive of this sort of effort. From working with the *BSD
and Hurd porting efforts, to fixing bugs exposed by Junichi's auto-build
scanning, and dealing with all of the other problems that get exposed -
and, more to the point, fixed - when people do the strangest things to the
code you package and maintain, I have, with very few expections, been truly
impressed by how willing Debian as a whole is to put forth the effort to
Get It Right (tm).
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
***@lightbearer.com http://users.lightbearer.com/lucifer/
Colin Walters
2002-11-07 00:03:34 UTC
Permalink
Post by Wichert Akkerman
Post by Colin Walters
I think becoming the most portable free OS is worthy of a big version
number bump...
We have some major catching up to do with NetBSD if we want to
accomplish that..
No, we don't. NetBSD only runs on 10 distinct CPU architectures. We
run on 11. Now, we can sit here and debate the quality of the ports
forever...but the number of CPU architectures is a hard fact.
Tollef Fog Heen
2002-11-07 00:35:12 UTC
Permalink
* Wichert Akkerman

| Previously Colin Walters wrote:
| > I think becoming the most portable free OS is worthy of a big version
| > number bump...
|
| We have some major catching up to do with NetBSD if we want to
| accomplish that..

No, not really. They have a lot more fine-grained port structure than
us, like five or six different ppc based ports. Also, they don't have
s/390 at least.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Michael Stone
2002-11-05 16:56:58 UTC
Permalink
Post by Emile van Bergen
Post by Michael Stone
We shouldn't release 4.0, we should release 4. And the next one should
be 5, and then 6. The minor number is absolutely meaningless and should
be abandoned. For other distributions it might have a meaning (e.g.,
redhat tends to support security only for the final minor number in the
last major series--but our minors are completely arbitrary and have no
such encoded meaning.)
Well, as long as the scheme is used, there's at least the freedom to
indicate smaller or larger steps of progress among releases.
But we don't have any such steps. Hence "completely arbitrary".
Post by Emile van Bergen
This may have no meaning for computers, but it may have for humans
("Let's see now, Debian has released a version with a new major number,
there should be quite some changes. I'm curious, maybe I should give it
another try").
I'll let you in on a secret--there are major changes with *every* new
debian release, and you should *always* upgrade, because we don't have
the resources to support old releases indefinately.

Mike Stone
Dmitry Borodaenko
2002-11-05 17:40:46 UTC
Permalink
On Tue, Nov 05, 2002 at 11:56:36AM -0500, Michael Stone wrote:
MS> I'll let you in on a secret--there are major changes with *every*
MS> new debian release

Hmm, are you sure this is not a bug? :)
--
Dmitry Borodaenko
Michael Stone
2002-11-05 18:43:28 UTC
Permalink
Post by Dmitry Borodaenko
MS> I'll let you in on a secret--there are major changes with *every*
MS> new debian release
Hmm, are you sure this is not a bug? :)
Yes. Otherwise we could have gone home after buzz.

Mike Stone
Glenn McGrath
2002-11-04 21:33:04 UTC
Permalink
On Mon, 4 Nov 2002 13:17:01 -0500
Post by Noah L. Meyerhans
Version numbers are arbitrary and meaningless.
My turn to express my pet hate.

Its not a version number, its a version string... irrespective of what
policy says.

A number cant have words embeded in it in a non-mathematical manner.

Numbers use decimal points, the '.' in the version string isnt a decimal
point, its a seperator.

If it were a number then 0.1 would be bigger than 0.00000001

If we refered to it as a string rather than a number it would avoid a lot
of confusion.



Glenn
David Sanders
2002-11-07 21:07:54 UTC
Permalink
Post by Morten Brix Pedersen
I am wondering why updates to the Debian GNU/Linux distribution uses the
much alternative versioning syntax, such as 2.2r7, 3.0r1 etc.
In my opinion, 3.0.1 is a much clearer and more commonly used syntax.
I agree. 3.0r1 sounds too much like WinXP SP1. The Win people always
claim that there is no innovation coming out of the Linux community,
just copying Windows/Office. Its time for a versioning syntax change -
but it is also time for version policy upgrade. We need to get the
latest innovative free software on the street faster.

I hereby declare that we need 3.1.0 within six months, complete with
KDE3, GNOME2, Perl5.8, Apache2, GCC3, etc. etc. etc.

What say ye?

David
Anthony Towns
2002-11-07 21:20:43 UTC
Permalink
Post by David Sanders
I hereby declare that we need 3.1.0 within six months, complete with
KDE3, GNOME2, Perl5.8, Apache2, GCC3, etc. etc. etc.
Get me a working installer in, say, three months, and I think we could
manage that. Give me one within two months and I'd be about as willing
to guarantee it as I'd be willing to guarantee anything.

Of course, even if we manage that, we'd still only be playing catch up
with versions of Red Hat that have already been released.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Bernd Eckenfels
2002-11-07 21:27:38 UTC
Permalink
Post by Anthony Towns
Get me a working installer in, say, three months, and I think we could
manage that. Give me one within two months and I'd be about as willing
to guarantee it as I'd be willing to guarantee anything.
Well, since the installer/boot-floppy stuff is always mentioned as one of
the reasons for the delay, which it is surely not, we could simple release
3.1 with the current installer/boot floppies. No?

New versions of packages and a new installer is realy independend from each
other.

Greetings
Bernd
Michael Banck
2002-11-07 21:29:34 UTC
Permalink
Post by Bernd Eckenfels
Well, since the installer/boot-floppy stuff is always mentioned as one of
the reasons for the delay, which it is surely not, we could simple release
3.1 with the current installer/boot floppies. No?
Ah, you are going to maintain boot-floppies for all 11 architectures? In
that case, we can go ahead I guess.

Michael
--
<colins> Anyone got $50 to lend me, I'm thinking of taking over WorldCom
<fallous> not anymore. I just bought xerox for $27.95
<colins> you got ripped
<fallous> it included a new toner cartridge for my photocopier
Bernd Eckenfels
2002-11-07 21:43:34 UTC
Permalink
Post by Michael Banck
Ah, you are going to maintain boot-floppies for all 11 architectures? In
that case, we can go ahead I guess.
Is this your way to think about suggestions?

How about dealing with the idea to make a release which does not change all
of the internals, just for the sake of less work and quicker release.

If somebody can tell me why not, then i would be happy.

If you want me to say we can't release more often because this is too much
work for the currently porters, then fine. But in that case we should admit
it, and not pretend that we look for faster release cycles.

Greetings
Bernd
Michael Banck
2002-11-07 21:55:16 UTC
Permalink
Post by Bernd Eckenfels
Post by Michael Banck
Ah, you are going to maintain boot-floppies for all 11 architectures? In
that case, we can go ahead I guess.
Is this your way to think about suggestions?
Apparently nobody[1] wants to have anything to do with boot-floppies
anymore, so your argument seems bogus unless you do it yourself. Sorry,
I don't want to be rude, but this seems to be the situation today.

Sure, we could stall debian-installer for another year and try to get
boot-floppies working again (this time, we'd really have to use 2.4 on
all flavors or be loughed at), but IMHO it's time to move forward
eventually, debian-installer really seems to rock.

Michael
--
[1] well, Zomb said something like he'd be still interested in
boot-floppies, but this was some time ago and I don't know what he
thinks about this today.
Bernd Eckenfels
2002-11-07 22:13:14 UTC
Permalink
Post by Michael Banck
Apparently nobody[1] wants to have anything to do with boot-floppies
anymore, so your argument seems bogus unless you do it yourself. Sorry,
I don't want to be rude, but this seems to be the situation today.
apparently this was the case for the last installer, too. I did not know
that bf are already considered retired? Wont the new debian installer not
use them, too?

Greetings
Bernd
y
Daniel Jacobowitz
2002-11-07 22:19:28 UTC
Permalink
Post by Bernd Eckenfels
Post by Michael Banck
Apparently nobody[1] wants to have anything to do with boot-floppies
anymore, so your argument seems bogus unless you do it yourself. Sorry,
I don't want to be rude, but this seems to be the situation today.
apparently this was the case for the last installer, too. I did not know
that bf are already considered retired? Wont the new debian installer not
use them, too?
No. b-f was scheduled to die after potato. The new d-i wasn't ready.
So we resurrected them provisionally.

D-i is completely independent and _people need to finish it instead of
complaining about the release cycle_.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bernd Eckenfels
2002-11-07 22:26:50 UTC
Permalink
Post by Daniel Jacobowitz
_people need to finish it instead of
complaining about the release cycle_.
i can understand that some people are pissed by others who discuss
everything, on the other hand personally I think it is important to also
talk about what is scheduled.

For me, it was not clear that we never intended to make the boot floppies an
ongoing stable project, maybe because I thought something which delayed the
release for so long was something which is used in more than one release.
PErhaps this is because I did not read every mind, but more likely it is
just because everybody was told to shut up.

Greetings
Bernd
Anthony Towns
2002-11-07 22:41:08 UTC
Permalink
Post by Bernd Eckenfels
i can understand that some people are pissed by others who discuss
everything, on the other hand personally I think it is important to also
talk about what is scheduled.
It's more likely because you weren't around on debian-***@lists.d.o in
early 2001 when the decisions were made... (Shame on you!)

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Bernd Eckenfels
2002-11-07 22:47:10 UTC
Permalink
Post by Anthony Towns
early 2001 when the decisions were made... (Shame on you!)
Yes, this is another problem. Debian policy, Debian legal, boot-floppies and
whatever there is more on important decision making mailng lists are not
transparent to the debian developer who cant follow all of them. Thanks to
Joey this will not be the case anymore.

Gruss
Bernd
--
(OO) -- ***@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD ***@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Anthony Towns
2002-11-07 23:23:39 UTC
Permalink
Post by Bernd Eckenfels
Post by Anthony Towns
early 2001 when the decisions were made... (Shame on you!)
Yes, this is another problem. Debian policy, Debian legal, boot-floppies and
whatever there is more on important decision making mailng lists are not
transparent to the debian developer who cant follow all of them. Thanks to
Joey this will not be the case anymore.
While Joey's doing a superlative job, I think you're being a bit optimistic
on how much help it'll be:

http://www.debian.org/News/weekly/2000/41/
Anthony's main concern is that the new debian-installer
project is not ready yet, and the old boot floppies
need several months of work to be usable for woody.

http://lists.debian.org/debian-devel-announce-0012/msg00012.html
So I think the thing we probably need to focus first on
is getting some way to install woody directly. Which
means we need to decide whether we're going to keep
hammering away at debian-installer until it actually
becomes usable, or if we're going to bite the bullet
and just accept that we're going to use boot-floppies
again, not be able to improve them much and get
flamed for it in all the woody reviews too. If we
do go with boot-floppies for woody, I'd be strongly
inclined towards downplaying debian-installer so as
not to divide the testing effort and leave us with a
choice of two installation methods that both suck. To
get boot-floppies to work with woody at about the
same quality as potato's install, will likely take
a couple of months; to get debian-installer to work
at a similar quality could take... four months? six?

http://www.debian.org/News/weekly/2001/6/
The boot-floppies team needs help. Adam Di Carlo wrote
in, asking for help on what may be the final revision of
the boot floppies -- for woody -- before the upcoming
debian-installer effort replaces them. According to
Adam, "a lot of the 'talent' have been sucked into
debian-installer. I have pretty much no one helping me
right now with boot-floppies maintenance." He included
a list of tasks that need doing to get a usable set of
boot floppies for woody, and concluded, "Please help
me out. Otherwise, god knows when we'll be able to
release woody!"

There's more to Debian than anyone can reasonably expect to stay
consistently on top of, IMO. Even just within the "core" bits.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Bernd Eckenfels
2002-11-08 00:01:54 UTC
Permalink
Post by Anthony Towns
While Joey's doing a superlative job, I think you're being a bit optimistic
i was refering to the weekly news, that it is important to make the work of
those pecial lists more transparent.
Post by Anthony Towns
http://www.debian.org/News/weekly/2000/41/
http://lists.debian.org/debian-devel-announce-0012/msg00012.html
http://www.debian.org/News/weekly/2001/6/
Great, I gues this mail should be quoted in dwn .)

Greetings
Bernd
--
(OO) -- ***@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD ***@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Martin Schulze
2002-11-09 22:01:07 UTC
Permalink
Post by Bernd Eckenfels
Post by Anthony Towns
While Joey's doing a superlative job, I think you're being a bit optimistic
i was refering to the weekly news, that it is important to make the work of
those pecial lists more transparent.
But it's not sufficient apparently. And as usual, you should not rely on
third-party's work...
Post by Bernd Eckenfels
Post by Anthony Towns
http://www.debian.org/News/weekly/2000/41/
http://lists.debian.org/debian-devel-announce-0012/msg00012.html
http://www.debian.org/News/weekly/2001/6/
Great, I gues this mail should be quoted in dwn .)
Err? It was quoted from DWN, why should it included in it again?

Regards,

Joey
--
Reading is a lost art nowadays. -- Michael Weber

Please always Cc to me when replying to me on the lists.
Anthony Towns
2002-11-07 22:26:16 UTC
Permalink
Post by Bernd Eckenfels
Post by Anthony Towns
Get me a working installer in, say, three months, and I think we could
manage that. Give me one within two months and I'd be about as willing
to guarantee it as I'd be willing to guarantee anything.
Well, since the installer/boot-floppy stuff is always mentioned as one of
the reasons for the delay, which it is surely not, we could simple release
3.1 with the current installer/boot floppies. No?
Nope: glibc and numerous other stuff have changed so it no longer builds.
There's also probably a new kernel (2.6) to cope with, which tends to
be difficult at best, and there's the ever present pressur to improve
internationalisation and other features. Note that *everything* has to
fit into around 2.88MB in the boot-floppies model.

We *tried* "simply releasing with the current boot-floppies" for woody
-- it took about twelve months between having people start working on
them and getting a finished product. And we're in a worse state now:
most of the experienced people, particularly Adam, don't want to go
through that again.
Post by Bernd Eckenfels
New versions of packages and a new installer is realy independend from each
other.
Unfortunately they're not. They *ought* to be, though. Making things that
way is one of the goals of the new installer, but it's not working yet.

There are four options at present:

* make boot-floppies (the installer we've always used) work
* make PGI work
* make debian-installer work
* write something else new

Each of these have a fairly vast array of problems, and debian-installer
is the only one that has people actively working on fitting it into
Debian, as far as I'm aware. (From what I've seen, it's intended more
as something third parties can use to install Debian, than something
for Debian itself; I'm happy to be corrected on this)

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Branden Robinson
2002-11-09 22:51:35 UTC
Permalink
Post by Anthony Towns
* make boot-floppies (the installer we've always used) work
* make PGI work
* make debian-installer work
* write something else new
Each of these have a fairly vast array of problems, and debian-installer
is the only one that has people actively working on fitting it into
Debian, as far as I'm aware. (From what I've seen, it's intended more
as something third parties can use to install Debian, than something
for Debian itself; I'm happy to be corrected on this)
Debian-installer is intended more as something third parties can use to
install Debian, than something for Debian itself?

If you meant PGI, then you're wrong. PGI has never been intended as
something for use "more" by third parties.

It is simply intended as an alternative to the existing Debian
installation system for the architectures where it works.

If it were intended mostly for third party use it never would have been
released to Debian unstable.
--
G. Branden Robinson | Never underestimate the power of
Debian GNU/Linux | human stupidity.
***@debian.org | -- Robert Heinlein
http://people.debian.org/~branden/ |
Anthony Towns
2002-11-10 06:02:09 UTC
Permalink
Post by Branden Robinson
Post by Anthony Towns
* make boot-floppies (the installer we've always used) work
* make PGI work
* make debian-installer work
* write something else new
Each of these have a fairly vast array of problems, and debian-installer
is the only one that has people actively working on fitting it into
Debian, as far as I'm aware. (From what I've seen, it's intended more
as something third parties can use to install Debian, than something
for Debian itself; I'm happy to be corrected on this)
Debian-installer is intended more as something third parties can use to
install Debian, than something for Debian itself?
Doh. Yes, I meant "From what I've seen, _PGI_'s intended more...".
Post by Branden Robinson
If you meant PGI, then you're wrong. PGI has never been intended as
something for use "more" by third parties.
Well, for it to be used by Debian, it needs to be able to be "built" by
Debian, to be put on our official CDs, and to support all the machines
we intend to support. AFAIK, the current situation with PGI is that it's
essentially as hard to build as boot-floppies was (in that it needs to
grab copies of a whole bunch of .debs from the archive, then put them
together into an image using features the autobuilders don't provide
on a machine running the target architecture), and actually makes this
marginally more of a problem by depending on more things (like X).

Given that no one's seemed particularly interested in making PGI easy
to build -- and that it's a hard thing to do -- then I'm continuing
to assume that it's intended for people for whom that's not an issue,
which, as far as I'm aware, are third parties.

Which isn't to downplay what you've done at all -- from all reports PGI's
unsurpassed as a Debian installer where it's suitable -- but rather to
say that as things stand, PGI's not an answer as far as getting sarge
out any sooner is concerned.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``If you don't do it now, you'll be one year older when you do.''
Continue reading on narkive:
Loading...