Re: Temporal Release Strategy
On Fri, Apr 22, 2005 at 12:02:39PM -0400, Patrick Ouellette wrote:
> On Thu, Apr 21, 2005 at 01:04:34AM +0200, Adrian Bunk wrote:
> > Let my try to explain it:
> >
> >
> > The "debian stable == obsolete" is a release management problem of
> > Debian. One release every year and it would be suitable for most
> > purposes.
>
> This is the problem. Debian has NEVER been able to have a release every
> year. Most server administrators I know would prefer a release cycle
> longer than 12 months, most desktop users would prefer around 12-24
> months.
But this peoblem is not solved by your proposal (and please read my
other email why your proposal won't work).
Your release management has announced that the testing release process
was able to achive this if they drop two thirds of the Debian
architectures.
I'd say the pre-testing was able to achieve this with a dozen
architectures.
> The issue has always been one of "how many RC bugs are acceptable in the
> release" and this has always been at the discretion of the release
> manager.
This number has never been highe than zero [1].
> > You say you've deployed Debian sarge and sid in server environments
> > (even sarge, although months old security fixes might be missing???).
> >
> > Let me ask some questions:
> > - How many thousand people can't continue working if the server isn't
> > available?
> For comparative purposes, I have worked as systems/network/admin where
> the number has been as small as 50 and as large as 30,000.
>
> > - How many million dollar does the customer lose every day the server is
> > not available?
>
> We measured it in millions of dollars per hour, not day.
>
> > - How many days without this server does it take until the company is
> > bankrupt?
>
> We never got to that point, because it was simply not an option.
And critical machines for such a company were running a Debian testing
or unstable???
> > If the mail server of a small company isn't running for a few hours it's
> > not a problem - but there are also other environments.
>
> Since you seem to be trolling, I'll feed the troll: If that small
> company relies on the email server to take orders from customers, that
> few hour outage could translate into a large amount of money. If that
> small company is not financially sound, that few hour outage may be the
> cause of that small business failing. Large organizations are much
I am not trolling.
All I wanted to say is that there are not that much computer-bound small
companies that can live with some outages.
> better equipped to weather a temporary outage (larger cash reserves,
> ability to implement backup systems, etc).
An interesting problem about software bugs is, that they affect backup
systems as well.
>...
> > > >Look at the third use case I explained above. For these users of Debian,
> > > >long-living releases where the _only_ changes are security fixes are
> > > >_very_ important.
> > >
> > > Again, I don't think you ever built a commercial product around Linux
> > > based on your statements here. No offence if you have, maybe it's just
> > > corporate culture differences between the EU and US?
> >
> >
> > There are reasons why companies pay several thousand dollars licence
> > fees for every computer they run the enterprise version of some
> > distribution on. E.g. RedHat supports each version of their enterprice
> > edition for seven years. A few thousand dollars are _nothing_ compared
> > to the support costs and man months that have to be put into setting up
> > and testing the system.
>
> So it should be no problem for those companies who choose to run Debian
> to forward a small donation to Debian for all the thousands they save.
> Or maybe they should allow their staff to spend several hours a week
> getting paid to contribute to Debian.
AFAIK neither money nor human resources are a problem of Debian.
SPI already has more money than plans how to reasonable spand it, and if
manpower was a problem in a project with nearly thousand official and
trusted developers, this would be an organizational problem but not a
problem you could solve by adding more people to the project - people
discovered not less than thirty years ago that adding people to a
project often _increases_ the time until the goal is reached.
> My point is Debian is NOT a corporate product. If it is found to be
> useful by corporations that's great for them. If the corporations want
> to run Debian, there are companies that offer similar support for Debian
> that RedHat and Novell offer for their respective distros.
>
> Since Debian is not a corporate product, Debian is free to investigate
> and try different strategies without worrying about the monetary impact
> of those changes in the same way a corporate distribution has to. We
> can innovate because it makes sense, not because it is good for the
> bottom line.
Debian plans to drop two thirds of it's architectures from it's releases
and Debian could also complete dump stable.
Noone forces Debian to continue stable releases, but you should be aware
that this was a disserve for many of your users - and you have agreed
that your users are your priority.
> > Debian stable is ancient - but that's something you have to ask the
> > Debian release management about. If the officially announced release
> > date for sarge is now missed by more than one and a half years this is
> > the issue where investigation should take place.
> >
>
> Which is the issue I was attempting to suggest a possible solution to.
See my other mail why this doesn't work.
> > Regarding sarge:
> >
> > I do personally know people who had serious mail loss due to #220983. At
> > the time I reported this bug, it was present in sarge. This problem
> > couldn't have happened in a Debian stable (because it would have been
> > discovered before the release would have been declared stable). This
>
> This is the biggest delusion I have ever heard. Any piece of software
> can have a critical and undiscovered bug. Just because it was not
> discovered before someone arbitrarily decided to release it does not
> mean it is not there. If a bug requires an unlikely set of events to
> coincide before it is triggered, it could be YEARS after the software is
> released before the right set of conditions happens.
In this case, the "unlikely set of events" was simply "the glibc
currently in unstable enters testing", and the cyrus-imapd in testing
was immediately broken for all testing users.
Do you really claim this problem wasn't discovered and fixed before a
release?
If "someone arbitrarily decided to release", the release process is
buggy.
A big amount of the good reputation of Debian stable releases comes from
the fact, that they were frozen for several months which shaked out many
bugs. Only a dreamer would expect to get the number of bugs to zero, but
there's a big difference between the number of in testing today and the
number of bugs in a Debian stable (I'm not talking about any bug
metrics, but about the actual and not measurable number of bugs).
> > kind of problems that can occur every day in sarge _are_ dangerous
> > problems.
> >
>
> The kind of bugs yet undiscovered in testing and stable are also
> dangerous, but not as dangerous as believing all the major bugs are
> caught in testing. How many security updates have been issued for
> packages in stable since it was released? "Here there be dragons."
Security problems affect testing no less than stable.
> It is not about presenting a bug free distribution, but about managing
> the risks associated with the bugs that may be undetected at the time
> the release is released. I believe a second stage between testing and
> stable would allow better management of that risk, by providing an
> almost frozen area where further testing of packages would be able to
> take place. The natural progression is then to declare those packages
> "production quality" at some point in time after they entered the candidate
> stage. If you really believe the package to be production quality, you
> should have no problem calling it stable.
Which still leaves my point from my other mail that many packages will
never be able to enter your "candidate"...
> Pat
cu
Adrian
[1] bugs that are for a good reason "sarge-ignore" not counted
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: