5:52 p.m.
Here's your chance to slap me up side of the head!
Reading the Debian thread (and others) has made me wonder why Fedora
has to have "releases" at all. Why not have a continuously evolving
distribution? One would start by downloading an "installer system"
that would then use the existing mechanisms (yum, whatever) to update
itself. From this point on, why would one need "releases"? Just keep
releasing updates and new packages exactly as things are done now.
I know there must be something wrong with this scenario; would someone
like to hit me with a clue stick.
Regards,
John
5:58 p.m.
John Wendel wrote:
Here's your chance to slap me up side of the head!
Reading the Debian thread (and others) has made me wonder why Fedora
has to have "releases" at all. Why not have a continuously evolving
distribution? One would start by downloading an "installer system"
that would then use the existing mechanisms (yum, whatever) to update
itself. From this point on, why would one need "releases"? Just keep
releasing updates and new packages exactly as things are done now.
I know there must be something wrong with this scenario; would someone
like to hit me with a clue stick.
Regards,
John
Personally, I like the Fedora system for servers and such since I know
where things stand at a given time. For instance I've upgraded 5
servers over the last month with either FC4 or FC5. I chose FC4 for the
production ones since I was comfortable with it and knew it was stable.
I used FC5 since it was newer on the 'not ready for prime time' boxes I
have to work out the kinks. For workstations or laptops (mine in
particular) I use Gentoo for the very reason you suggest 'a revolving
distro'. It's great to immediately get the latest and greatest off the
bat if I have time to work out the bugs or deal with driver/module
issues. I don't want Fedora to change the way it releases for this
reason alone. I know where the distro is if I need to fall back on a
certain library/package.
My $0.02.
--
Mark Haney
Sr. Systems Administrator
ERC Broadband
6:01 p.m.
On Thu, Apr 27, 2006 at 03:52:02PM -0700, John Wendel wrote:
Reading the Debian thread (and others) has made me wonder why Fedora
has to have "releases" at all. Why not have a continuously evolving
distribution? One would start by downloading an "installer system"
that would then use the existing mechanisms (yum, whatever) to update
itself. From this point on, why would one need "releases"? Just keep
releasing updates and new packages exactly as things are done now.
Think of the releases as stabilisation points.
Right now, after a release, there are two forks.
The released version will have stable updates pushed to it.
The other fork (rawhide/development), will have all kinds of crazy
destabilising experiments pushed to it.
With a single stream as you propose, we either throw away
the notion of a stable release, or we don't ever destabilise the tree.
Dave
--
http://www.codemonkey.org.uk
6:06 p.m.
Dave Jones wrote:
On Thu, Apr 27, 2006 at 03:52:02PM -0700, John Wendel wrote:
With a single stream as you propose, we either throw away
the notion of a stable release, or we don't ever destabilise the tree.
Dave
And this also points to my gripe about Debian. It's 'stable'
isn't very
in a lot of cases I've seen. That and it's a giant pain in the butt to
update.
--
Mark Haney
Sr. Systems Administrator
ERC Broadband
6:21 p.m.
On Thu, Apr 27, 2006 at 07:06:00PM -0400, Mark Haney wrote:
And this also points to my gripe about Debian. It's
'stable' isn't very
in a lot of cases I've seen. That and it's a giant pain in the butt to
update.
May I ask what you find unstable about stable? Also what the giant
pain is in updating?
Kind Regards,
D
--
BOFH excuse #148:
Insert coin for new game
6:29 p.m.
ded wrote:
On Thu, Apr 27, 2006 at 07:06:00PM -0400, Mark Haney wrote:
> And this also points to my gripe about Debian. It's 'stable' isn't
very
> in a lot of cases I've seen. That and it's a giant pain in the butt to
> update.
>
May I ask what you find unstable about stable? Also what the giant
pain is in updating?
Kind Regards,
D
I could go on and on about the Debian server we have. We've rebuilt
OpenLDAP 3 times. We've had to rebuild apache twice. And MRTG never
survives an update. And this is from just using standard .deb packages.
--
Mark Haney
Sr. Systems Administrator
ERC Broadband
9:19 p.m.
ded wrote:
On Thu, Apr 27, 2006 at 07:06:00PM -0400, Mark Haney wrote:
>And this also points to my gripe about Debian. It's 'stable' isn't
very
>in a lot of cases I've seen. That and it's a giant pain in the butt to
>update.
May I ask what you find unstable about stable? Also what the giant
pain is in updating?
He *told* you. The pain is his butt.
:-)
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
3:20 a.m.
On Thu, Apr 27, 2006 at 07:06:00PM -0400, Mark Haney wrote:
And this also points to my gripe about Debian. It's
'stable' isn't very
in a lot of cases I've seen. That and it's a giant pain in the butt to
update.
I can provide an anecdote to the contrary. I'm surprised you're using
FC in a production environment. Of course you can use about everything
in a production environment if you yourself do all the work, but that's
exactly the point of using a stable branch of a distro (i.e. RHEL over
FC, stable/testing Debian).
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
9:19 p.m.
John Wendel wrote:
Why not have a continuously evolving
distribution? One would start by downloading an "installer system" that
would then use the existing mechanisms (yum, whatever) to update itself.
From this point on, why would one need "releases"? Just keep releasing
updates and new packages exactly as things are done now.
I know there must be something wrong with this scenario; would someone
like to hit me with a clue stick.
For a start not everyone in the world has enough bandwidth for that:
so they need iso images to be able to upgrade for example.
Jens
9:57 p.m.
Jens Petersen wrote:
John Wendel wrote:
> Why not have a continuously evolving distribution? One would start by
> downloading an "installer system" that would then use the existing
> mechanisms (yum, whatever) to update itself. From this point on, why
> would one need "releases"? Just keep releasing updates and new
> packages exactly as things are done now.
>
> I know there must be something wrong with this scenario; would someone
> like to hit me with a clue stick.
For a start not everyone in the world has enough bandwidth for that: so
they need iso images to be able to upgrade for example.
Here's one which may make more headway for understanding. There is
in any piece of software's life a thing called "integration test"
where it is tested with other pieces it must coexist with. Until
any given piece has been tested with other pieces, it may work
fine, or it may not, but we don't know. There comes a time when
one just *can't* test with every previous version of every piece
of software which has been released before, because there's just
not enough time. So one draws a line in the sand, and calls it
a release. The software available at that moment is all we test
with, and all we "guarantee" it'll work with. Trying all permutations
of all previous versions of all software just becomes too burdensome.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
10:27 p.m.
On Thu, 2006-04-27 at 21:57, Mike McCarty wrote:
>
> For a start not everyone in the world has enough bandwidth for that: so
> they need iso images to be able to upgrade for example.
Here's one which may make more headway for understanding. There is
in any piece of software's life a thing called "integration test"
where it is tested with other pieces it must coexist with. Until
any given piece has been tested with other pieces, it may work
fine, or it may not, but we don't know.
That would imply that you shouldn't expect software to work
unless it all comes from a single vendor, which should
not be the case at all - and if it is, you probably
shouldn't use any of it. Your interfaces either do
what they are documented to do or not, and no amount
of changes to other parts should change that.
--
Les Mikesell
lesmikesell(a)gmail.com
10:52 p.m.
Les Mikesell wrote:
On Thu, 2006-04-27 at 21:57, Mike McCarty wrote:
>>For a start not everyone in the world has enough bandwidth for that: so
>>they need iso images to be able to upgrade for example.
>
>Here's one which may make more headway for understanding. There is
>in any piece of software's life a thing called "integration test"
>where it is tested with other pieces it must coexist with. Until
>any given piece has been tested with other pieces, it may work
>fine, or it may not, but we don't know.
That would imply that you shouldn't expect software to work
unless it all comes from a single vendor, which should
not be the case at all - and if it is, you probably
shouldn't use any of it. Your interfaces either do
what they are documented to do or not, and no amount
of changes to other parts should change that.
I guarantee you, with anything as complex as an entire
OS distribution, the interfaces do not all do exactly
what they are documented to do. Anyone believing otherwise
lives in a fantasy land.
It is true that not all software would benefit as much
from integration test as others. OTOH, things like the
compilers, linkage editors, link libraries, kernel,
server programs, device drivers, installers, disc editors
and partition managers, and boot loaders all need some
integration test.
And not with just software, either. Many BIOS are known
to be broken. And then there are different hardware for
test. Trying to test all combinations just takes too much
time.
Look at all the stuff SELinux broke.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
11:13 p.m.
On Thu, 2006-04-27 at 22:52, Mike McCarty wrote:
>>
>>Here's one which may make more headway for understanding. There is
>>in any piece of software's life a thing called "integration test"
>>where it is tested with other pieces it must coexist with. Until
>>any given piece has been tested with other pieces, it may work
>>fine, or it may not, but we don't know.
>
>
> That would imply that you shouldn't expect software to work
> unless it all comes from a single vendor, which should
> not be the case at all - and if it is, you probably
> shouldn't use any of it. Your interfaces either do
> what they are documented to do or not, and no amount
> of changes to other parts should change that.
I guarantee you, with anything as complex as an entire
OS distribution, the interfaces do not all do exactly
what they are documented to do. Anyone believing otherwise
lives in a fantasy land.
Oh, I believe a lot of things are broken. I'm just not
sure I agree that replacing everything at once with
a new set that passed a couple of tests together is
the right way to deal with it. In particular it doesn't
make any sense to me to have to replace a kernel and
device drivers that have worked flawlessly on my hardware
for the last year or more with some wildly different
version just to get a new version of evolution and
some other desktop apps.
It is true that not all software would benefit as much
from integration test as others. OTOH, things like the
compilers, linkage editors, link libraries, kernel,
server programs, device drivers, installers, disc editors
and partition managers, and boot loaders all need some
integration test.
You seem to be forgetting that with fedora, the users
*are* the integration test. And for people who have their
own apps, the OS distribution is just supposed to supply
working unix-like interfaces.
And not with just software, either. Many BIOS are known
to be broken. And then there are different hardware for
test. Trying to test all combinations just takes too much
time.
Look at all the stuff SELinux broke.
Well, yes - the unix-like interface was pretty well
designed by about sysvr4 when linux started the attempt
to emulate it.
--
Les Mikesell
lesmikesell(a)gmail.com
12:37 a.m.
Les Mikesell wrote:
On Thu, 2006-04-27 at 22:52, Mike McCarty wrote:
>>>Here's one which may make more headway for understanding. There is
>>>in any piece of software's life a thing called "integration
test"
>>>where it is tested with other pieces it must coexist with. Until
>>>any given piece has been tested with other pieces, it may work
>>>fine, or it may not, but we don't know.
>>
>>
>>That would imply that you shouldn't expect software to work
>>unless it all comes from a single vendor, which should
>>not be the case at all - and if it is, you probably
>>shouldn't use any of it. Your interfaces either do
>>what they are documented to do or not, and no amount
>>of changes to other parts should change that.
>
>I guarantee you, with anything as complex as an entire
>OS distribution, the interfaces do not all do exactly
>what they are documented to do. Anyone believing otherwise
>lives in a fantasy land.
Oh, I believe a lot of things are broken. I'm just not
sure I agree that replacing everything at once with
a new set that passed a couple of tests together is
the right way to deal with it. In particular it doesn't
make any sense to me to have to replace a kernel and
device drivers that have worked flawlessly on my hardware
for the last year or more with some wildly different
version just to get a new version of evolution and
some other desktop apps.
I don't recall making that assertion.
>It is true that not all software would benefit as much
>from integration test as others. OTOH, things like the
>compilers, linkage editors, link libraries, kernel,
>server programs, device drivers, installers, disc editors
>and partition managers, and boot loaders all need some
>integration test.
You seem to be forgetting that with fedora, the users
*are* the integration test. And for people who have their
own apps, the OS distribution is just supposed to supply
working unix-like interfaces.
I agree with you in some respects that Fedora Core is
more like a beta release than anything else. So I'll
concede that you have a certain point here.
But what I saw advocated, as I understood it, was the
complete abandonment of the concept of a release, and
instead piecemeal releases of all parts of the distro.
This would be unmaintainable. The installer, for example,
must be intimately aware of what the kernel and boot
loader expect. Trying to make it backwards and forwards
compatible would be... well I can't think of words
which would describe the mess.
Certainly, one could probably release Mozilla, or Thunderbird,
without much worry of incompatibilities. But not so
the kernel, or the compilers/devel tools, or the installer.
[snip]
>Look at all the stuff SELinux broke.
Well, yes - the unix-like interface was pretty well
designed by about sysvr4 when linux started the attempt
to emulate it.
That's my point. It makes no sense for things to become
"unbundled" beyond a certain point. Some things *must*
be tested as a whole package, a release.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
10:02 p.m.
On Fri, 2006-04-28 at 11:19 +0900, Jens Petersen wrote:
John Wendel wrote:
> Why not have a continuously evolving
> distribution? One would start by downloading an "installer system" that
> would then use the existing mechanisms (yum, whatever) to update itself.
> From this point on, why would one need "releases"? Just keep releasing
> updates and new packages exactly as things are done now.
>
> I know there must be something wrong with this scenario; would someone
> like to hit me with a clue stick.
For a start not everyone in the world has enough bandwidth for that:
so they need iso images to be able to upgrade for example.
What you say applies to
those with _very_ limited bandwidth. They'd
obtain the ISO's from some off-line source.
For those with limited bandwidth, who'd download the ISOs first, then
burn them and then use their limited bandwidth for updates, the
situation is different. Not downloading the ISOs, but installing
directly from the net would spare them a lot of bandwidth and time,
because it would avoid them having to download packages (as part of the
ISOs) they have no use for, or have been updated/replace since the
release of the ISOs.
The same also applies to "late adopters" (E.g. people now installing
Fedora 4). Instead of wasting bandwidth on downloading ISOs, and then
replacing a large amount of the packages with updates on-line, they
could directly install the updated packages.
AFAICT, this is how many "lean" Debian derived distros (Knoppix?) work.
Ralf
10:42 p.m.
Ralf Corsepius wrote:
On Fri, 2006-04-28 at 11:19 +0900, Jens Petersen wrote:
>John Wendel wrote:
>
>For a start not everyone in the world has enough bandwidth for that:
>so they need iso images to be able to upgrade for example.
What you say applies to those with _very_ limited bandwidth. They'd
obtain the ISO's from some off-line source.
For those with limited bandwidth, who'd download the ISOs first, then
For those with severely limited bandwidth, the best bet is
to purchase pre-burned CDROMs.
[snip]
The same also applies to "late adopters" (E.g. people now
installing
Fedora 4). Instead of wasting bandwidth on downloading ISOs, and then
replacing a large amount of the packages with updates on-line, they
could directly install the updated packages.
AFAICT, this is how many "lean" Debian derived distros (Knoppix?) work.
Knoppix is not "lean". It's true that it (currently) fits onto one
CDROM, but it's compressed, and has Open Office, several developer's
kits, and a lot of diagnostic stuff on it.
DSL is lean, and it does work as you suggest in part. But that is
still is not an "incremental approach to release", as I understand
the current subject matter.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
2:13 p.m.
Ralf Corsepius wrote:
For those with limited bandwidth, who'd download the ISOs first,
then
burn them and then use their limited bandwidth for updates, the
situation is different. Not downloading the ISOs, but installing
directly from the net would spare them a lot of bandwidth and time,
because it would avoid them having to download packages (as part of the
ISOs) they have no use for, or have been updated/replace since the
release of the ISOs.
I don't know how others find this, but I personally am a big fan of
grabbing the DVD ISOs, even with a relatively speedy connection. In this
way, I can install everything I need from the disc(s), and get work done
while I let the update do its thing.
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
2:13 p.m.
Peter Gordon wrote:
I don't know how others find this, but I personally am a big fan
of
grabbing the DVD ISOs, even with a relatively speedy connection. In
this way, I can install everything I need from the disc(s), and get
work done while I let the update do its thing.
I recommend the DVD ISO to those
still using CDs (access to a D VD
burner and reader permitted). Aside from not changing the disc 4 or 5
times, I find the DVD installs in about 1/2 the time of CD-ROM install.
As per another commend about the disk completely out of date after a few
months is true. However,
there was a Fedora user who maintained "Service Packs" editions of 4.
Label FC4.1 FC4.2 etc. This
is a nice band-aid, but the underlining problem rests in anaconda. It
should have an option to grab
updated packages from the mirror on install while getting the remaining
packages from the Disc.
Stephen
3:32 p.m.
Stephen Mirowski wrote:
[...] This
is a nice band-aid, but the underlining problem rests in anaconda. It
should have an option to grab
updated packages from the mirror on install while getting the remaining
packages from the Disc.
As I understand it, now that Anaconda's installer uses a Yum-based
backend in FC5, one of the goals for FC6+ was to have a true
repository-based network installation option (at least for a base
Core/Extras/Updates configuration).
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
7:41 p.m.
Peter Gordon wrote:
Stephen Mirowski wrote:
> [...] This
> is a nice band-aid, but the underlining problem rests in anaconda.
> It should have an option to grab
> updated packages from the mirror on install while getting the
> remaining packages from the Disc.
As I understand it, now that Anaconda's installer uses a Yum-based
backend in FC5, one of the goals for FC6+ was to have a true
repository-based network installation option (at least for a base
Core/Extras/Updates configuration).
Kick butt.
=)
Stephen
8:07 a.m.
Here, Here ! I happen to be one of those still forced to live in the
stone ages of dial-up. 19.2kbps on a good day. Yum seems to work fine
for updating small packages, but when stuff gets to 1meg, it starts
taking a LONG time. I know this is "my" problem, but I find it
frustrating at times that many forget that not everyone has access to
DSL or some sort of high speed connection. I happen to live in a rural
area where there is no cable, no DSL. Satellite is available if you
want to cough up $600 for equipment and $100 per month for
service...ouch!
-----Original Message-----
From: Jens Petersen [mailto:petersen@redhat.com]
Sent: Thursday, April 27, 2006 9:20 PM
To: For users of Fedora Core releases
Subject: Re: [PHILOSOPHY] Stability and Release Schedules
John Wendel wrote:
> Why not have a continuously evolving
> distribution? One would start by downloading an "installer system"
> that would then use the existing mechanisms (yum, whatever)
to update itself.
> From this point on, why would one need "releases"? Just
keep releasing
> updates and new packages exactly as things are done now.
>
> I know there must be something wrong with this scenario;
would someone
> like to hit me with a clue stick.
For a start not everyone in the world has enough bandwidth for that:
so they need iso images to be able to upgrade for example.
Jens
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
9:40 p.m.
John Wendel wrote:
Here's your chance to slap me up side of the head!
Reading the Debian thread (and others) has made me wonder why Fedora has
to have "releases" at all. Why not have a continuously evolving
distribution? One would start by downloading an "installer system" that
would then use the existing mechanisms (yum, whatever) to update itself.
From this point on, why would one need "releases"? Just keep releasing
updates and new packages exactly as things are done now.
I know there must be something wrong with this scenario; would someone
like to hit me with a clue stick.
Regards,
John
I like a progressively improving system and enjoyed the time that I
participated with the development phases. My last visit was smooth and
the breakage level was lower than previous beta phases. I however recall
the problems that I had when upgrading from one release to another. From
one release to another, there are major changes that happen from release
to release. I was able to work through the obstacles but feel they would
not be as great a factor with an evolving distribution. Releases are
more revolutionary and a lot of people suggest fresh installations
because of the factors a snapshot of releases entails.
In my observation, a progressing release would serve the computer user
better than one release frozen approximately six months between each
other. There are problems that you have to overcome and each project
develops their software during different time frames.
Ideally there would be progression for each project and a base that is
stable to enable the other projects to have a base to rely on.
I'm for a stable base to allow for a more free flowing progression of
all the many packages involved and a distribution that tracks upstream
as closely as possible.
I'm sure there are pros and cons for both scenarios.
Jim
--
Every program has (at least) two purposes:
the one for which it was written and another for which it wasn't.
10:29 p.m.
On Thu, 2006-04-27 at 22:40 -0400, Jim Cornette wrote:
John Wendel wrote:
I'm for a stable base to allow for a more free flowing progression of
all the many packages involved and a distribution that tracks upstream
as closely as possible.
I'm sure there are pros and cons for both scenarios.
I've advocated something similar, where for a several week period,
certain groups of packages are upgraded with time for the users to
bugtest and report what happened to their installations as a result.
Once the noise level drops, get hit with the next group of packages.
Everyone would be on the same page, the developers could focus on just
those issues and progress along with the users. When the test period is
over the proven stable packages would be in the updated system image.
One could burn CD's that contained a stable system. Those who enjoy
cutting edge would 'upgrade' regularly via a yum script for the next set
of installs packages. It's a thought. Those who just want a running
stable system need not apply to the scheme, and just wait until yum
updates to newer proven-stable packages. It's a thought. Ric
10:40 p.m.
Rickey Moore wrote:
On Thu, 2006-04-27 at 22:40 -0400, Jim Cornette wrote:
> John Wendel wrote:
> I'm for a stable base to allow for a more free flowing progression of
> all the many packages involved and a distribution that tracks upstream
> as closely as possible.
>
> I'm sure there are pros and cons for both scenarios.
I've advocated something similar, where for a several week period,
certain groups of packages are upgraded with time for the users to
bugtest and report what happened to their installations as a result.
Once the noise level drops, get hit with the next group of packages.
Everyone would be on the same page, the developers could focus on just
those issues and progress along with the users. When the test period is
over the proven stable packages would be in the updated system image.
One could burn CD's that contained a stable system. Those who enjoy
cutting edge would 'upgrade' regularly via a yum script for the next set
of installs packages. It's a thought. Those who just want a running
stable system need not apply to the scheme, and just wait until yum
updates to newer proven-stable packages. It's a thought. Ric
It sounds like concentration on issues and a smaller area of focus would
be captured with this concept. I do think that putting a time limitation
on the phased update release would rush developers as well as those
testing the updates for problems. Also some developers are dedicated to
networking, kernel, graphical interface, cli applications, security
issues, Internet applications and the like. They would still have to
keep on developing their components and hopefully not be backtracked by
the phased in updates exposing bugs.
On the plus side, these developers can apply any needed changes exposed
by the phased update results. If regression is needed on the phased
update, development should be on track. If major or minor base system
components need revising to progress the phase of updates, the whole lot
of currently being developed packages that depend on components
needing changes has to be implemented.
The quality control should be higher with the two week limited component
updates. That is if reduced amount of released components is traceable
to the problem. Quality might suffer though if the bug is illusive
because it exposed a bug that was not exposed earlier by the changes.
With the different ideas regarding update cycles, progressive releases,
snapshot to snapshot and pruned systems from periodic fresh installs of
resulting snapshots, we can move forward with a better upgrading cycle.
Personally, I like progressive development and a sort of safety net for
testing the updates for a few weeks as you suggested. I believe the
testing repository is setup for this reason.
Jim
--
Is it possible that software is not like anything else, that it is meant to
be discarded: that the whole point is to always see it as a soap bubble?
1:36 p.m.
On Thu, 2006-04-27 at 15:52 -0700, John Wendel wrote:
Here's your chance to slap me up side of the head!
Reading the Debian thread (and others) has made me wonder why Fedora
has to have "releases" at all. Why not have a continuously evolving
distribution? One would start by downloading an "installer system"
that would then use the existing mechanisms (yum, whatever) to update
itself. From this point on, why would one need "releases"? Just keep
releasing updates and new packages exactly as things are done now.
I know there must be something wrong with this scenario; would someone
like to hit me with a clue stick.
dialup users, for one.
I personally would like to see a point release every couple of months or
so that just has updates, and critical anaconda bugs fixes. I know some
people home brew them.
11:31 a.m.
On Thu, 2006-27-04 at 15:52 -0700, John Wendel wrote:
Here's your chance to slap me up side of the head!
Reading the Debian thread (and others) has made me wonder why Fedora
has to have "releases" at all. Why not have a continuously evolving
distribution? One would start by downloading an "installer system"
that would then use the existing mechanisms (yum, whatever) to update
itself. From this point on, why would one need "releases"? Just keep
releasing updates and new packages exactly as things are done now.
I know there must be something wrong with this scenario; would someone
like to hit me with a clue stick.
This thread is to long too read every entry. In case nobody has
mentioned it ;
The reason for releases is to allow for significant changes
to fundamental libraries that could break many things or
require almost every package to be updated at the same time.
I am not completely familiar with Debian, but other OSes use
a similar development/stable branch system. You may have
misread or been mislead, because most similar systems still
have releases for the reasons I stated above, but the only
time the releases change is when a significant change is
made, and not based on a time schedule. Periodically such
systems also have patch releases that fix security or
stability issues and require significant package updates.
11:38 p.m.
Guy Fraser wrote:
I am not completely familiar with Debian, but other OSes use
a similar development/stable branch system. You may have
misread or been mislead, because most similar systems still
have releases for the reasons I stated above, but the only
time the releases change is when a significant change is
made, and not based on a time schedule. Periodically such
systems also have patch releases that fix security or
stability issues and require significant package updates.
Exactly. For example, Gentoo has a similar system, where deemed-stable
packages have an 'arch' keyword, potentially broken but
works-for-the-devs packages are keyworded as '~arch' and known-broken
packages are hardmasked to prevent installation without explicit user
interaction to "unmask" them as needed (where the 'arch' or
'~arch'
keywording is the architecture, such as '~x86', 'sparc', '~mips',
'amd64', et al).
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
6575
days inactive
6581
days old
26 comments
16 participants
participants (16)
-
Dan -
Dave Jones -
Eugen Leitl -
Guy Fraser -
Jens-Ulrik Petersen -
Jim Cornette -
John Wendel -
Les Mikesell -
Mark Haney -
Michael A. Peters -
Mike McCarty -
Peter Gordon -
Ralf Corsepius -
Ric Moore -
Smith, Herb -
spmirowski