so what? Re: Debian development modem
Shaleh
The bigger question is: does it matter? most of us have a stable hamm
system and have had them for a long time. does owning a "official" cd
make any difference. I use the CD once -- when I install. Then it
collects dust. The system ITSELF is stable, rapidly fixed, and all in
all the best Linux I have used. I bought my bo CD a year ago, I had no
idea if Debian was any good. But it had a mailing list FULL of nice and
helpful people and 4.00 for Debian was better than 40.00 for RH (okay so
I am a student). Now I stay with Debian because of its technical
merits. I have become a develop to help the number of bugs grow (-: I
grow tired of these long continuous threads. If you have a problem,
help fix it. Quit complaining and threatening to leave. I was once
told to never trust converts. They have no real dedication. I say the
same to everyone here. We are here becuase we are making OUR linux
better. If CD's are important they will happen. But rather than
releasing shoddy work, we make a well honed product. I can wait for a
WORKING cd. I had to deal with RH at work and know the difference in
quality we make.
--
-----------------------------------------------
How can you see, when your mind is not open?
How can you think, when your eyes are closed?
- Jason Bonham Band, "Ordinary Black and White"
-----------------------------------------------
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Engel
On Wed, May 27, 1998 at 03:38:38PM -0400, Shaleh wrote:
> The bigger question is: does it matter? most of us have a stable hamm
> system and have had them for a long time. does owning a "official" cd
> make any difference. I use the CD once -- when I install. Then it
> collects dust.
Yes, it does matter. I can no longer recommend Debian to my friends
and coworkers, because I don't want to have to tell them the hoops
they have to jump through to get a reasonably current system
installed. I also don't want to have to explain why virtually all of
the pre-compiled or third-party software they will run across will be
in a foreign packaging format, and that even if it can be converted to
a native format, it still may not work for them.
> The system ITSELF is stable, rapidly fixed, and all in
> all the best Linux I have used. I bought my bo CD a year ago, I had no
> idea if Debian was any good.
No argument here. Quality-wise Debian is head and shoulders above
every other LInux distribution I've seen. Unfortunately, only the
Debian developers and small percentage of Linux users ever get to see
the quality because it never gets released.
> I
> grow tired of these long continuous threads. If you have a problem,
> help fix it. Quit complaining and threatening to leave. I was once
> told to never trust converts. They have no real dedication. I say the
> same to everyone here.
How long have you been working on Debian? I've been working on it
since the 0.92 days. That must be at least 4 years. For way too
long, I maintained all of the core development packages, libc4/5/6,
gcc, binutils, etc. I laid the groundwork for both of the major libc
transitions (4 to 5 and 5 to 6), and spent countless hours porting and
rebuilding other developer's packages to help speed things along.
Both times, it took a year or more before that work was released.
You might be asking now, "Well if you did all this before, why haven't
I heard of you and why aren't you doing anything now. The reason is
that I finally got fed up with all of the inane flame wars and power
plays that seemed to erupt every 2-3 months. For the last year, I
decided to keep a low profile, maintain my own packages and see what
happened. You know what happened? The same old things, flame wars,
power play and no releases.
Perhaps you understand now why I'm so frustrated.
> We are here becuase we are making OUR linux
> better. If CD's are important they will happen. But rather than
> releasing shoddy work, we make a well honed product.
No, until you release something, there is NO product, at least not one
ordinary users are willing to use. What you have right now is a
quaint, little, community-supported Linux distribution. And that's
all it will ever be until things change.
David
--
David Engel ODS Networks
da...@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
Andreas Jellinghaus
>But it had a mailing list FULL of nice and helpful people and 4.00 for Debian
>was better than 40.00 for RH (okay so I am a student).
if you buy debian, you only buy a cdrom with sutff on it.
if you buy a cheapbytes cdrom of xxx, you only buy a cdrom with stuff on it.
but if you buy a commercial linux distribution, you are buying support,
a book, sample version of commercial software.
ok, a cd with stuff of it is also included (only because you couldn't sell
support and the book without it).
it isn't fair to compair that.
andreas
Bill Mitchell
On Wed, 27 May 1998, Shaleh wrote:
> The bigger question is: does it matter? most of us have a stable hamm
> system and have had them for a long time. does owning a "official" cd
> make any difference. I use the CD once -- when I install. Then it
> collects dust. <snip>
> <snip> If CD's are important they will happen. But rather than
> releasing shoddy work, we make a well honed product. I can wait for a
> WORKING cd. I had to deal with RH at work and know the difference in
> quality we make.
I am located in the Philippines. I get download speeds in the hundreds
of bytes per second when my ISP is up, and my ISP has frequent outages.
I can download the occasional package, but downloading more than a few
megabytes is painful (at 300 bytes per second, I get roughly a megabyte
per hour). Those of us without high speed internet access _need_ CDs.
As a practical matter, the latest debian system release available to me
is whatever I can get on mail-order CD.
Shaleh
I have not been paying attention that long and for that -- I apologize.
Frankly this is where the problem is coming from -- a group wants to be
a RH competitor in market share or whatever and a group which wants to
maintain a community product. I can not see the too existing. RH makes
it to deadline for two reasons: they cut corners and they have paid
staff who can be dedicated to the work. This is the same resaon you see
more R&D from them. I guess the only real solution to to get everyone
to stop and vote for a purpose and let those who want to leave go their
own way. Until this happens the current situation will not change.
Although some may not see this as a problem. Debian is not a single
goal project like kernel development or making a new window manager. SO
it is harder to shoe horn into a set path.
--
-----------------------------------------------
How can you see, when your mind is not open?
How can you think, when your eyes are closed?
- Jason Bonham Band, "Ordinary Black and White"
-----------------------------------------------
Dale Scheetz
On Thu, 28 May 1998, Bill Mitchell wrote:
>
> I am located in the Philippines. I get download speeds in the hundreds
> of bytes per second when my ISP is up, and my ISP has frequent outages.
> I can download the occasional package, but downloading more than a few
> megabytes is painful (at 300 bytes per second, I get roughly a megabyte
> per hour). Those of us without high speed internet access _need_ CDs.
> As a practical matter, the latest debian system release available to me
> is whatever I can get on mail-order CD.
>
I just finished testing the new master I made of the 1.3.1R8 bo archive.
I included a directory called pre-2.0-upgrade which contains all of the
packages neede to transition from 1.3 to 2.0, and a script that installs
them. This upgrades to libc6 and bash, providing the perl that the new
dpkg will need and then installing it as well. This leaves the system with
libc5 development installed but provides libc6 and tools needed for the
upgrade with dselect or apt (once you install apt, that is).
Sorry for the shameless plug,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dw...@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Raul Miller
David Engel <da...@ods.com> wrote:
> Yes, it does matter. I can no longer recommend Debian to my friends
> and coworkers, because I don't want to have to tell them the hoops
> they have to jump through to get a reasonably current system
> installed. I also don't want to have to explain why virtually all of
> the pre-compiled or third-party software they will run across will be
> in a foreign packaging format, and that even if it can be converted to
> a native format, it still may not work for them.
Is it as simple as cutting more releases?
Let's say that every three months we split off an unstable version and
froze then released what we had at that point. Do you see any problems
with this?
--
Raul
Hamish Moffatt
On Wed, May 27, 1998 at 03:38:38PM -0400, Shaleh wrote:
> The bigger question is: does it matter? most of us have a stable hamm
> system and have had them for a long time. does owning a "official" cd
> make any difference. I use the CD once -- when I install. Then it
> all the best Linux I have used. I bought my bo CD a year ago, I had no
This is fine if you want the distribution just to be for developers
and highly technical users. I do think we need official releases
and official CDs. I still have a bo machine (deliberately, until hamm's
release) and I'm not about to do a net upgrade on it now, will take too
longer (I just have a modem link).
Hamish
--
Hamish Moffatt, ham...@debian.org, ham...@rising.com.au, hmof...@mail.com
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
David Engel
On Wed, May 27, 1998 at 08:14:56PM -0400, Raul Miller wrote:
> Is it as simple as cutting more releases?
>
> Let's say that every three months we split off an unstable version and
> froze then released what we had at that point. Do you see any problems
> with this?
If only it were that simple. Personally, I think a release every 4 to
5 months is about right. However, testing and actually preparing a
release are not fun. With a volunteer organization such as Debian,
there has to be a commitment, starting at the top and running all the
way down, to get the dirty work done, even if it means putting a
complete (but temporary) stop to all other development work.
David
--
David Engel ODS Networks
da...@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
David Engel
On Wed, May 27, 1998 at 07:07:14PM -0400, Shaleh wrote:
> I have not been paying attention that long and for that -- I apologize.
Apology accepted. I've been here a long time and seen the same
problems come up over and over again. That's part of why I'm so
passionate about this.
> Frankly this is where the problem is coming from -- a group wants to be
> a RH competitor in market share or whatever and a group which wants to
> maintain a community product. I can not see the too existing.
I think that's defeatist. I know Debian can't be everything to
everyone, but I do know it can be a lot more than it currently is.
> RH makes
> it to deadline for two reasons: they cut corners and they have paid
> staff who can be dedicated to the work. This is the same resaon you see
They also know their limits and don't try to include anything and
everything. There are somes things that have limited enough scope
that should be left for "contrib" status.
> more R&D from them. I guess the only real solution to to get everyone
> to stop and vote for a purpose and let those who want to leave go their
> own way. Until this happens the current situation will not change.
Agreed. However, I'd rather it be polling than voting. To me, voting
connotes a democratic process and I've come to the belief that Debian
can not effectively be run that way. That doesn't mean that the
developers shouldn't have a voice in things (they can still "vote"
with their feet, after all). It does mean, though, that somebody has
to be in charge to make the tough decisions, even when they are
unpopular, to keep the entire project on course.
> Although some may not see this as a problem. Debian is not a single
> goal project like kernel development or making a new window manager. SO
> it is harder to shoe horn into a set path.
I disagree. Ask Linus if managing the kernel development is a single
goal project. :) In fact, I would go so far as to say that managing
the kernel is very much like managing Debian. If Linus can do it
effectively for the kernel, surely it can also be done for Debian.
Buddha Buck
> On Wed, May 27, 1998 at 08:14:56PM -0400, Raul Miller wrote:
> > Is it as simple as cutting more releases?
> >
> > Let's say that every three months we split off an unstable version and
> > froze then released what we had at that point. Do you see any problems
> > with this?
>
> If only it were that simple. Personally, I think a release every 4 to
> 5 months is about right. However, testing and actually preparing a
> release are not fun. With a volunteer organization such as Debian,
> there has to be a commitment, starting at the top and running all the
> way down, to get the dirty work done, even if it means putting a
> complete (but temporary) stop to all other development work.
Before work started on Hamm, there was plans to do exactly that --
periodic releases every 3-4 months. This was because we had such a
problem with missing deadlines.
However, do keep in mind: We have had two major flag-day releases
recently. 1.1 was delayed for a -long- time while we worked out the
details of the a.out->ELF transition, and 2.0 is delayed as well
because of the libc5->libc6 transition.
Both of those transitions required all the packages to be recompiled to
new standards. To be fair, the libc6 conversion is complete, and we
also used the time to do other major overhauls (such as how we handle
Emacs, TeX, etc, and getting the window managers to work with the
menuing system). These overhauls also take time.
We also took the time to improve the behind-the-scenes issues, like
revamping the source packaging system, and overhauling the packaging
system. We have greatly improved the ease of maintaining the
distribution as well, with more mirrors, new hardware for master, and
better helper scripts for building, checking, uploading, and processing
packages.
Also, 1.3 was a very successful release, and caused a -tremendous-
amount of growth in Debian as well. My available list shows nearly
2000 packages (double that of 1.3), and we are forced to go to three
CD's. Since the libc6 transition, as well as everything else we tried
to do for 2.0, took so long, this growth is being absorbed into 2.0.
This added complexity is making the release take even longer.
But it is almost done. 2.0 is in a deep freeze right now, there is
only about 100 release-critical bugs left, and some of those will be
fixed by pulling the packages (not to pick on anything specific here,
but is there any reason to have a non-free, libc5 "swish" (with a
16-month release-critical bug) and a free, libc6 "swish-e"?). We
should be releasing 2.0 very soon. The only major stumbling block will
be figuring out how to split it across several CD's.
2.0 is a -big- improvement over 1.3. But it also did most of the big
changes. I expect 2.1 to be a -much- simpler, faster, undertaking than
2.0.
>
> David
> --
> David Engel ODS Networks
> da...@sw.ods.com 1001 E. Arapaho Road
> (972) 234-6400 Richardson, TX 75081
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>
--
Buddha Buck bmb...@acsu.buffalo.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Rev. Joseph Carter
> > The bigger question is: does it matter? most of us have a stable hamm
> > system and have had them for a long time. does owning a "official" cd
> > make any difference. I use the CD once -- when I install. Then it
> > collects dust.
>
> and coworkers, because I don't want to have to tell them the hoops
> they have to jump through to get a reasonably current system
> installed.
I'm working on getting a way to mirror the current stuff so I can have CDs
burned for friends and the like.
> I also don't want to have to explain why virtually all of
> the pre-compiled or third-party software they will run across will be
> in a foreign packaging format, and that even if it can be converted to
> a native format, it still may not work for them.
I've made comments to this effect before and nobody seems to hear them. I
really dislike rpm for many reasons, but unless we give everyone really
significant reason to package .deb's, they won't. Most who make their stuff
available as .rpm are using FHS which is how Redhat does things. Debian
doesn't use this and most people don't wanna patch their stuff to fit just
Debian. Also that Debian and Redhat don't agree on package names at all.
I know a lotta people don't like Redhat, but for the sake of our dist, a
little cooperation between them and us is really a good idea. For this
reason the Linux standard base everyone keeps talking about sounds like a
VERY GOOD THING.
> > The system ITSELF is stable, rapidly fixed, and all in
> > all the best Linux I have used. I bought my bo CD a year ago, I had no
> > idea if Debian was any good.
>
> No argument here. Quality-wise Debian is head and shoulders above
> every other LInux distribution I've seen. Unfortunately, only the
> Debian developers and small percentage of Linux users ever get to see
> the quality because it never gets released.
A lot of the bugs are with a lot of packages that a lot of people don't use
I have seen. Perhaps we should consider moving away from versioned dists
and move to a date-based dist in which all new packages start out in an
unstable area and after some criteria is met (time for people using it to
find bugs, any serious bugs being squashed) these packages could be
considered stable...
This sort of design would allow people who need stable systems to be running
a reasonably stable system. A lot of what is in hamm now could easily be
called stable. A lot of what's in hamm around December of last year (when I
upgraded to it) could be called stable for that matter.
I'd like to know what people think about this. Having not been a Linux user
for more than 6 months, perhaps I'm way off base on this. If I'm not, it'd
make updates happen to the stable tree more often, CD-ROM publishers will
have more chances to sell CDs (or subscriptions for latest CDs) and all in
all things would run smoother IMO..
The downside is the amount of work this would take. Certainly not wise
before hamm is out (duh) and maybe not even in time for slink--even if
everybody likes it.
The other thought someone had was have a more centralized Debian core dist
which is released independantly of the larger Debian dist.. I think the
Linux standard base thing will do some of this for us if it takes off so it
won't be as important then.
> How long have you been working on Debian? I've been working on it
> since the 0.92 days. That must be at least 4 years. For way too
> long, I maintained all of the core development packages, libc4/5/6,
> gcc, binutils, etc. I laid the groundwork for both of the major libc
> transitions (4 to 5 and 5 to 6), and spent countless hours porting and
> rebuilding other developer's packages to help speed things along.
> Both times, it took a year or more before that work was released.
I've watched some of this. Current attempts to curb some of this may or may
not work well or even at all. I'm hoping.
> You might be asking now, "Well if you did all this before, why haven't
> I heard of you and why aren't you doing anything now. The reason is
> that I finally got fed up with all of the inane flame wars and power
> plays that seemed to erupt every 2-3 months. For the last year, I
> decided to keep a low profile, maintain my own packages and see what
> happened. You know what happened? The same old things, flame wars,
> power play and no releases.
>
> Perhaps you understand now why I'm so frustrated.
>
> > We are here becuase we are making OUR linux
> > better. If CD's are important they will happen. But rather than
> > releasing shoddy work, we make a well honed product.
>
> No, until you release something, there is NO product, at least not one
> ordinary users are willing to use. What you have right now is a
> quaint, little, community-supported Linux distribution. And that's
> all it will ever be until things change.
Linux for world domination! => Debian Linux if we can ever get the $@*)&$
thing out the door. I'm working on some small bugs in packages I use. I'll
make NMU of anything I fix satisfactorally. Eventially I'd like to become a
real maintainer, but I don't have anything to maintain yet and am still
ironing out some details of policy interpretation and understanding
debhelper to avoid losing the sanity I have left.
Rev. Joseph Carter
> > and coworkers, because I don't want to have to tell them the hoops
> > they have to jump through to get a reasonably current system
> > the pre-compiled or third-party software they will run across will be
> > in a foreign packaging format, and that even if it can be converted to
> > a native format, it still may not work for them.
>
To many, yes.
> Let's say that every three months we split off an unstable version and
> froze then released what we had at that point. Do you see any problems
> with this?
No, but I think I might have an idea.. Instead of trying to make everything
stable all at once, put what's stable in the stable tree as it gets that
way. Every couple of months (or perhaps every couple of SERIOUSLY IMPORTANT
upgrades like to fix major exploits and the like) the CD makers can send out
new snapshots of stable..
This would make version numbering kinda useless (which for a dist I always
thought it was anyway), get newer software out as it's ready to be out
rather than as EVERYTHING is ready to be out, etc..
James A.Treacy
> A lot of the bugs are with a lot of packages that a lot of people don't use
> I have seen. Perhaps we should consider moving away from versioned dists
> and move to a date-based dist in which all new packages start out in an
> unstable area and after some criteria is met (time for people using it to
> find bugs, any serious bugs being squashed) these packages could be
> considered stable...
>
contributing to the testing project.
I have thought a (little) bit about a system along the lines you mention.
We could create a web page for every package in unstable that hasn't gone
into stable yet. When someone has installed a package, they could go to the
page for that package and fill out a form. The package can get into stable
only when certain criteria have been met. The criteria could depend on the
package. For a simple library, having 5 people install and use it (and fill
out the form) might be sufficient. A package with a lot more users might
require more responses, e.g. TeX needs 20 people to fill out the form.
A package which requires configuration (like smail) may not only need
a larger number of people to fill out the form, but a sufficient number
of people with each type of configuration (the form provides a list).
There are two problems with this. First is security. We want all users to
be able to fill out the forms, but how do we keep evil minded people from
ruining the results. Second, is designing a framework that is simple, but
accomplishes the required goals.
If simple is the right way to go, there could simply be a line in the
control file specifying the number of people that need to fill out the form
(with a positive response) before the package is allowed into stable.
There are a number of issues that I have intentionally ignored in this. I
am just throwing this out to see what people think.
Jay Treacy
Rev. Joseph Carter
> There are a lot of people using packages every day that aren't formally
> contributing to the testing project.
Yes, but many of these users DO contribute bug reports. I think the biggest
hurdle to the system I've suggested is that bug.debian.org has several long
outstanding bugs on it.
> I have thought a (little) bit about a system along the lines you mention.
> We could create a web page for every package in unstable that hasn't gone
> into stable yet. When someone has installed a package, they could go to
> the page for that package and fill out a form. The package can get into
> stable only when certain criteria have been met. The criteria could depend
> on the package. For a simple library, having 5 people install and use it
> (and fill out the form) might be sufficient. A package with a lot more
> users might require more responses, e.g. TeX needs 20 people to fill out
> the form. A package which requires configuration (like smail) may not only
> need a larger number of people to fill out the form, but a sufficient
> number of people with each type of configuration (the form provides a
> list).
This is an interesting way to do it. I have a better idea though. =>
Urgency in the control file. Urgency of most packages is low. These
packages can be considered unstable perhaps a month. If no "release
critical" bugs are outstanding on this version of the package (not
subversion) it can be moved to stable. So my_package 1.4.2-1 has a grave or
critical bug in it. Two weeks later, 1.4.2-2 fixes it. In another 2 weeks,
it could go stable.. There might need to be some exceptions, but usually
the places exceptions are needed shouldn't be low urgency, hm?
Medium and high urgency would of course be shorter times since they are
higher urgency for reasons. I might suggest adding an urgency critical or
very_high or whatever you wanna call it then for things like patches to IP
exploits in a stable kernel. => These things CANNOT wait.
> There are two problems with this. First is security. We want all users to
> be able to fill out the forms, but how do we keep evil minded people from
> ruining the results. Second, is designing a framework that is simple, but
> accomplishes the required goals.
>
> If simple is the right way to go, there could simply be a line in the
> control file specifying the number of people that need to fill out the
> form (with a positive response) before the package is allowed into stable.
mmm I can see one more problem with this: I for one sure won't take the
time to do this by hand and there's no way in hell I'm gonna let the system
automagically report what software I'm using. I think instead fixing the
bug system would be better.
It's been mentioned that Debian developers are kinda skitzophrenic.. Some
want a community development where everyone's contributions matter and
anyone can contribute and any release we make is solid. Others want
consistant releases with the latest stuff so they don't have to be part of
the development community and able to fix any problems that crop up to get
newer software with recent features.
This would IMO be a MORE community based organization and would get software
that is ready for release out a lot sooner, hopefully satisfying more
people, INCLUDING the CD-ROM vendors who kinda like having new product to
sell every few months.. Some of their customers (me) will probably quite
frequently buy the newest CD-ROMs just so I have installation media of
fairly recent (even if out of date by a month or two) software. I run slink
packages now, but still plan to buy a hamm CD set when it ships for that
reason.
> There are a number of issues that I have intentionally ignored in this. I
> am just throwing this out to see what people think.
Like the privacy issue? =>
The BIGGEST issue about any idea of the sort starting with mine, including
yours, and several others like it is this: Can stable actually be kept
stable in a system like this or would compromises cause stability to go
down? I think probably we could do it since hopefully the above suggestions
I made as for what it would take to get a package in to stable faster would
be policy. Thoughts anyone?
Enrique Zanardi
On Thu, May 28, 1998 at 12:01:04AM -0400, Buddha Buck wrote:
> > On Wed, May 27, 1998 at 08:14:56PM -0400, Raul Miller wrote:
> > > Is it as simple as cutting more releases?
> > >
> > > froze then released what we had at that point. Do you see any problems
> > > with this?
> >
On the libc6 transition issue. Following Brian schedule, every library
should have been recompiled with libc6 on July/August 1997. Guess?
Only a few were! Three months later there were important packages that
still were libc5-based. That's part of the "dirty work" that has to be
done, and it seems not every contributor has enough time to do (Real Life
tends to require 36-hour days).
Of course we've done improvements, but we tend to concentrate in some
parts and leave the rest behind. Thus the distribution doesn't evolutes
as a whole, and problems accumulate until the release date is near.
Take a look at hamm as it was last January. Look at it now. What big
improvements have been made in those four months? And in the last two
months? As have been said already, we make a very good pre-release
distribution, but then spend a huge amount of time fixing those problems
that we haven't pay a lot of attention at.
To make it worse, when release date is near some good development
projects are stopped or delayed until the release is made, (dpkg,
boot-floppies next generation, FHS compliance ...). If we spend a few
months in "near-release-state", those projects lose momentum, and Debian
lose technological lead. And that hurts everyone, user or developer!
With more coordination, a clear schedule, and easy (and more frequent)
maintainer collaboration/replacement to fix those packages that didn't
follow the schedule we would do it better.
If that means we have to break main in "core" and "non-core" and develop
different rules (different schedules, different testing procedures) for
each set, to ease management, let's do it.
--
Enrique Zanardi ezan...@ull.es
Edward Betts
On Wed, 27 May, 1998, Raul Miller wrote:
> Is it as simple as cutting more releases?
>
> Let's say that every three months we split off an unstable version and
> froze then released what we had at that point. Do you see any problems
> with this?
Yes, Yes, Yes, Please
My little 28.8k modem will never download the whole of debian every 3
months to keep it up to unstalbe, I would some burned CDs and having it
stable would be an added bonus.
Yes, Yes, Yes, Please
Has anything major changed in Debain over the last 3 months, is it
considerably more stable than 3 months ago or code there have been a code
freeze and release 3 months ago???
Yes, Yes, Yes, Please
--
Edward Betts http://www.hairnet.demon.co.uk/
Vincent Renardias
On Wed, 27 May 1998, David Engel wrote:
> On Wed, May 27, 1998 at 08:14:56PM -0400, Raul Miller wrote:
> > Is it as simple as cutting more releases?
> >
> > Let's say that every three months we split off an unstable version and
> > froze then released what we had at that point. Do you see any problems
> > with this?
>
> If only it were that simple. Personally, I think a release every 4 to
> 5 months is about right. However, testing and actually preparing a
> release are not fun. With a volunteer organization such as Debian,
> there has to be a commitment, starting at the top and running all the
> way down, to get the dirty work done, even if it means putting a
> complete (but temporary) stop to all other development work.
Both the NetBSD & OpenBSD groups have 2 scheduled releases each year: one
on June 15th, and one on December 15th. I'd be in favor of adopting a
similar release schedule for Debian.
If we decide to do so, we must consolidate the testing team to be able to
test&fix the release within the current schedule, but I don't think it's
impossible to do.
Cordialement,
--
- Vincent RENARDIAS vincent@{waw.com,pipo.com,debian.org} -
- Debian/GNU Linux: Pipo: WAW: -
- http://www.fr.debian.org http://www.pipo.com http://www.waw.com -
---------------------------------------------------------------------------
- "La fonctionnalite Son Visuel vous delivre des avertissements visuels." -
- [Message durant l'installation de Windows95]:wq
Michael Meskes
David Engel writes:
> Yes, it does matter. I can no longer recommend Debian to my friends
> and coworkers, because I don't want to have to tell them the hoops
> they have to jump through to get a reasonably current system
> installed. I also don't want to have to explain why virtually all of
> the pre-compiled or third-party software they will run across will be
> in a foreign packaging format, and that even if it can be converted to
> a native format, it still may not work for them.
Boy, I know this. I've seen way too many test Debian and switch back because
of these problems.
> No argument here. Quality-wise Debian is head and shoulders above
> every other LInux distribution I've seen. Unfortunately, only the
> Debian developers and small percentage of Linux users ever get to see
> the quality because it never gets released.
And now we're back into the marketing debate we had a short time ago.
> How long have you been working on Debian? I've been working on it
> since the 0.92 days. That must be at least 4 years. For way too
> long, I maintained all of the core development packages, libc4/5/6,
> gcc, binutils, etc. I laid the groundwork for both of the major libc
> transitions (4 to 5 and 5 to 6), and spent countless hours porting and
> rebuilding other developer's packages to help speed things along.
> Both times, it took a year or more before that work was released.
I entered the project late in 1994 and that was after 0.93. Back when I was
working at the university (and thus had more time) I did port many to libc5
too. I do understand what you mean even if I spend less time on the topic. I
hate the idea of spending so much time for a project that's killing itself.
> Perhaps you understand now why I'm so frustrated.
Oh yes, I do.
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
mes...@topsystem.de | Europark A2, Adenauerstr. 20
mes...@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
Ian Jackson
I see one big reason why hamm is taking so long to release: it's not
compatible with bo.
This has made developers (many of whom were attracted by Debian's
incremental and partial upgrade capability) very reluctant to
upgrade. It has also made it impossible to fix bugs in bo.
Let us never make this mistake again.
We should, instead, simply freeze unstable every six months, and
release it three months or so later. A package should be allowed into
frozen (or stable) if it would improve the quality of the
distribution.
We have often good backwards compatibility, so that it doesn't matter
if our stable distribution is a mixture of a.out and ELF or libc5 and
libc6.
Ian.
Meskes, Michael
IMO six months is too long. How about freeze every three months and
release twice a year at fixed dates? Something like the NetBSD schedule.
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
mes...@topsystem.de | Europark A2, Adenauerstr. 20
mes...@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
Raul Miller
Ian Jackson <i...@chiark.greenend.org.uk> wrote:
> We have often good backwards compatibility, so that it doesn't matter
> if our stable distribution is a mixture of a.out and ELF or libc5 and
> libc6.
Absolutely.
If we go back and look at the discussion at the beginning of hamm,
there was this idea that we had to go all the way to libc6 in one
jump "to pressure developers into migrating to libc6".
I suspect that if we'd have focussed on a libc6 development environment
that run under libc5, and built up from there, that we'd have gotten
a fully libc6 release sooner.
--
Raul
Alex Yukhimets
> This has made developers (many of whom were attracted by Debian's
> incremental and partial upgrade capability) very reluctant to
> upgrade. It has also made it impossible to fix bugs in bo.
True.
> Let us never make this mistake again.
> We have often good backwards compatibility, so that it doesn't matter
> if our stable distribution is a mixture of a.out and ELF or libc5 and
> libc6.
It would not be that easy for FSSTD/FHS mix I guess :)
That's why I would propose not have FHS-compliance goal for 2.1 release.
Instead, work on 2.1 as a "bugfix", simple package upgrade release, apt?,
and in parallel for FHS transition.
Thanks.
Alex Y.
--
_
_( )_
( (o___ +-------------------------------------------+
| _ 7 | Alexander Yukhimets |
\ (") | http://pages.nyu.edu/~aqy6633/ |
/ \ \ +-------------------------------------------+
Raul Miller
We'd have to tolerate a mix for transition release(s), that's all.
--
Raul
Raul Miller
Rev. Joseph Carter <kngh...@earthlink.net> wrote:
> This is an interesting way to do it. I have a better idea though. =>
> Urgency in the control file. Urgency of most packages is low. These
> packages can be considered unstable perhaps a month. If no "release
> critical" bugs are outstanding on this version of the package (not
> subversion) it can be moved to stable. So my_package 1.4.2-1 has a grave or
> critical bug in it. Two weeks later, 1.4.2-2 fixes it. In another 2 weeks,
> it could go stable.. There might need to be some exceptions, but usually
> the places exceptions are needed shouldn't be low urgency, hm?
In what way would urgency be different from priority?
> The BIGGEST issue about any idea of the sort starting with mine, including
> yours, and several others like it is this: Can stable actually be kept
> stable in a system like this or would compromises cause stability to go
> down? I think probably we could do it since hopefully the above suggestions
> I made as for what it would take to get a package in to stable faster would
> be policy. Thoughts anyone?
I think that if we decided we cared we'd do a lot about it.
Hamish Moffatt
On Thu, May 28, 1998 at 01:02:45PM +0200, Vincent Renardias wrote:
> Both the NetBSD & OpenBSD groups have 2 scheduled releases each year: one
> on June 15th, and one on December 15th. I'd be in favor of adopting a
> similar release schedule for Debian.
Nice dates, the latter will be a nice birthday present for me :-)
Hamish
--
Hamish Moffatt, ham...@debian.org, ham...@rising.com.au, hmof...@mail.com
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Carlos Barros
On Thu, 28 May 1998, Bill Mitchell wrote:
> > <snip> If CD's are important they will happen. But rather than
> > releasing shoddy work, we make a well honed product. I can wait for a
> > WORKING cd. I had to deal with RH at work and know the difference in
> > quality we make.
>
> I am located in the Philippines. I get download speeds in the hundreds
> of bytes per second when my ISP is up, and my ISP has frequent outages.
> I can download the occasional package, but downloading more than a few
> megabytes is painful (at 300 bytes per second, I get roughly a megabyte
> per hour). Those of us without high speed internet access _need_ CDs.
> As a practical matter, the latest debian system release available to me
> is whatever I can get on mail-order CD.
Even that I'm a hostmaster here in Uruguay, I have a 64K line... and
as good transfer rate is about 4KB(~4:00 am) that's why CD's are
needed here...
Bye
Carlos Barros.
Meskes, Michael
Sorry, now I don't understand. I think we should release twice a year.
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
mes...@topsystem.de | Europark A2, Adenauerstr. 20
mes...@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
> -----Original Message-----
> From: Raul Miller [SMTP:r...@test.legislate.com]
> Sent: Thursday, May 28, 1998 4:07 PM
> To: Meskes, Michael; 'Ian Jackson'; Debian developers list
> Subject: Re: so what? Re: Debian development modem
>
> Meskes, Michael <mes...@topsystem.de> wrote:
> > IMO six months is too long. How about freeze every three months and
> > release twice a year at fixed dates? Something like the NetBSD
> schedule.
>
> I don't understand. Why freeze when we're not going to release?
>
> [I can see pipelining the process, allowing unstable development
> to go forward while we've got a freeze going, as long as the
> freeze takes priority.]
>
> --
> Raul
Raul Miller
Dale Scheetz
On Thu, 28 May 1998, Meskes, Michael wrote:
> IMO six months is too long. How about freeze every three months and
> release twice a year at fixed dates? Something like the NetBSD schedule.
Twice a year IS once every six months. If you freeze every three months
you get 4 releases per year.
A freeze every six months with a 3 month testing cycle to release, gets
two releases out every 12 months.
The problems that I see with this, are just the problems we have had while
trying to get hamm to a release...bo gets no attention. It is the overlaps
that cause problems.
If, on the other hand what you meant was: Three months of development,
followed by three months of testing frozen to produce a release, then
there is no overlap and attention is being payed to only the release under
development.
I see this as requiring some direction and control over the development
effort. It will require that maintainers who want to work on packaging for
the "next" release, will hold that work until work begins on that next
release, so as not to clutter up the current release. A well defined set
of simple goals for each release cycle would expidite the schedule.
Our current problem with releasing 2.0 is that we took on goals that were
too complex for a simple release cycle. It was necessary in this case, but
we should work harder in the future at keeping a more narrow focus on
short term goals when working on a release.
We still need to be able to run projects (like apt) which are not strictly
tied to any particular release, but grow slowly from release to release.
Part of the difficulty is keeping those projects active without impacting
release schedules.
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dw...@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Meskes, Michael
So I misunderstood the original mail. Yes, you were right I meant the 3
month development + 3 months freeze. But that one could contain some
development for the next version, as we do now. The problem as I see it,
is that there are major bugs in hamm that no one cares about, because we
are already working on slink. I still don't fully understand why we
can't get hamm out of the door.
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
mes...@topsystem.de | Europark A2, Adenauerstr. 20
mes...@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
Dale Scheetz
On Thu, 28 May 1998, Meskes, Michael wrote:
> So I misunderstood the original mail. Yes, you were right I meant the 3
> month development + 3 months freeze. But that one could contain some
> development for the next version, as we do now. The problem as I see it,
> is that there are major bugs in hamm that no one cares about, because we
> are already working on slink. I still don't fully understand why we
> can't get hamm out of the door.
>
Well, as I see it there are two major issues, one of which is my
responsibility.
First, we are waiting on an upstream release of 2.0.7 glibc (any day now)
which will, hopefully fix several package problems.
Second, the major need for a release is to have a functioning set of
installation disks. As several of the crucial packages were converted to
slang "at the last minute" they have taken some time to stabalize out. It
appears that the most recent disk set is well on the way to being release
ready.
Once these two criterion have been met we only need to determine which
bugs stand in the way of a release and fix them...sounds too simple ;-)
Brandon Mitchell
On Thu, 28 May 1998, Edward Betts wrote:
> Has anything major changed in Debain over the last 3 months, is it
> considerably more stable than 3 months ago or code there have been a code
> freeze and release 3 months ago???
The installation disk and apt to name a few.
<flame>
If you want a release every few months, go with a distributor that
distributes unstable and untested releases (redhat comes to mind).
</flame>
We are only volunteers, and even the critical elements (like the boot
disks) only move as fast as the people who work on them move. If you
really wanted a cd, someone would have probably made one from unstable
for you. I'd prefer if debian not put the stable sticker on something
just because we hit a 3 month mark (I know there was more to the request
than just that, I just fear this result in the long run).
Brandon
Rev. Joseph Carter
> Our current problem with releasing 2.0 is that we took on goals that were
> too complex for a simple release cycle. It was necessary in this case, but
> we should work harder in the future at keeping a more narrow focus on
> short term goals when working on a release.
I'm not so sure. It would have been possible to focus primarily on libc6
but still leave room for libc5, which was the big transition. I think not
every package need be FHS for 2.1 though, as long as critical ones are.
Rev. Joseph Carter
> Rev. Joseph Carter <kngh...@earthlink.net> wrote:
> > This is an interesting way to do it. I have a better idea though. =>
> > Urgency in the control file. Urgency of most packages is low. These
> > packages can be considered unstable perhaps a month. If no "release
> > critical" bugs are outstanding on this version of the package (not
> > subversion) it can be moved to stable. So my_package 1.4.2-1 has a grave or
> > critical bug in it. Two weeks later, 1.4.2-2 fixes it. In another 2 weeks,
> > it could go stable.. There might need to be some exceptions, but usually
> > the places exceptions are needed shouldn't be low urgency, hm?
>
> In what way would urgency be different from priority?
afaik, they're the same thing. The entry in the control file is "Urgency"
though.
> > The BIGGEST issue about any idea of the sort starting with mine, including
> > yours, and several others like it is this: Can stable actually be kept
> > stable in a system like this or would compromises cause stability to go
> > down? I think probably we could do it since hopefully the above suggestions
> > I made as for what it would take to get a package in to stable faster would
> > be policy. Thoughts anyone?
>
> I think that if we decided we cared we'd do a lot about it.
I think this would be a better system than freezing unstable now and then
for testing and release because you wouldn't be trying to get EVERYTHING
updated and tested all the time.
Raul Miller
Meskes, Michael <mes...@topsystem.de> wrote:
> So I misunderstood the original mail. Yes, you were right I meant the 3
> month development + 3 months freeze. But that one could contain some
> development for the next version, as we do now. The problem as I see it,
> is that there are major bugs in hamm that no one cares about, because we
> are already working on slink. I still don't fully understand why we
> can't get hamm out of the door.
First time I heard about this.
I thought that we had some people in the critical path who were
working just as hard as they could to get hamm released.
--
Raul
The Gecko
On 28-May-98 Rev. Joseph Carter wrote:
> No, but I think I might have an idea.. Instead of trying to make everything
> stable all at once, put what's stable in the stable tree as it gets that
> way. Every couple of months (or perhaps every couple of SERIOUSLY IMPORTANT
> upgrades like to fix major exploits and the like) the CD makers can send out
> new snapshots of stable..
I thought, in general, Debian came out every few months with a new release.
The delay with 2.0 was glibc6 and Red Hat is faster with that because they pay
their programmers. After 2.0 is released, we should probably be able to count
on Debian going back to it's frequent release cycle...
----------------------------------
http://benham.net/index.html
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d+(-) s:+ a29 C++$ UL++>++++ P+++$ L++>++++ E? W+++$ N+(-) o? K- w+++$(--)
O M-- V- PS-- PE++ Y++ PGP++ t+ 5 X R+ !tv b++++
DI+++ D++ G++>G+++ e h+ r* y+
------END GEEK CODE BLOCK------
----------------------------------
Darren/Torin/Who Ever...
-----BEGIN PGP SIGNED MESSAGE-----
Brandon Mitchell, in an immanent manifestation of deity, wrote:
>On Thu, 28 May 1998, Edward Betts wrote:
>> Has anything major changed in Debain over the last 3 months, is it
>> considerably more stable than 3 months ago or code there have been a code
>> freeze and release 3 months ago???
>
>The installation disk and apt to name a few.
><flame>
>If you want a release every few months, go with a distributor that
>distributes unstable and untested releases (redhat comes to mind).
></flame>
I think that the idea is to release that which is stable every 3||6
months while not putting in those pieces that are having problems.
Darren
- --
<to...@daft.com> <http://www.daft.com/~torin> <to...@debian.org> <to...@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI programmer and tutor. @
@ Make a little hot-tub in your soul. @
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNW209I4wrq++1Ls5AQG3VgQAh+ul61u4p3tdVitbMMxvAveYc/zcQSDi
fD47+NSrijR607RuzXjbhjvAfMIsaPm4STRYhYo/es+nEZ3wSv7xzkHoNoGKPD6M
08VySZXYs+ukj5/7KO3xCEa1heq4EpNnsdHYRHwHmwKi5QvqiiadMftdrpZ82yjO
Uibv1h7kf+A=
=xmNc
-----END PGP SIGNATURE-----
Brandon Mitchell
On 28 May 1998, Darren/Torin/Who Ever... wrote:
> Brandon Mitchell, in an immanent manifestation of deity, wrote:
> >On Thu, 28 May 1998, Edward Betts wrote:
> >> Has anything major changed in Debain over the last 3 months, is it
> >> considerably more stable than 3 months ago or code there have been a code
> >> freeze and release 3 months ago???
> >
> >The installation disk and apt to name a few.
> ><flame>
> >If you want a release every few months, go with a distributor that
> >distributes unstable and untested releases (redhat comes to mind).
> ></flame>
>
> I think that the idea is to release that which is stable every 3||6
> months while not putting in those pieces that are having problems.
I get a little concerned when people want to release a distribution
without installation disk and call it stable. Debian becomes known as the
potluck distribution, it may or may not have what you need to install it.
I think I agree with Dale the most: we bit off a big chunk this time, and
now we are paying for it. If the future, lets try to take more managable
bites and releases will be more often and still stable.
Brandon
Rev. Joseph Carter
> Sorry, now I don't understand. I think we should release twice a year.
I really think this does not really fix the problem we're having now with
hamm though. Trying to test and fix problems in EVERYTHING is a big task
considering how big EVERYTHING is..
It's MUCH better IMO to have PACKAGES be stable and unstable. After a
period of time (at least partially on the urgency of the package--not the
priority) if there are no outstanding grave/critical bugs, the package can
be moved into stable dist..
Every 3-6 months (more or less time if there is a real need) freeze stable
for an official CD image to be made. This would allow what's done to be out
and used by everybody, what's not done to get either noticed as not done and
fixed, or left out of stable till someone decides that it's important enough
that the bug doesn't matter (in which case the bug might just end up
downgraded)
I do suggest adding a new urgency, call it very_high or critical or
whatever, it would essentially be used for things like new kernel patches
fixing the latest IP exploit or other things that can't wait for the testing
process in unstable..
This would make testing easier because it would break a large job into small
parts, make the dist more of a community thing while still maintaining
quality and getting new software out when there is reasonable assurance
there aren't a number of seriously nasty bugs. Minor bugs are a fact of
life, we deal with them.
Rev. Joseph Carter
> >> Has anything major changed in Debain over the last 3 months, is it
> >> considerably more stable than 3 months ago or code there have been a code
> >> freeze and release 3 months ago???
> >
> >The installation disk and apt to name a few.
> ><flame>
> >If you want a release every few months, go with a distributor that
> >distributes unstable and untested releases (redhat comes to mind).
> ></flame>
>
> I think that the idea is to release that which is stable every 3||6
> months while not putting in those pieces that are having problems.
I really think this is possible, please see the last few messages I've
written on the subject, I really think we can and hope people can agree that
we should. Let's get hamm out as we've been planning to first.
Rev. Joseph Carter
> I thought, in general, Debian came out every few months with a new
> release. The delay with 2.0 was glibc6 and Red Hat is faster with that
> because they pay their programmers. After 2.0 is released, we should
> probably be able to count on Debian going back to it's frequent release
> cycle...
I do hope so. I still think my ideas might be helpful in making sure that
thinks like the FHS upgrade don't slow us down. Of course, something I
haven't yet said is that all packages depended on or recommended by a
package would need to make stable before a package could be stable, but that
goes without saying.
David Engel
Here are my responses to several messages (in no particular order). I
had intended to respond to even more messages, but I was adding too
many "me too" and "agreed" type comments and this message was already
long enough so I cut them out.
On Thu, May 28, 1998 at 01:01:57PM -0400, Brandon Mitchell wrote:
> We are only volunteers, and even the critical elements (like the boot
> disks) only move as fast as the people who work on them move. If you
All the more reason to set realistic goals for releases to begin with.
And even more reason to have strong leadership reduce those goals when
not everything goes as well as planned.
> for you. I'd prefer if debian not put the stable sticker on something
> just because we hit a 3 month mark (I know there was more to the request
> than just that, I just fear this result in the long run).
Nobody is suggesting that Debian lower its standards to ship something
just because the calendar changes. However, to many users the need to
have current, timely releases is just as important as having bug-free
releases. At some point, a current release with only a few moderate,
but fixable, problems is better than an out of date release with no
significant problems but lots of minor and annoying ones that you know
have been fixed.
On Thu, May 28, 1998 at 12:01:04AM -0400, Buddha Buck wrote:
> Before work started on Hamm, there was plans to do exactly that --
> periodic releases every 3-4 months. This was because we had such a
> problem with missing deadlines.
Change that to "... have always had and still have a problem with
missing deadlines."
> Both of those transitions required all the packages to be recompiled to
> new standards. To be fair, the libc6 conversion is complete, and we
The libc6 conversion has been virtually complete for 6 months. It was
70-80% done 9 months ago. The biggest stumbling block in the
conversion was X (to be expected). I just checked and Mark had
released the first X packages for libc6 last August already!
> also used the time to do other major overhauls (such as how we handle
> Emacs, TeX, etc, and getting the window managers to work with the
> menuing system). These overhauls also take time.
What good are those overhauls if you don't get them into users' hands
in a reasonable amount of time?
> We also took the time to improve the behind-the-scenes issues, like
> revamping the source packaging system, and overhauling the packaging
> system. We have greatly improved the ease of maintaining the
> distribution as well, with more mirrors, new hardware for master, and
> better helper scripts for building, checking, uploading, and processing
> packages.
All of which are great improvements for the developers, but none of
which were important enough from a users standpoint to force them to
go without a significant update for a year.
> Also, 1.3 was a very successful release, and caused a -tremendous-
> amount of growth in Debian as well. My available list shows nearly
I agree that 1.3 was a watershed for Debian. It's a shame that all
of the momentum gained from that release has been lost.
> 2000 packages (double that of 1.3), and we are forced to go to three
Don't be fooled. More packages does not necessarily equate to a
better distribution.
> 2.0 is a -big- improvement over 1.3. But it also did most of the big
> changes. I expect 2.1 to be a -much- simpler, faster, undertaking than
> 2.0.
I'm not as optimistic as you. There will always be a big, new
undertaking. They may not always be as big as a libc switch, but they
will be there. For example, the source packaging still needs some
improvements. What's going to happen when someone mandates that those
~2000 packages all need to be converted to the next new format before
the next release can be made?
On Thu, May 28, 1998 at 11:52:31AM -0700, The Gecko wrote:
> I thought, in general, Debian came out every few months with a new release.
> The delay with 2.0 was glibc6 and Red Hat is faster with that because they pay
> their programmers. After 2.0 is released, we should probably be able to count
> on Debian going back to it's frequent release cycle...
Debian has never, ever had a frequent release cycle.
On Thu, May 28, 1998 at 02:07:23PM +0200, Michael Meskes wrote:
> And now we're back into the marketing debate we had a short time ago.
To a degree, yes. I'm certainly not saying that having a larger
market share than RedHat should be a goal. However, if you're going
to go to the trouble of putting together a major distribution and
packaging it, don't you want to reach the widest audience you can?
On a related note, is anyone else bothered by the fact that nearly
every well known Linux developer (at least in the kernel and
development areas) uses RedHat?
On Thu, May 28, 1998 at 01:48:44PM +0100, Ian Jackson wrote:
> I see one big reason why hamm is taking so long to release: it's not
> compatible with bo.
I'm glad to see you make an appearance in this thread, Ian. I hope
you will continue to participate.
> This has made developers (many of whom were attracted by Debian's
> incremental and partial upgrade capability) very reluctant to
> upgrade. It has also made it impossible to fix bugs in bo.
>
> Let us never make this mistake again.
The mistake was not biting the bullet getting the libc conversion done
fast enough. It was allowed to drag on and other changes allowed to
creep in to the point where there were too many changes left to
complete to move forward quickly and too many changes already made to
go back.
> We should, instead, simply freeze unstable every six months, and
> release it three months or so later. A package should be allowed into
> frozen (or stable) if it would improve the quality of the
> distribution.
If you mean a full release would pop out every six months or so,
that's a bit longer than I would like but is still acceptable. I also
think 3 months from first freeze to release is too long. Finding
people to test is already hard enough. Do you really expect to be
able to find enough people willing to give up current development for
3 months just to do testing and actually get it done in 3 months?
Ian, I know Bruce left you in a tough position because of the way he
left, but I feel I must put you on thr spot here. There has been talk
before of more frequent releases, however, and each time it was just
that -- talk. What do you intend to do as current Debian leader to
ensure that the project doesn't fall back into its aimless wandering
ways like before?
> We have often good backwards compatibility, so that it doesn't matter
> if our stable distribution is a mixture of a.out and ELF or libc5 and
> libc6.
A mixed environment is fine for normal packages. It is not fine for
development packages (i.e. libraries). If not everything you need is
available for the right environment, it's worthless.
On Thu, May 28, 1998 at 09:30:07AM -0400, Raul Miller wrote:
> I suspect that if we'd have focussed on a libc6 development environment
> that run under libc5, and built up from there, that we'd have gotten
> a fully libc6 release sooner.
I don't think that would have helped much. Supporting parallel
development environments is going to be a major pain no matter how you
try to do it.
In hindsight, I think a better approach for fixing bugs in bo would
have been to allow selected libc6 packages into bo so that more easily
buildable hamm packages could have been used as updates. Before
anyone cries about moving unstable packages into stable, they would
have been tested, of course.
On Thu, May 28, 1998 at 11:54:55AM -0400, Dale Scheetz wrote:
> Well, as I see it there are two major issues, one of which is my
> responsibility.
>
> First, we are waiting on an upstream release of 2.0.7 glibc (any day now)
> which will, hopefully fix several package problems.
I don't think Debian should wait on Ulrich. There's no telling when
he will have an official 2.0.7 ready. Dale, you should go with
whatever -pre version and fixes you deem appropriate. FWIW, that's
what RedHat appears to have done.
> Second, the major need for a release is to have a functioning set of
> installation disks. As several of the crucial packages were converted to
> slang "at the last minute" they have taken some time to stabalize out. It
> appears that the most recent disk set is well on the way to being release
> ready.
Lesson learned: someone should be looking at boot disk issues even
_before_ a freeze and not allow these types of last minute changes.
David
--
David Engel ODS Networks
da...@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
Philip Hands
> Sorry, now I don't understand. I think we should release twice a year.
What about encouraging people to press ``Debian Unstable Snapshots'' once
every couple of months.
We could do the snapshot images ourselves (so that everyone's ``May 98''
image was exactly the same), give it a few days testing to ensure that it's
not completely broken, and suggest in the documentation that people
look at the web site for any problems and work-arounds found after release.
As long as it is published with warnings that it is just a snapshot, and not a
tested release, we should not be tarnish our image, while providing the
bandwidth limited folks with an alternative ``download'' method.
Cheers, Phil.
Edward Betts
On Thu, 28 May, 1998, Brandon Mitchell wrote:
> On Thu, 28 May 1998, Edward Betts wrote:
>
> > Has anything major changed in Debain over the last 3 months, is it
> > considerably more stable than 3 months ago or code there have been a code
> > freeze and release 3 months ago???
>
> The installation disk and apt to name a few.
> <flame>
> If you want a release every few months, go with a distributor that
> distributes unstable and untested releases (redhat comes to mind).
> </flame>
> disks) only move as fast as the people who work on them move. If you
> just because we hit a 3 month mark (I know there was more to the request
> than just that, I just fear this result in the long run).
Oh my I forgot install disks, that is the difference between installing a
fresh from CD and upgrading over the Internet I suppose.
--
Edward Betts http://www.hairnet.demon.co.uk/
Bill Mitchell
I've been lurking, and have some musings and suggestions which I think
might be useful. I'll use a post from Ian J. as a jumping off point.
On Thu, 28 May 1998, Ian Jackson wrote:
> I see one big reason why hamm is taking so long to release: it's not
> compatible with bo.
>
> This has made developers (many of whom were attracted by Debian's
> incremental and partial upgrade capability) very reluctant to
> upgrade. It has also made it impossible to fix bugs in bo.
>
> Let us never make this mistake again.
Major releases tend to be this way. Version numbering aside, it seems
to me that most/all debian releases have been major.
Offhand, I don't recall the details prior to 1.2 but, as I recall it,
1.2->1.3 was libc4->libc5, a.out->elf, and curses->terminfo. 1.3->2.0 is
libc5->libc6. Both upgrades involve issues which go beyond just releasing
a later, spiffier, and more featureful collection of packages. Both, to
some extent, involve incompatibilities with previous releases. These
incompatibilities make upgrading touchy. The curses->terminfo change
implied that quite a number of packages needed to be be upgraded as part
of any 1.2->1.3 upgrade, even if a.out support was preserved.
> We should, instead, simply freeze unstable every six months, and
> release it three months or so later. A package should be allowed into
> frozen (or stable) if it would improve the quality of the
> distribution.
If working on a major release which involves making next-release packages
which are incompatible with current-release packages, I think that
a directory tree needs to be maintained with up-to-date current-release
packages as well. The current release should not be frozen in time
except for bugfixes -- it needs to keep pace with new package releases
and old package featurizations as well. If not, debian will be perceived
as being outdated compared to other distributions containing later and
more current versions of the packages.
For hamm development, a decision was made to freeze bo except for serious
bugfixes (I presume this decision has remained in force during the months
of my most recent absence from debian). This, as I recall, was in
reaction to two pressures:
CD Manufacturers had problems in making an investment to produce a
1.3.0 CD, only to have it immediately superseded by a 1.3.1 CD with
minor changes. So as not to present a disincentive against putting
out debian CDs, the current release needed to be less volatile.
Some (most?) package maintainers had a problem keeping packages
current in both libc5 and libc6 formats. Dropping the requirement
for libc5 package maintenance gave an incentive for maintainers to
upgrade to libc6.
> We have often good backwards compatibility, so that it doesn't matter
> if our stable distribution is a mixture of a.out and ELF or libc5 and
> libc6.
With hindsight, it seems that we would have been better off to pay more
attention to maintaining an environment of good backwards compatibility
for packages, to have package maintenance take place in a directory tree
based on the current debian system release, and to do development towards
the next major system release in a separate tree where backwards
compatibility is maintained for current-release packages where possible.
Packages which require separate versions for debian-current and debian-next
system releases would have two concurrent versions (which might need
another change to package version numbering conventions), or would be
simply unavailable in the next-release tree.
All package maintainers would need debian-current release based
development systems. Developers working on the debian-next release
would need development systems for both debian-current and debian-next.
(debian-current and debian-next being major releases having some
degree of incompatibility. debian-current would have periodic
release-numbered minor releases).
For the debian-current release, there would probably be a stable
tree which is updated every N months with later-release packages
which are considered stable. This tree should probably be updated
no less often than every three months, so as not to fall too far
behind package releases by other distributions. There would also
probably be an unstable (unproven?) tree with the latest maintainer
release. Criteria for releasing packages from unstable (unproven?)
to stable might be that it have been in the unstable tree for at least
one month and/or have a `seems OK' endorsement by at least N debian
users (mechanics for gathering the endorsements to be determined).
Come to think of it, there would probably be three debian-current release
trees. I might name them released, proven, and unproven. `released'
would be the current minor-release stable tree. `proven' would be
packages which had met minor-release criteria but had not yet been
picked up in a release. `unproven' would be the latest maintainer
release.
In addition to these debian-current release trees, there would be
at least one debian-next tree. This would probably be mostly
symlinks back to forward-compatible packages in a debian-current
tree (probably to the package in the debian-current unproven tree).
Where it became known that cross-release compatibility for a package
would be broken, the symlink would be deleted. Such deleted symlinks
would either be left that way or replaced with compatible package versions
maintained concurrently with the incompatible version in the current-release
tree. If there is only one next-release tree, as is currently done, there
would be no guarantee that it contains a consistent package set at any
given time. Only active debian-next developers and others wishing to live
on the bleeding edge would use this tree.
CD manufacturers could release CDs based on the debian-current `released'
tree at a every-N month cycle with an incremented minor release number.
They might or might not include the current-release `proven' and/or
`unproven' trees. (if the release cycle is three months, A monthly CD
containing the latest proven & unproven trees might be attractive).
CD manufacturers might or might not offer CDs with the bleeding edge
debian-next tree. I would hope that at least one or two would.
Guy Maor
The cause of many of our problems is that we strive to release a
stable version of every package. Instead, we should have releases at
preset intervals, say 4 times a year, of only parts of unstable.
One month before the release we enter the freeze. At that time, a
decision by the maintainer and the release manager is made for every
package whether to release it. Only the selected packages are tested.
If the testing team discovers a critical bug, the package is either
fixed or it is dropped from stable. A critical bug rarely delays a
release, because there is always the previous stable version of the
package to fall back on.
When releases are at regular, reasonably often, intervals, it is not
as important if a package isn't ready for a release. The next release
is only a few months later.
A disadvantage of such a method is the need for more effort from the
testers.
Guy
Lindsay Allen
This is going to ruffle a few feathers, but I have broad shoulders...
I very much support David's remarks about leadership. As a mere user cum
tester I was first bewildered and then amazed at the silence from the top
as developers squabbled amongst themselves and then started walking out
the door.
The leader's first and foremost task is to manage the team, _not_ the
distribution. Technical details re the distribution can be delegated to
someone with more time, but the leader's job is to _lead_ the team, to
give direction and to _make_ a decision even if it turns out to be less
than optimal. If he does a good job the team members will feel good just
to be part of the team.
My career has been as an airline pilot and I leave it to you to imagine
how things would go if, instead of having a Captain, each aircraft relied
on a consensus from the passengers each time a problem came up. I would
keep my feet firmly on the ground, thank you.
On a more personal note, I have been running hamm for a long time here and
am very happy with it. But if I were an outsider, waiting and waiting for
hamm to appear, I would have shifted camp months ago. If we could have
stopped the developers from using hamm before its release (yes, I know!) I
bet it would have been out the door last December.
So while we must keep our distribution technically sound we must not
forget our "customers", assuming that there any any still waiting.
Lindsay
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lindsay Allen <al...@cleo.murdoch.edu.au> Perth, Western Australia
voice +61 8 9316 2486 32.0125S 115.8445E vk6lj Debian Unix
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Enrique Zanardi
On Thu, May 28, 1998 at 11:52:26PM -0700, Guy Maor wrote:
> The cause of many of our problems is that we strive to release a
> stable version of every package. Instead, we should have releases at
> preset intervals, say 4 times a year, of only parts of unstable.
>
> One month before the release we enter the freeze. At that time, a
> decision by the maintainer and the release manager is made for every
> package whether to release it. Only the selected packages are tested.
> If the testing team discovers a critical bug, the package is either
> fixed or it is dropped from stable. A critical bug rarely delays a
> release, because there is always the previous stable version of the
> package to fall back on.
>
> When releases are at regular, reasonably often, intervals, it is not
> as important if a package isn't ready for a release. The next release
> is only a few months later.
>
> A disadvantage of such a method is the need for more effort from the
> testers.
IMHO, that method would be easier to follow if we divide "main" in "core"
and "non-core". That way, "core" packages will be the primary testing
target (we can't release a distribution without those packages, but
sometimes there are major transitions, like the current libc5->libc6 and
you can't fall back to the previous stable version). The "non-core"
packages would be a secondary target. Those that work would be
included, else they would be moved to the next release and the previous
stable version is used, as you suggest. (We can use any "optional"
libc5-based package with Debian 2.0, because we have such a good "core"
system).
--
Enrique Zanardi ezan...@ull.es
Michael Meskes
Rev. Joseph Carter writes:
> On Thu, May 28, 1998 at 04:12:01PM +0200, Meskes, Michael wrote:
>
> hamm though. Trying to test and fix problems in EVERYTHING is a big task
> considering how big EVERYTHING is..
>
> It's MUCH better IMO to have PACKAGES be stable and unstable. After a
> period of time (at least partially on the urgency of the package--not the
> priority) if there are no outstanding grave/critical bugs, the package can
> be moved into stable dist..
>
> Every 3-6 months (more or less time if there is a real need) freeze stable
> for an official CD image to be made. This would allow what's done to be out
> and used by everybody, what's not done to get either noticed as not done and
> fixed, or left out of stable till someone decides that it's important enough
> that the bug doesn't matter (in which case the bug might just end up
> downgraded)
I like this idea. Just to see if I understood you correctly, we could make a
stable CD when we want to? In fact we would still keep the version
numbering, but there is always an up-to-date stable release.
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
mes...@topsystem.de | Europark A2, Adenauerstr. 20
mes...@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
Michael Meskes
Raul Miller writes:
> Meskes, Michael <mes...@topsystem.de> wrote:
> > So I misunderstood the original mail. Yes, you were right I meant the 3
> > month development + 3 months freeze. But that one could contain some
> > development for the next version, as we do now. The problem as I see it,
> > is that there are major bugs in hamm that no one cares about, because we
> > are already working on slink. I still don't fully understand why we
> > can't get hamm out of the door.
>
> First time I heard about this.
>
> I thought that we had some people in the critical path who were
> working just as hard as they could to get hamm released.
Upong rereading my mail it sounds pretty offending, but was never meant to
be. What I wanted to say way that the open bugs are the only open problem I
was aware of. I wasn't aware of a problem with the boot disks and libc.
Besides I think we should ship with whatever version of glibc is available
and not wait for Ulrich.
I had a hard time imagining that these bugs are the only reason for the
delay, because it shouldn't be too difficult to fix them or move the package
out of the dist.
Bdale Garbee
In article <1998052908...@molec3.dfis.ull.es> you wrote:
: IMHO, that method would be easier to follow if we divide "main" in "core"
: and "non-core".
So, how does that differ from the current system? Isn't "core" exactly the
same as the set of required+important priority packages? One could argue
that the core also includes standard packages, but I see that as a second
tier, with all of optional and extra as clearly not part of the core.
But even this is just a testing optimization thing. To do a 'stable release',
the "release team" would still want/need to determine which packages from the
set of all available packages should be included in the release, and which
version of each package to be released should be included. If it helps the
testing team to start with packages in the highest priority band and work
out from there, that's fine, but I don't think it should change the release
process.
I've been thinking about this a long time. Here's a wild idea I've been
kicking around for a long time. If you don't have time to be distracted,
quit reading now!
A long time ago, when I instigated and for a while managed master.debian.org,
I was on the verge of proposing a radical change in the way we handle
versioning... then I got massively busy at work, went through a messy
internal audit that forced me to be less generous to Debian with our network
bandwidth, and so forth... so I never followed up on the idea. I have
alluded to it a couple of times, and I still think there's a kernel of a
good idea in here somewhere.
The general notion is that all package uploads go into a common pool.
Scripts on the server routinely build a symlink tree that points to the most
recent version of each package in the pool, which is the equivalent of the
current 'unstable' tree. In fact, there could even be different flavors of
instability, with different criteria used by the link tree builder to
determine which versions to link to for each tree. Trees of symlinks are
cheap.
When the calendar, or the release team, or God decrees that it's time to work
on a new "stable release", a new versioned symlink tree is semi-manually
built pointing into the package pool, identifying the versions of each
package that are proposed to be included in the release. Testing ensues,
and the versioned symlink tree is updated appropriately based on the results.
At release time, the versioned symlink tree is frozen. The size of the pool
is managed using standard resource allocation techniques... any version of a
package currently being pointed to is retained, prior versions of packages
are retained as allowed by available disk space, with older bits being
deleted to make space for new bits arriving.
There are some obvious issues surrounding how a structure like this gets
mirrored, but it has several technical and procedural advantages. I always
hated the Perl/FTP mirroring code, and figured that doing something radical
with the dist tree that wasn't well supported by the traditional mirroring
techniques might motivate me to go write a suite of tools to do the job
better. One of the really cool aspects of a structure like this is that there
is very little risk in trying a new rev of a package, since with sufficient
disk space on the archive, there would always be a few prior revs to fall back
on as need be. It also makes it really easy to live on the bleeding edge,
since latency from upload to mirroring could be very small.
One specific failing of the current system that I lament is that any new
package installation into the distribution tree causes us to lose the previous
version. This makes fallback tough, depending on the maintainer or other
random folk to be able to reproduce/reupload a prior version of a package.
It also causes us to be wickedly cautious about installing new packages... my
vision would have Incoming packages dropped into the pool immediately if the
signatures and sums all matched for a registered developer... I'd also drop
the notion of subsections entirely, and merge the 'standard' and 'important'
priorities into one priority.
I still don't have time to work on this idea... if I did, it might be the
genesis of a yet-another Debian-derived distribution... since it would be
easy to track unstable and Incoming to seed an independently managed release
tree even if Debian didn't adopt the notion... and I suspect it's radical
enough to be a tough sell these days... too many developers to convince!
As my current-favorite game says on the box... "so many pedestrians, so little
time..." :-) Or, as the HP calculator software guys used to say, "life is
short, and the ROM is full"... :-)
Bdale
Enrique Zanardi
On Fri, May 29, 1998 at 02:35:30AM -0600, Bdale Garbee wrote:
> In article <1998052908...@molec3.dfis.ull.es> you wrote:
>
> : IMHO, that method would be easier to follow if we divide "main" in "core"
> : and "non-core".
>
> So, how does that differ from the current system?
Talking about testing, it doesn't! It just "officializes" the current
status, identifies properly both package sets and helps coordinating
things and defining different rules for each set (IMO).
Currently the "priorities" thing doesn't work as well as the
"distribution/section" one, We still have "required" packages that depend
on "optional" packages. We don't have any "main" package that depend on a
"contrib" or "non-free" one. Also, by looking at our FTP archive or
Official CDs there's no way to tell which priorities a package have.
OTOH, I don't care much about the "name" or method we use to separate
both sets, as long as that separation is clear for Debian developers,
Debian users (aka "probable proto-developers") and those wanting to use
Debian as a "base distribution", and as long as we can define a different
testing/release procedure for each set.
> But even this is just a testing optimization thing. To do a 'stable release',
> the "release team" would still want/need to determine which packages from the
> set of all available packages should be included in the release, and which
> version of each package to be released should be included.
As I said, there are different goals we must fulfill when working with
each set. The "core" set _must_ work (release critical bugs in the core
set means no release can be done) so our developing and testing must be
focused primarily on that set. The "non-core" set is a secondary target.
If something doesn't work it is removed from the "frozen" distribution
and moved to the "unstable" one. The "core" set is not broken by such a
removal. (IIRC, our "main" distribution had several problems last "freeze
date" because of a similar cleanup). By having each set in a different
subdirectory tree we help isolating problems.
Thanks,
--
Enrique Zanardi ezan...@ull.es
Bdale Garbee
In article <1998052910...@molec3.dfis.ull.es> you wrote:
: If something doesn't work it is removed from the "frozen" distribution
: and moved to the "unstable" one.
I suppose this is the key difference in our approaches. The way we've just
copied all of unstable and declared it "frozen" is fundamentally broken to
my mind. We should implement a subset of the lintian checks and pkg-order as
part of ensuring that anything in a 'frozen' or 'stable' tree is correct by
construction for this class of policy issues.
If we do this, then the priorities really do mean something useful, and what
you're asking for falls out pretty easily. If we go one step further, and
restructure the tree so that packages are split into directories by priority
instead of by the ever-confusing concept of subsection, we'd get the best of
both worlds, I suspect...
I'm willing to help write code to do a better job of handling package release
logistics for slink. It is now way too late to worry about it for hamm, which
we need to wrap up as quickly as possible, so we can get back to having fun.
Bdale
Raul Miller
Bdale Garbee <bd...@gag.com> wrote:
> The general notion is that all package uploads go into a common pool.
I like this idea.
Note that we can grandfather our current distribution system by
declaring the existing stuff as (a complex, but reasonably static)
part of the pool.
Also, I've been thinking about keeping backups for "deleted" packages.
--
Raul
Rev. Joseph Carter
> > > Sorry, now I don't understand. I think we should release twice a year.
> >
> > I really think this does not really fix the problem we're having now with
> > hamm though. Trying to test and fix problems in EVERYTHING is a big task
> > considering how big EVERYTHING is..
> >
> > It's MUCH better IMO to have PACKAGES be stable and unstable. After a
> > period of time (at least partially on the urgency of the package--not the
> > priority) if there are no outstanding grave/critical bugs, the package can
> > be moved into stable dist..
> >
> > Every 3-6 months (more or less time if there is a real need) freeze stable
> > for an official CD image to be made. This would allow what's done to be out
> > and used by everybody, what's not done to get either noticed as not done and
> > fixed, or left out of stable till someone decides that it's important enough
> > that the bug doesn't matter (in which case the bug might just end up
> > downgraded)
>
> I like this idea. Just to see if I understood you correctly, we could make a
> stable CD when we want to? In fact we would still keep the version
> numbering, but there is always an up-to-date stable release.
It would seem to me to be the case that version number would only add
complexity (determining what the version number would be for the next
release) It would seem that a date release would be a better animal to deal
with.
Someone could burn stable CDs as often as they felt like and they would get
something that is more stable than say redhat is, but would likely be much
more up to date than say 1.3.1r8 is.
Now and then freezing of the stable dist to be SURE that everything works
okay and that nothing is added that may break things (which shouldn't happen
anyway, since that's supposed to be fixed while packages are in unstable,
but I think we should be prepared for an occasional problem to slip by as it
does even now) In a few weeks after the freeze, ship it. Mainly this time
period is designed to give time for official images to be made and bugs
worked out of that process if need be.
bugs.debian.org would become much more significant under this model I think.
Stig Sandbeck Mathisen
> It's MUCH better IMO to have PACKAGES be stable and unstable. After a
> period of time (at least partially on the urgency of the package--not the
> priority) if there are no outstanding grave/critical bugs, the package can
> be moved into stable dist..
I like. That will mean we can have a "current" Debian all the time.
For greater changes in system policy, however (as with moving to libc6)
this can be more of a challenge. (However, I might be wrong)
--
SSM - Stig Sandbeck Mathisen
Trust the Computer, the Computer is your Friend
Bob Hilliard
Philip Hands <ph...@hands.com> writes:
> What about encouraging people to press ``Debian Unstable Snapshots'' once
> every couple of months.
If the high-volume distributors aren't interested in this, don't
forget that a number of Debian developers make and sell custom gold
CDs. (See the listings under "Getting Debian on CD" on www.debian.org.)
These cost $20-30, as opposed to $5-20 for the sliver CDs, but are more
up to date, and can be customized to suit the buyer.
Bob
--
_
|_) _ |_ Robert D. Hilliard <hill...@flinet.com>
|_) (_) |_) Palm City, FL USA PGP Key ID: A8E40EB9
Rev. Joseph Carter
> In article <1998052908...@molec3.dfis.ull.es> you wrote:
>
> : IMHO, that method would be easier to follow if we divide "main" in "core"
> : and "non-core".
>
> the same as the set of required+important priority packages? One could
> argue that the core also includes standard packages, but I see that as a
> second tier, with all of optional and extra as clearly not part of the
> core.
That's kinda what I thought really. Though I can clearly see other problems
besides these, that's still the big one. The larger Debian dist would be
updated as often as it has been (not often enough) and the core wouldn't
satisfy the need for new toys.
That's why I suggested having the packages be considered stable or unstable
rather than an entire dist. It'd be much more likely to happen more
freqently that packages get stable than entire groups of 2000 odd packages
will.
> But even this is just a testing optimization thing. To do a 'stable
> release', the "release team" would still want/need to determine which
> packages from the set of all available packages should be included in the
> release, and which version of each package to be released should be
> included. If it helps the testing team to start with packages in the
> highest priority band and work out from there, that's fine, but I don't
> think it should change the release process.
Problem seens that there is just too much to test all at once.
> I've been thinking about this a long time. Here's a wild idea I've been
> kicking around for a long time. If you don't have time to be distracted,
> quit reading now!
>
> A long time ago, when I instigated and for a while managed
> master.debian.org, I was on the verge of proposing a radical change in the
> way we handle versioning... then I got massively busy at work, went
> through a messy internal audit that forced me to be less generous to
> Debian with our network bandwidth, and so forth... so I never followed up
> on the idea. I have alluded to it a couple of times, and I still think
> there's a kernel of a good idea in here somewhere.
>
> The general notion is that all package uploads go into a common pool.
> Scripts on the server routinely build a symlink tree that points to the
> most recent version of each package in the pool, which is the equivalent
> of the current 'unstable' tree. In fact, there could even be different
> flavors of instability, with different criteria used by the link tree
> builder to determine which versions to link to for each tree. Trees of
> symlinks are cheap.
Upto here this was EXACTLY what I was thinking...
> When the calendar, or the release team, or God decrees that it's time to
> work on a new "stable release", a new versioned symlink tree is
> semi-manually built pointing into the package pool, identifying the
> versions of each package that are proposed to be included in the release.
> Testing ensues, and the versioned symlink tree is updated appropriately
> based on the results. At release time, the versioned symlink tree is
> frozen. The size of the pool is managed using standard resource
> allocation techniques... any version of a package currently being pointed
> to is retained, prior versions of packages are retained as allowed by
> available disk space, with older bits being deleted to make space for new
> bits arriving.
I was thinking maybe that we could instead update the stable tree as we
went, when a package in unstable was deemed stable enough. Stable would be
kept stable, but not static. As packages were determined to be stable, they
are moved to stable..
All packages in unstable remain there for a testing period for bugs to be
found. If no release-affecting bugs are open after that testing period, the
package can be moved to stable. However it can't be moved till all of those
level of bugs are either closed or whatever (more or less as is the case
with not releasing hamm till it's done) For a low urgency package I figure
4-6 weeks should be sufficient for testing. Less for higher urgency
packages since higher urgency seems to indicate serious/security bugs were
fixed.
All that would remain is making official releases, essentially installable
snapshots of stable. That's an issue I haven't worked out yet, but it seems
that a short-term freeze of the stable tree to be sure that it can be
installed would do the job. I hope.
> There are some obvious issues surrounding how a structure like this gets
> mirrored, but it has several technical and procedural advantages. I
> always hated the Perl/FTP mirroring code, and figured that doing something
> radical with the dist tree that wasn't well supported by the traditional
> mirroring techniques might motivate me to go write a suite of tools to do
> the job better. One of the really cool aspects of a structure like this
> is that there is very little risk in trying a new rev of a package, since
> with sufficient disk space on the archive, there would always be a few
> prior revs to fall back on as need be. It also makes it really easy to
> live on the bleeding edge, since latency from upload to mirroring could be
> very small.
I hadn't actually considered keeping old revisions around really, sounds
like something apt might make work well. I would suggest that there be some
method to keep n old versions of packages in certain sections at least, with
base being the first one to come to mind. I'm not yet sure how apt would
handle this.
> One specific failing of the current system that I lament is that any new
> package installation into the distribution tree causes us to lose the
> previous version. This makes fallback tough, depending on the maintainer
> or other random folk to be able to reproduce/reupload a prior version of a
> package. It also causes us to be wickedly cautious about installing new
> packages... my vision would have Incoming packages dropped into the pool
> immediately if the signatures and sums all matched for a registered
> developer... I'd also drop the notion of subsections entirely, and merge
> the 'standard' and 'important' priorities into one priority.
Often downgrading involves a purge of the new package and reinstallation of
the old anyway. Not sure how to fix that problem really. Downgrading would
be a manual process still most likely.
> I still don't have time to work on this idea... if I did, it might be the
> genesis of a yet-another Debian-derived distribution... since it would be
> easy to track unstable and Incoming to seed an independently managed
> release tree even if Debian didn't adopt the notion... and I suspect it's
> radical enough to be a tough sell these days... too many developers to
> convince!
Some of us do. => Can't claim I'm one of them at the moment, but I can and
wouldn't mind helping. But I don't want another Debian derived dist. I'd
much rather see Debian become better because it can become better.
> As my current-favorite game says on the box... "so many pedestrians, so
> little time..." :-) Or, as the HP calculator software guys used to say,
> "life is short, and the ROM is full"... :-)
=>
Rev. Joseph Carter
> > It's MUCH better IMO to have PACKAGES be stable and unstable. After a
> > period of time (at least partially on the urgency of the package--not the
> > priority) if there are no outstanding grave/critical bugs, the package can
> > be moved into stable dist..
>
> I like. That will mean we can have a "current" Debian all the time.
Current enough at least. And if apt allows you to have the package list for
unstable but NOT automagically upgrade to unstable packages lest you tell it
to, then you'd be all set.
> For greater changes in system policy, however (as with moving to libc6)
> this can be more of a challenge. (However, I might be wrong)
Not so much as it sounds. Upgrading to hamm today is not a simple task and
dselect is drain bamaged to the extreme with telling dpkg how to install
packages to make the upgrade work and apt isn't quite ready for general use
I think (though I've had NO PROBLEMS with it myself and most probably
wouldn't either) and isn't part of hamm.
However, I am thinking more slink or post-slink. By then we should have
something more substantial for apt.
Adding libc6 to bo is EASY. I did this the day after I installed from my
1.3.1r6 CD and I had NO EXPERIENCE with Linux before that really. Some very
basic ksh experience on an isp shell, but I couldn't even write a shell
script at the time. What was harder was installing other packages in the
right order and I did screw it up (by letting dselect do it for me) before I
wend and did it by hand. It killed bash by not having libreadline there and
such. Since it left much else broken I didn't want to TRY and fix it, so I
just reinstalled, upgraded by hand, and learned how to fix these things in
the future.. (hint: sash and an extra passwd entry for root is a good
beginning!)
And hamm is backwards compatible with libc5, unlike Redhat 5. The combined
effect of frequent updates to stable, apt to make those updates work safely,
and debian's backwards compatibility to at least the last version would make
Debian a VERY attractive alternative to Redhat bugginess.
We just gotta watch that things that should NOT move into stable don't till
they're ready to move there. I'm pretty sure we can do it though.
David Engel
On Fri, May 29, 1998 at 02:35:30AM -0600, Bdale Garbee wrote:
> In article <1998052908...@molec3.dfis.ull.es> you wrote:
> : IMHO, that method would be easier to follow if we divide "main" in "core"
> : and "non-core".
>
> So, how does that differ from the current system? Isn't "core" exactly the
> same as the set of required+important priority packages? One could argue
> that the core also includes standard packages, but I see that as a second
> tier, with all of optional and extra as clearly not part of the core.
It differs in important ways. Debian's current practice of accepting
any DSFG-compliant package into main creates at least two false, but
not unreasonable, expectations among users.
First, having a package in main creates the expectation that the
package will be held to the same standards as every other package in
main. If I understood another message correctly, the test team has
only recently finished checking out the required and important
packages, now hopes to check out all of the standard packages and
probably won't get to the optional and extra packages at all. This
means there could very possibly be some serious problems in packages
that get released.
Second, having a package in main creates the expectation that the
package will either be provided in future releases also or at least
replaced with a comparable alternative. I've seen some people
suggesting that Debian should re-evaluate every package when release
time rolls around and only include those packages that are deemed
stable at that time. The consequence is that the packages which
aren't deemed stable are removed and the users that might need them
are just out of luck.
Both of these situations are a disservice to users. Having a separate
collection of packages clearly marked as contributed and not part of
the main distribution would help prevent users from forming the wrong
expectations.
Now, some may point at RedHat's contrib section and its "varying
degree" of quality as a reason not to do it that way. I strongly
believe that Debian's contrib section wouldn't be that bad. Debian's
policy, open bug system and open development process would ensure
that.
As I've stated before, having a smaller main distribution would also
immensely help to make Debian more manageable. It would make it
easier to focus the developers and testers on what packages are really
important and need the most attention when release time comes.
A true contrib section would also be the ideal place for the one-off
type packages that so many developers, including myself, are guilty of
making. By one-off, I mean the things that look neat, quickly get
packaged and are then abandoned when the neatness wears off.
On Fri, May 29, 1998 at 10:56:35AM +0800, Bill Mitchell wrote:
> All package maintainers would need debian-current release based
> development systems. Developers working on the debian-next release
> would need development systems for both debian-current and debian-next.
> (debian-current and debian-next being major releases having some
> degree of incompatibility. debian-current would have periodic
> release-numbered minor releases).
> ...
> Come to think of it, there would probably be three debian-current release
> trees. I might name them released, proven, and unproven. `released'
> would be the current minor-release stable tree. `proven' would be
> packages which had met minor-release criteria but had not yet been
> picked up in a release. `unproven' would be the latest maintainer
> release.
I don't believe this is workable. First, I doubt that enough
developers would have the required system resources to work on 3 (or
more) different releases at the same time. Second, Debian has a
purely volunteer work force. It's hard enough already getting a
sustained effort working on a single release. If that effort was
diminished by dividing the volunteers across multiple releases,
nothing would ever get done.
On Fri, May 29, 1998 at 07:19:35PM +0100, Tom Lees wrote:
> IMHO, this is what we should do:-
>
> a) Push out more releases, but label them "work in progress", or something
> similar if need be. We _CAN_ do this every 3 or 6 months, and people
> won't complain (hopefully).
They will complain. See above for what expectations users will have
concerning the quality and composition of releases.
> b) Shrink the main distribution somehow. I'm not suggesting a "core
> _developer_" approach - but a "core _distribution_" approach.
>
> This means that I can maintain packages in both distributions, no matter
> who I am, but that the distributions are managed (as a whole) separately.
Yes. This is one thing I've been trying to advocate, but probably
haven't been as clear about the "not a core developer" part as I could
have been.
> c) Do our best to motivate people more. I personally would be motivated
> by better PR on the part of the distribution, or free stuff (CDs,
> T-shirts, etc). Better PR is important though, and making fairly
> regular releases comes into that too.
I would certainly be more motivated if I believed that Debian was
moving forward, gaining wider usage and that the fruits of my labor
were benefitting more people. I'd also be more motivated if I could
recommend the distribution that I worked on to friends and coworkers
because I believed it was the best distribution for them instead of
the distribution "by and for well-net-connected developers" that it
currently is.
> d) Try our best to create more manageable release goals. Releases should
> be specifically planned to take 3 months to update. Most of the work
> that actually should happen in a release should be updating to new
> versions of packages. More long-term goals (eg FHS compliance, libc6
> updating) should be managed very carefully. One possible solution
Right. This is where the strong leadership issue that I've harped on
comes into play.
> Or maybe I just need a better mailing-list-reader (I'm using Mutt at the
> moment, but I might try GNUs) :)
I currently have procmail filter everything related to Debian into a
separate folder, but even that can be too much to read. I think I'm
going to have to filter things into multiple folders and make better
use of Mutt's scoring capabilities.
David
--
David Engel ODS Networks
da...@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
Bdale Garbee
In article <19980529230129.A4537@elo> you wrote:
: If I understood another message correctly, the test team has
: only recently finished checking out the required and important
: packages, now hopes to check out all of the standard packages and
: probably won't get to the optional and extra packages at all.
If we were to beef up the documentation of what the priorities on packages
meant, and made it clear that there was a descending scale of promised quality
for priorities farther from 'required', I think we could take care of most of
the problems you're identifying. Yes, there will always be some user unhappy
about a bug, or a package that goes orphaned... but dwelling on that may be
counter-productive.
I had an interesting chat with one of my cohorts at work today about this
topic. We spent some time thinking about the various Debian users we know,
and tried to characterize what they want from the distribution. What we came
up with was the notion that it splits three ways.
The first group wants to always have the latest of everything, regardless of
testing level or absolute stability. This includes a fair number of the
Debian developers, and some of our more wild-eyed friends, but isn't the
mainstream. This community can be reasonably assumed to be net-connected,
and probably cares about CD'd only when they're doing a cold install.
The second group is CD-focussed. They are either folks who aren't on the
net with lots of bandwidth, or who are using Debian to provide the platform
for other work, and don't want to be "bothered" by constant change. For these
folks, a fresh CD every half-year or year is good, and it's important that
the bits they get be as robust and bug-free as possible. Once they install
a package, they're making a long-term committment to that package revision.
So far, nothing new.
We think the third group represents the primary target market for a
distribution like Debian. This group has good net access, wants to stay
reasonably current, but can't tolerate dealing with the worst 10% or so of
the package churn that happens in a bleeding-edge "unstable" tree. They would
prefer not to bump into any real problems, but they're willing to stumble once
in a while if that's the price of keeping up with security patches, new
development tool releases, and the like. This group might be characterized
by those who are currently running 'hamm' on production servers, as we do at
work.
The insight we had was that for this third group, formal testing is icing on
the cake, and not really required. If we were to implement a "package pool
with symlink trees" approach such as I described yesterday, we might envision
training our automation not only to routinely build a symlink tree of the
latest versions of each package for the first group, but also to build a
"stable but unreleased" tree for this third group. The key concept is that
if a package version has been released for some period of time (a week, a
month, not sure how long makes sense) without being retracted or superceded,
then it is, by definition, "stable"... even though it's absolute quality is
still an unknown. Put another way, if there is active development underway on
a package such that new revisions are showing up every few hours or days, this
third group of folks doesn't want to upgrade or install the package until the
churn rate slows down... and that's a relatively easy idea to automate.
So, group one wants nothing between them and the developer's uploads, group
two wants a human testing team to have reviewed and approved each package that
is on their CD, and group three doesn't want to wait for a human testing team,
but wants to distance themselves a touch from the bleeding edge.
While we were talking, another thing that was really clear to us was that
'standard' and 'important' should be merged, leaving the name 'standard' for
the combined priority. That would leave 'required' as the set of packages
that are part of the base install, 'standard' as all the stuff that one might
reasonably expect to be present on any normal Debian system, 'optional' as the
place where most packages live, and 'extra' for the kinds of things that get
shoved out there now... dangerous toys, etc. Once we get past this
constitution thingy being ratified, I intend to propose this officially.
More food for thought for slink and on...
Bdale
Rob Browning
"David Engel " <da...@ods.com> writes:
> > Or maybe I just need a better mailing-list-reader (I'm using Mutt at the
> > moment, but I might try GNUs) :)
>
> I currently have procmail filter everything related to Debian into a
> separate folder, but even that can be too much to read. I think I'm
> going to have to filter things into multiple folders and make better
> use of Mutt's scoring capabilities.
Definitely try Gnus -- *highly* recommended. No idea how I'd handle
this volume of mail without it.
--
Rob Browning <r...@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
Bill Mitchell
On Fri, 29 May 1998, David Engel wrote:
> On Fri, May 29, 1998 at 10:56:35AM +0800, Bill Mitchell wrote:
> > All package maintainers would need debian-current release based
> > development systems. Developers working on the debian-next release
> > would need development systems for both debian-current and debian-next.
> > (debian-current and debian-next being major releases having some
> > degree of incompatibility. debian-current would have periodic
> > release-numbered minor releases).
> > ...
> > Come to think of it, there would probably be three debian-current release
> > trees. I might name them released, proven, and unproven. `released'
> > would be the current minor-release stable tree. `proven' would be
> > packages which had met minor-release criteria but had not yet been
> > picked up in a release. `unproven' would be the latest maintainer
> > release.
>
> I don't believe this is workable. First, I doubt that enough
> developers would have the required system resources to work on 3 (or
> more) different releases at the same time. Second, Debian has a
> purely volunteer work force. It's hard enough already getting a
> sustained effort working on a single release. If that effort was
> diminished by dividing the volunteers across multiple releases,
> nothing would ever get done.
I don't think I succeeded in communicating my suggestion very well.
I was speaking of just two releases above, debian-current (e.g., bo),
and debian-next (e.g., hamm). The bo->hamm development model stabilized
the package set released with bo a year or so ago as the production
release, except for serious bugfixes, and concentrated both system
development effort and package maintenance effort in the essentially
debian-developer-only hamm release. Now, a year or so later, users of
the the year-old debian 1.3.x release are using packages several revisions
behind what the users of other linux distributions are using.
I suspect that you are correct that many package maintainers probably
do not have the resources and the time to work on two or more releases.
For bo->hamm, debian chose to concentrate both the development effort
for the next system release and the package maintainer effort in the
mostly debian-developer-only hamm release. I am suggesting that, in
future, system development effort be focused on the developmental system
release, but that package maintenance effort be concentrated on the
current production release used by the debian user community.
The current production debian release would move forward in a series of
regular minor releases, incorporating new and updated packages. The
packages incorporated into the release would initially be considered
`unproven'. Unproven packages would go through some sort of validation
(details TBD), after which they would be considered `proven'. At
periodic release intervals, `proven' packages would be incorporated
into the production release, and the minor release number incremented.
Maintainers working on individual package maintenance would need to
do their package maintenance on a system based on the current production
release.
Development of a new system release not fully backwards compatible
with the current production release (e.g., 1.2 vs. 1.3, or 1.3 vs. 2.0)
would be done by developers able to run the new release. If these
developers also maintained individual packages, they would need to be
able to run both the current production release for package maintenance
and the new developmental release for system development. This probably
means that not all package maintainers would also be working on system
development for the next release. So be it. A smaller development team
working on next-release system development issues might well move forward
faster.
System developers working on the next system release would make a
major effort not to break backwards compatibility with packages
in current release for the current production release. In fact,
their development systems would use forward-compatible packages
from the current production release. Where it became necessary to
break inter-release compatibility for individual packages, that would
be addressed on a package-by-package basis.
At completion of system development, and prior to system release, the
situation with regard to packages with broken compatibility to the
new system release would be reviewed. These packages would need either
to be removed from the distribution or brought forward with a
new-release-compatible package revision.
David Engel
On Sat, May 30, 1998 at 01:04:41AM -0600, Bdale Garbee wrote:
[This part re-ordered for clarity]
> While we were talking, another thing that was really clear to us was that
> 'standard' and 'important' should be merged, leaving the name 'standard' for
> the combined priority. That would leave 'required' as the set of packages
> that are part of the base install, 'standard' as all the stuff that one might
> reasonably expect to be present on any normal Debian system, 'optional' as the
> place where most packages live, and 'extra' for the kinds of things that get
> shoved out there now... dangerous toys, etc. Once we get past this
> constitution thingy being ratified, I intend to propose this officially.
I agree that standard and important should probably be combined into
just standard.
> : If I understood another message correctly, the test team has
> : only recently finished checking out the required and important
> : packages, now hopes to check out all of the standard packages and
> : probably won't get to the optional and extra packages at all.
>
> If we were to beef up the documentation of what the priorities on packages
> meant, and made it clear that there was a descending scale of promised quality
> for priorities farther from 'required', I think we could take care of most of
> the problems you're identifying. Yes, there will always be some user unhappy
> about a bug, or a package that goes orphaned... but dwelling on that may be
> counter-productive.
I think you are overestimating the ability of many users to recognize
the subtle distinction between package priorities.
You sort of suggested that the dividing line between core and non-core
packages probably lies between the current optional and extra
priorities. Upon further thought, I think it might lie somewhere in
the middle of optional. Either way, what then would be the harm in
moving the extra packages to contrib?
> I had an interesting chat with one of my cohorts at work today about this
> topic. We spent some time thinking about the various Debian users we know,
> and tried to characterize what they want from the distribution. What we came
> up with was the notion that it splits three ways.
I think your characterization of users is accurate.
> The first group wants to always have the latest of everything, regardless of
> testing level or absolute stability. This includes a fair number of the
> Debian developers, and some of our more wild-eyed friends, but isn't the
> mainstream. This community can be reasonably assumed to be net-connected,
> and probably cares about CD'd only when they're doing a cold install.
The group is served fine with the unstable tree.
> The second group is CD-focussed. They are either folks who aren't on the
> net with lots of bandwidth, or who are using Debian to provide the platform
> for other work, and don't want to be "bothered" by constant change. For these
> folks, a fresh CD every half-year or year is good, and it's important that
> the bits they get be as robust and bug-free as possible. Once they install
> a package, they're making a long-term committment to that package revision.
This group hasn't historically been served well by Debian.
> We think the third group represents the primary target market for a
> distribution like Debian. This group has good net access, wants to stay
> reasonably current, but can't tolerate dealing with the worst 10% or so of
> the package churn that happens in a bleeding-edge "unstable" tree. They would
> prefer not to bump into any real problems, but they're willing to stumble once
> in a while if that's the price of keeping up with security patches, new
> development tool releases, and the like. This group might be characterized
> by those who are currently running 'hamm' on production servers, as we do at
> work.
I'm not sure that I would consder this group as the primary target for
Debian. Regardless, as long as there isn't another major change in
libc, I think this group could be served just fine with the unstable
tree when combined with liberal use of dpkg/dselect's hold (i.e.
don't upgrade) feature.
> The insight we had was that for this third group, formal testing is icing on
> the cake, and not really required. If we were to implement a "package pool
> with symlink trees" approach such as I described yesterday, we might envision
> training our automation not only to routinely build a symlink tree of the
> latest versions of each package for the first group, but also to build a
> "stable but unreleased" tree for this third group. The key concept is that
That's an interesting approach. I wonder how well the "stability
implied by package age" approach would work out in real life.
On Sat, May 30, 1998 at 05:40:52PM +0800, Bill Mitchell wrote:
> > I don't believe this is workable. First, I doubt that enough
> > developers would have the required system resources to work on 3 (or
> > more) different releases at the same time. Second, Debian has a
> > purely volunteer work force. It's hard enough already getting a
> > sustained effort working on a single release. If that effort was
> > diminished by dividing the volunteers across multiple releases,
> > nothing would ever get done.
>
> I don't think I succeeded in communicating my suggestion very well.
> I was speaking of just two releases above, debian-current (e.g., bo),
> and debian-next (e.g., hamm). The bo->hamm development model stabilized
Perhaps I did misunderstand part of your suggestion. I still stand by
my second though. Dividing the limited (vast as it is) work force
available to Debian is a bad thing.
I sincerely hope, and mostly believe, that Debian won't have to deal
with such a major change as a libc replacement again any time soon.
That being the case, I don't think we should dwell any further on how
that affected the delay in Debian 2.0 who to prevent it from happening
again.
David
--
David Engel ODS Networks
da...@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
Anthony Towns
> On Sat, May 30, 1998 at 01:04:41AM -0600, Bdale Garbee wrote:
> > While we were talking, another thing that was really clear to us was that
> > 'standard' and 'important' should be merged, leaving the name 'standard'
> > for the combined priority.
I began this message thinking I was going to be pointing out that things
like "cron" [Important] and "cvs" [Standard] really deserve different
priority levels. But actually having gone through dselect's list of
Important packages, there's really not all that much stuff there. So
here's another "aye", fwiw.
> > That would leave 'required' as the set of
> > packages that are part of the base install, 'standard' as all the stuff
> > that one might reasonably expect to be present on any normal Debian
> > system,
This is slightly different to what 'standard' means at the moment,
I believe -- anything one might reasonably expect to be present on any
normal Unix system.
And it gives me the opportunity to suggest that we should consider moving
things like bug into standard.
[btw, is there any reason anacron is priority extra? It's supposed to be
a normal sort of thing to install on machines that aren't permanently up,
which I suspect isn't quite "unusual requirements"...]
The other thing that's worth considering is how much of this would be
better solved by using a different classifcation scheme.
When, for example, we develop a method for tagging packages as being
appropriate for "Unix workstation", "X Terminal", "Network server",
"ISP" and whatever else, we could also list packages that are "Certified
by the Debian Testing Group". [0]
> > If we were to beef up the documentation of what the priorities on packages
> > meant, and made it clear that there was a descending scale of promised
> > quality for priorities farther from 'required', I think we could take
> > care of most of the problems you're identifying. Yes, there will always
> > be some user unhappy about a bug, or a package that goes orphaned... but
> > dwelling on that may be counter-productive.
> I think you are overestimating the ability of many users to recognize
> the subtle distinction between package priorities.
*shrug* I expect there are people who curse RedHat for dodgy packages
uploaded to their contrib directory.
I can't see us getting a final answer here, but being able to say "We
don't have the manpower to test all our packages. We focus on the Required
and Standard packages. If you'd like to help, join the -testing group"
should go most of the way.
> You sort of suggested that the dividing line between core and non-core
> packages probably lies between the current optional and extra
> priorities. Upon further thought, I think it might lie somewhere in
> the middle of optional. Either way, what then would be the harm in
> moving the extra packages to contrib?
Debian's dedicated to providing a free operating system. It's the first
thing our proposed constitution says, even. I think it's nice to keep
the distribution split up into "free", "free, but needs non-free stuff"
and "non-free", without dirtying the water.
[three sorts of user, rearranged, with trimming and extra comments:]
> > The first group wants to always have the latest of everything, regardless
> > of testing level or absolute stability.
...who don't require any special testing, but do want daily updates or
similar.
> > We think the [second] group represents the primary target market for a
> > distribution like Debian. This group has good net access, wants to stay
> > reasonably current, but can't tolerate dealing with the worst 10% or so of
> > the package churn that happens in a bleeding-edge "unstable" tree.
> > They would prefer not to bump into any real problems, but they're willing
> > to stumble once in a while if that's the price of keeping up with security
> > patches, new development tool releases, and the like.
...who don't want anything common to break [like grep only working on
stdin, for example], and thus need a buffer of the first sort of users
between them and the latest release. They'd like irregular updates, so
that packages wouldn't get more than a month out of date, say.
> > The [third] group is CD-focussed. They are either folks who aren't on the
> > net with lots of bandwidth, or who are using Debian to provide the platform
> > for other work, and don't want to be "bothered" by constant change.
...who don't really want anything to break that could have been fixed,
and who don't really want updates more than a few times a year [once
every six, four or three months, say].
I think all are fairly reasonable uses of Debian GNU/Linux, and I'm
inclined to thinking that they cover enough of the Linux community,
and are distinct enough to be worth a different categorisation each.
Since it seems to be the current trend, I'm going to throw in YA
suggestion on how to rework the distribution process. I trust Guy,
Brian et al will take the bits of these that have a chance of working,
put them together, and we'll all live happily ever after.
What I'm about to suggest is based somewhat on the philosophy of ensuring
we're always just a step away from being ready to release; rather than
having huge amounts of pointless administrative style junk like we're
stuck with now. Ironically, it's an idea I first heard about from a
Microsoft book.
Anyway, I suspect that a slight restructuring of what we consider
"stable", "frozen", and "unstable" would work reasonably well. Basically,
having "stable" be exactly what it is now -- tested as well as we can
manage, and dedicated to being reliable rather than particularly up to
date; "unstable" more or less the same, the distribution you add new
stuff to and do whatever to.
But rather than having "unstable" be the working copy of the next release,
I was thinking of giving that title to "frozen", leaving "unstable"
more along the lines of the release after that.
Packages could only be moved to "frozen" after being static in "unstable"
for a week or so, and with no release-critical bugs filed against them
and with the release manager / the testing groups permission.
The testing group then has the entire three, four or six month release
cycle to spend testing packages, installs, and whatever else before
releasing, and important or interesting updates can be easily added to
the distribution. Meanwhile, CDs can be burnt from the frozen release
with the knowledge that while it won't be perfect, it'll be pretty damn
good nevertheless.
There'd probably be a fair amount of redundancy in the work the testers
would have to do [``There's a new version of foo! You *gotta* include
this! It's so cool!'' ``But we've already spent *aeons* testing the old
version!!''], but with some automated assistance, and the extra time they
should be able to afford, I don't think this would be too huge a problem.
It'd probably be a good idea to get weekly or fortnightly CD images of
`frozen' made available on ftp.debian.org or similar, too.
Transitional releases are something we probably ought to start
expecting, too. From what I've read, *every* release of Debian has been a
transitional release [a.out -> ELF, libc5 -> glibc, FSSTND -> FHS, ...],
and I think the above would work reasonably well for that. We could,
for example, make releases with a process something like:
bo-released: stable = libc5, unstable = libc5 + misc updates
Then we discover that getting libc6 bootdisks is difficult, say, so we
can't move to libc6 yet in its entirety, but there's some neat libc5
enhancements to various programs, so those are added to frozen, while
people work on bootdisks in unstable.
stable = libc5, frozen = libc5+misc updates, unstable = libc6 + libc5
Then we decide, yup, frozen's stable enough, so let's make a point
release, so we relink stable to frozen, and release 1.3.1, say.
Then we finally get bootdisks compiled in unstable, and a fair few of
our packages have gone libc6, so we move libc6 into frozen, and start
testing it.
stable = libc5+misc u/dates, frozen = libc6/libc5, unstable = libc6/libc5
Then we decide it's time to go on a libc6 recompiling spree, and end up
with all of unstable recompiled to libc6, say, just when the testing group
get frozen tested. [and you *know* something like that's going to happen]
So the testing group get fed up and decide to release what they've done so
far as pre2.0 or 1.99, or just plain 2.0, or whatever, and we end up with:
stable = libc6/libc5, frozen = libc6, unstable = libc6, FSSTND/FHS
And we keep on moving on.
As is probably obvious, I tend to think it's probably more feasible to
move the "base" packages over to {libc6,FHS,the new debian-doc standard,
whatever} and then move everything else over in the next release cycle.
Cheers,
aj
[0] I'm assuming that we'd have a file something like:
Category: Unix Workstation
Packages: cron | anacron, mail-transport-agent,
mail-reader, ...
Category: X Terminal
Packages: xbase, xserver, ...
In which case adding:
Category: Certified by the Debian Testing Group
Packages: perl, perl-base, cron, ...
Would be quite simple.
I'm tempted to go further and suggest that packages be grouped
in a manner similar to:
Category: Unix Workstation
Required: binutils, textutils, vi, sysvinit, ...
Standard: emacs, tex, rcs, make
Optional: ...
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``It's not a vision, or a fear. It's just a thought.''
Raul Miller
On Sun, May 31, 1998 at 12:55:20AM -0500, David Engel wrote:
> > You sort of suggested that the dividing line between core and non-core
> > packages probably lies between the current optional and extra
> > priorities. Upon further thought, I think it might lie somewhere in
> > the middle of optional. Either way, what then would be the harm in
> > moving the extra packages to contrib?
Anthony Towns <a...@azure.humbug.org.au> wrote:
> Debian's dedicated to providing a free operating system. It's the first
> thing our proposed constitution says, even. I think it's nice to keep
> the distribution split up into "free", "free, but needs non-free stuff"
> and "non-free", without dirtying the water.
Agreed: our current "contrib" classification says something about
the licensing issues, and that's important.
It should be fairly easy for someone to split optional into optional but
recommended and whatever. I don't want to do the split, however, and
I'd really like the description of the split to be clear enough to
avoid several tens of megabytes of discussion on it by next year.
> But rather than having "unstable" be the working copy of the next release,
> I was thinking of giving that title to "frozen", leaving "unstable"
> more along the lines of the release after that.
>
> Packages could only be moved to "frozen" after being static in "unstable"
> for a week or so, and with no release-critical bugs filed against them
> and with the release manager / the testing groups permission.
>
> The testing group then has the entire three, four or six month release
> cycle to spend testing packages, installs, and whatever else before
> releasing, and important or interesting updates can be easily added to
> the distribution. Meanwhile, CDs can be burnt from the frozen release
> with the knowledge that while it won't be perfect, it'll be pretty damn
> good nevertheless.
I like this idea, and it kind of matches some of what I was trying to
figure out how to express, and it looks like it matches what Bdale
was suggesting with his "pool of packages". Basically, the developers
part of the ftp site is the simple part, the test&release part is
the big complex part -- we already acknowlege this to some degree
(look at our bug tracking system), but we still put an awful lot
of load on the shoulders of the ftp site maintainer.
Furthermore, we have this practice of pulling stuff out of "incoming"
but we don't really take advantage of it.
And, there's this whole thing where many people have observed that
testing is far more parallizable than development.
So what are we doing about it?
Recommended reading (just a rehash of the messages in this
thread that I think are significant):
David Engel's second rehash of the problem: [important]
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01511.html
Buddha Buck's counterpoints:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01531.html
David Engel's clarifications on a few points:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01608.html
Guy Maor's quick summary:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01623.html
Bdale Garbee's ftp site cleanup proposal: [important]
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01632.html
Bdale Garbee's groupings of debian users:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01721.html
Unfortunately, the message I'm responding to doesn't seem to be up
in the archives, yes. I'd also like to classify it as important.
So I'm going to include the rest of it verbatim.
--
Raul
--
Bdale Garbee
In article <19980531005520.A6485@elo> you wrote:
: You sort of suggested that the dividing line between core and non-core
: packages probably lies between the current optional and extra
: priorities.
Actually, I think everything through 'standard' is core, optional and extra
get lumped together pretty often in my mind.
: Upon further thought, I think it might lie somewhere in
: the middle of optional. Either way, what then would be the harm in
: moving the extra packages to contrib?
Probably nothing. I think the line between standard and optional, and the
line between optional and extra, have been pretty fuzzy. In an era when it
all fit on one CD, it really didn't matter how things were prioritized. If
we get to the point where thers is a difference in testing level, or the bits
are spread across units of distribution media, then these priorities will
become more clear... we'll care more about getting stuff in the right
priorities... and users would pay more attention to package priority. Yeah,
I know, that last is blue-sky... :-)
:> The second group is CD-focussed.
: This group hasn't historically been served well by Debian.
True. I think this whole discussion of core and testing derives from that
fact, to some extent.
: That's an interesting approach. I wonder how well the "stability
: implied by package age" approach would work out in real life.
I don't know. The behavior that we realized we observe today is that people
in this category seem to wait for there to be a lull in the package upload
rate before they freshen the system. Thus, we hypothesize that the "churn
rate" on packages might be a good first-order indicator of stability, if not
absolute quality.
It seems like an experiment or two with a tree built this way might be in
order for slink.
: I sincerely hope, and mostly believe, that Debian won't have to deal
: with such a major change as a libc replacement again any time soon.
Amen, brother! :-)
I do a lot of embedded systems work, and am painfully aware of libc funnies
there. I'd really love it if my development platform's libc stabilized and
just didn't change in any meaningful way for a *long* time...
Bdale
Guy Maor
"David Engel " <da...@ods.com> writes:
> I've seen some people
> suggesting that Debian should re-evaluate every package when release
> time rolls around and only include those packages that are deemed
> stable at that time. The consequence is that the packages which
> aren't deemed stable are removed and the users that might need them
> are just out of luck.
Not removed, just left in unstable. Is that undesirable?
I think this is better than your proposal of splitting Debian into
core and non-core parts, and only releasing stable versions of core.
I would release stable versions of whatever is ready, all of the
"core" packages and anything else. So if a noncore, but well-tested,
package is deemed stable, it can be released. The decisions of which
packages to release as stable and which to not is easier than a
decision to make a package core or not.
Once a package is deemed noncore, it is forever second-tier, always to
be left in a contrib section where a stable version can not be
branched off.
Guy
Rev. Joseph Carter
> just standard.
Prolly, yes.
> You sort of suggested that the dividing line between core and non-core
> packages probably lies between the current optional and extra
> priorities. Upon further thought, I think it might lie somewhere in
> the middle of optional. Either way, what then would be the harm in
> moving the extra packages to contrib?
Only that Contrib means "Depends on non-free software"...
> > The first group wants to always have the latest of everything, regardless of
> > testing level or absolute stability. This includes a fair number of the
> > Debian developers, and some of our more wild-eyed friends, but isn't the
> > mainstream. This community can be reasonably assumed to be net-connected,
> > and probably cares about CD'd only when they're doing a cold install.
>
> The group is served fine with the unstable tree.
It works. => I will admit to being somewhat part of this group. I'm
somewhere bewteen here and the third.
> > The second group is CD-focussed. They are either folks who aren't on the
> > net with lots of bandwidth, or who are using Debian to provide the platform
> > for other work, and don't want to be "bothered" by constant change. For these
> > folks, a fresh CD every half-year or year is good, and it's important that
> > the bits they get be as robust and bug-free as possible. Once they install
> > a package, they're making a long-term committment to that package revision.
>
> This group hasn't historically been served well by Debian.
This group hasn't historically been served well by Linux. Linux itself is a
big moving target and drivers aren't modular enough now to be included with
hardware. If you upgrade hardware, you can bet you'll need a new kernel at
least.
> > We think the third group represents the primary target market for a
> > distribution like Debian. This group has good net access, wants to stay
> > reasonably current, but can't tolerate dealing with the worst 10% or so of
> > the package churn that happens in a bleeding-edge "unstable" tree. They would
> > prefer not to bump into any real problems, but they're willing to stumble once
> > in a while if that's the price of keeping up with security patches, new
> > development tool releases, and the like. This group might be characterized
> > by those who are currently running 'hamm' on production servers, as we do at
> > work.
>
> I'm not sure that I would consder this group as the primary target for
> Debian. Regardless, as long as there isn't another major change in
> libc, I think this group could be served just fine with the unstable
> tree when combined with liberal use of dpkg/dselect's hold (i.e.
> don't upgrade) feature.
dselect's hold feature is brain-dead and is ignored everywhere but in
dselect. High hopes for apt.
And the lack of frequent update CDs makes me a little uneasy about using the
unstable tree. I do because I have the most essential stuff backed up, but
it would hurt lots if I lost my drive for some reason. I plan to order hamm
on CD as soon as hamm is there on CD to order.
> > The insight we had was that for this third group, formal testing is icing on
> > the cake, and not really required. If we were to implement a "package pool
> > with symlink trees" approach such as I described yesterday, we might envision
> > training our automation not only to routinely build a symlink tree of the
> > latest versions of each package for the first group, but also to build a
> > "stable but unreleased" tree for this third group. The key concept is that
>
> That's an interesting approach. I wonder how well the "stability
> implied by package age" approach would work out in real life.
It wouldn't. If you were gonna do a "stable but not yet released" tree
similar to bo-updates packages would need to be moved in to it as the
packages became stable. I've described how I can see this working a couple
of times, the gist of it is that after a time if there aren't any stability
affecting bugs you can call the package stable if everything else the
package depends on etc is stable. If there are after that time open serious
bugs, the package can't be moved to stable till they're closed/downgraded as
appropriate.
> I sincerely hope, and mostly believe, that Debian won't have to deal
> with such a major change as a libc replacement again any time soon.
> That being the case, I don't think we should dwell any further on how
> that affected the delay in Debian 2.0 who to prevent it from happening
> again.
What about glibc 2.1? => <hides>
Joel Klecker
At 11:44 -0700 1998-05-31, Rev. Joseph Carter wrote:
>What about glibc 2.1? => <hides>
That's not a major change.
--
Joel "Espy" Klecker
Debian GNU/Linux Developer
<mailto:j...@espy.org>
<http://web.espy.org/>
Bill Mitchell
the current release while doing system upgrade development separately,
and (2) setting up package release mechanics which provide `released',
`proven', and `unproven' package release stages fits well with the
following:
On Sun, 31 May 1998, Anthony Towns wrote:
<snip>
> [three sorts of user, rearranged, with trimming and extra comments:]
>
> > > The first group wants to always have the latest of everything, regardless
> > > of testing level or absolute stability.
>
> ....who don't require any special testing, but do want daily updates or
> similar.
Those really living on the bleeding edge keep current from the developmental
tree for the next-release system.
Those wishing to be buffered from system development instabilities but
wanting new packages as soon as they are released update from the current
debian system release tree, the `unproven' subtree. This is where package
maintainer releases show up. Bugs reported by these users can keep a buggy
package from advancing into the `proven' subtree.
> > > We think the [second] group represents the primary target market for a
> > > distribution like Debian. This group has good net access, wants to stay
> > > reasonably current, but can't tolerate dealing with the worst 10% or so of
> > > the package churn that happens in a bleeding-edge "unstable" tree.
> > > They would prefer not to bump into any real problems, but they're willing
> > > to stumble once in a while if that's the price of keeping up with security
> > > patches, new development tool releases, and the like.
>
> ....who don't want anything common to break [like grep only working on
> stdin, for example], and thus need a buffer of the first sort of users
> between them and the latest release. They'd like irregular updates, so
> that packages wouldn't get more than a month out of date, say.
These update from the `proven' subtree. Bugs reported by these users can
eliminate a buggy package from the `proven' subtree and/or keep it from
advancing into the `released' subtree.
> > > The [third] group is CD-focussed. They are either folks who aren't on the
> > > net with lots of bandwidth, or who are using Debian to provide the platform
> > > for other work, and don't want to be "bothered" by constant change.
>
> ....who don't really want anything to break that could have been fixed,
> and who don't really want updates more than a few times a year [once
> every six, four or three months, say].
These update from the `released' subtree.
Note that the `released' subtree has its minor version number incremented
with each new release (picking up new & updated packages from the `proven'
subtree). Thus, for example, different CD offerings of debian 2.0.3 would
be identical, even if mastered separately by different CD manufacturers on
dates several weeks apart. The `proven' and `unproven' subtrees would
not be release-numbered, and snapshots taken on different dates would
likely differ from one another.
CD manufacturers having a release cycle shorter than our cycle of minor
releases could offer ever-later snapshots of the `proven' and `unstable'
subtrees on CD releases pressed for the same debian minor system release
version.
<snip>
> Since it seems to be the current trend, I'm going to throw in YA
> suggestion on how to rework the distribution process.
<suggestion snipped, but paraphrased and addressed below>
This, as I understand it, concerns managing releases from what I have called
the developmental tree above. That is, the tree where development of the
next system release is going on.
As I understand it, this would apply release mechanics there similar to
what I have suggested above for the ongoing package releases for the
current production debian system release. The development system would
be stabilized at some plateau, and a frozen snapshot of the system at
that stage of development split off. Development would then continue
in the unstable development tree to the next plateau.
> Packages could only be moved to "frozen" after being static in "unstable"
> for a week or so, and with no release-critical bugs filed against them
> and with the release manager / the testing groups permission.
My suggestion would be to have the developmental tree use the latest
packages released to the `unproven' subtree of the production release.
Maintaining inter-release compatibility would be a priority for the
system development team. Inter-release compatibility would be broken
where necessary, but efforts would be made to avoid this. Development
plateaus would not be concerned with the package mix, but rather with
some intermediate level of next-system-release development having been
reached.
If the new system release involved a new libc release, the new libc and
related development tools would be put into place and tested. Backwards
compatibility with old-libc packages would be maintained. The new
system would proceed to release with development tools using the new
libc by default, but with most packages on the system still using the
still-supported old libc. This, then, becomes the production system where
package maintenance is focused. In a series of subsequent minor system
releases, then, individual packages would move from the old libc to the
new libc.
<snip>
David Engel
On Sun, May 31, 1998 at 11:32:45AM -0700, Guy Maor wrote:
> Not removed, just left in unstable. Is that undesirable?
>
> I think this is better than your proposal of splitting Debian into
> core and non-core parts, and only releasing stable versions of core.
This discussion has been getting away from the original issue that I
brought up -- the need to make more frequent releases. I am going to
get back to that in the new thread started by Raul Miller with subject
"Debian Re-organization proposals". Before doing that though, I need
to correct the misunderstanding above.
I never proposed only releasing stable versions or core packages. In
fact, I am in favor of including all packages that meet the DSFG on
release CDs, but that the distinction between core and non-core (and
all that it implies) be clearer than it currently is.
David
--
David Engel ODS Networks
da...@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
Rev. Joseph Carter
> And it gives me the opportunity to suggest that we should consider moving
> things like bug into standard.
YES, this is VERY IMPORTANT if you ask me (and nobody did).
> [btw, is there any reason anacron is priority extra? It's supposed to be
> a normal sort of thing to install on machines that aren't permanently up,
> which I suspect isn't quite "unusual requirements"...]
Prolly because anacron conflicts lots with cron and cron is important. =>
Of course, someone decided sendmail is extra too, and that's the most
standardized daemon in existance for unix in general.
> The other thing that's worth considering is how much of this would be
> better solved by using a different classifcation scheme.
>
> When, for example, we develop a method for tagging packages as being
> appropriate for "Unix workstation", "X Terminal", "Network server",
> "ISP" and whatever else, we could also list packages that are "Certified
> by the Debian Testing Group". [0]
That's AFAIK for the installation scripts only.
> *shrug* I expect there are people who curse RedHat for dodgy packages
> uploaded to their contrib directory.
Not so much really I suspect. I think they would tend to blame the
maintainers of the rpms since RedHat goes out of their way to be sure you
know contrib != Redhat.
> Debian's dedicated to providing a free operating system. It's the first
> thing our proposed constitution says, even. I think it's nice to keep
> the distribution split up into "free", "free, but needs non-free stuff"
> and "non-free", without dirtying the water.
Agreed!
> [three sorts of user, rearranged, with trimming and extra comments:]
>
> > > The first group wants to always have the latest of everything, regardless
> > > of testing level or absolute stability.
>
> ...who don't require any special testing, but do want daily updates or
> similar.
We've already agreed unstable takes care of them.
> ...who don't want anything common to break [like grep only working on
> stdin, for example], and thus need a buffer of the first sort of users
> between them and the latest release. They'd like irregular updates, so
> that packages wouldn't get more than a month out of date, say.
That is certainly a release critical bug. => Generally I figured as
packages didn't have these it was safe to call them "stable". Figuring them
into my idea is easy because the stable tree fits them fine since it would
be updated as packages moving in to it were ready to be called stable.
> > > The [third] group is CD-focussed. They are either folks who aren't on the
> > > net with lots of bandwidth, or who are using Debian to provide the platform
> > > for other work, and don't want to be "bothered" by constant change.
>
> ...who don't really want anything to break that could have been fixed,
> and who don't really want updates more than a few times a year [once
> every six, four or three months, say].
These guys would get the 3-6 month stable CD's. Just before these would be
released (couple weeks) you'd freeze stable and fix anything that's
last-minute and make sure all the install scripts work okay.
> I think all are fairly reasonable uses of Debian GNU/Linux, and I'm
> inclined to thinking that they cover enough of the Linux community,
> and are distinct enough to be worth a different categorisation each.
>
> Since it seems to be the current trend, I'm going to throw in YA
> suggestion on how to rework the distribution process. I trust Guy,
> Brian et al will take the bits of these that have a chance of working,
> put them together, and we'll all live happily ever after.
Not many have commented on my ideas much, but those who have commented
liked them. I'm SURE there's something I'm overlooking, but nobody has seen
it and commented yet. So far it seems to address everybody's concerns and
doesn't leave anybody out in the cold (which is a not insignificant ego
boost to someone who by all rights is still a Linux rookie) so I am going to
believe for now that it's genuinely a good and well thought-out idea till
someone points out a major problem with it.
It sure beats just freezing/releasing unstable at fixed intervals.
> What I'm about to suggest is based somewhat on the philosophy of ensuring
> we're always just a step away from being ready to release; rather than
> having huge amounts of pointless administrative style junk like we're
> stuck with now. Ironically, it's an idea I first heard about from a
> Microsoft book.
Which is very similar to mine now that I reread it.
> Anyway, I suspect that a slight restructuring of what we consider
> "stable", "frozen", and "unstable" would work reasonably well. Basically,
> having "stable" be exactly what it is now -- tested as well as we can
> manage, and dedicated to being reliable rather than particularly up to
> date; "unstable" more or less the same, the distribution you add new
> stuff to and do whatever to.
I would have changed "stable" to "official"--the last official CD release
version. This tree should not have symlinks to anywhere considering that
it's what someone would burn for the current "official version"..
Unstable would exist kinda as it does now. Packages get moved from Incoming
directly here. "testing" would be a better name for it, but "unstable"
should keep people who shouldn't touch it away. It would be like slink is
now, not a full dist. It's a suppliment, not a dist per se.
Frozen would not exist as it does now. However the closest equivalent would
be "stable". The new stable dist would in fact be stable---more so than
hamm. It'd essentially start as a tree of symlinks to official. Then as a
package in unstable is deemed appropriate for stable, it's moved there and
if there's an older package (link or file) it'd be replaced.
Stable would be expected to WORK and not have any major bugs, but stable may
be in-between goals. Ie, it's been possible in hamm since long before I
started using it to have a libc5 and 6 system.. Stable should be kept
backwards compatible with the last dist--enough that it runs (though for
example the FSSTND -> FHS goal may have files in odd places for a bit.
At regular intervals and/or when determined to be "time for a release", any
symlinks in stable are made into files and the whole mess gets no more
updates for a few weeks while the last bits of testing and any pending
install updates are fixed. Then stable becomes official and we start a new
stable symlink tree.
As for project/experimental.... Do we need to mess with this? Other than
maybe the Packages.gz file which makes no sense to me since it seems it
would be MASSIVELY unwise to use it, even if you use packages out of
experimental (apt).. Feel free to correct me if I'm wrong.
This fits all three types of users and gives up to two levels of fallback if
a new version of something in unstable breaks. If it breaks in stable, it's
a problem but can be fixed. By official, nothing should be obviously
broken, we can hope. =>
> But rather than having "unstable" be the working copy of the next release,
> I was thinking of giving that title to "frozen", leaving "unstable"
> more along the lines of the release after that.
I more or less changed the names to be more descriptive, but that's kinda
what I've been talking about.
> Packages could only be moved to "frozen" after being static in "unstable"
> for a week or so, and with no release-critical bugs filed against them
> and with the release manager / the testing groups permission.
I was thinking for a low urgency package more like a month. With the
exception of a Linux kernel, people can wait this long I hope.
> The testing group then has the entire three, four or six month release
> cycle to spend testing packages, installs, and whatever else before
> releasing, and important or interesting updates can be easily added to
> the distribution. Meanwhile, CDs can be burnt from the frozen release
> with the knowledge that while it won't be perfect, it'll be pretty damn
> good nevertheless.
I kinda figured testing as a more ongoing thing. If you use packages in
unstable and find a bug, report it. Simple as that. Testing for stable to
official should not need to be much, we would hope.
> There'd probably be a fair amount of redundancy in the work the testers
> would have to do [``There's a new version of foo! You *gotta* include
> this! It's so cool!'' ``But we've already spent *aeons* testing the old
> version!!''], but with some automated assistance, and the extra time they
> should be able to afford, I don't think this would be too huge a problem.
I thought about this too, see above. =>
> It'd probably be a good idea to get weekly or fortnightly CD images of
> `frozen' made available on ftp.debian.org or similar, too.
Just let the CD venders know they can do this with the stable tree..
CheapBytes would with their Debian Hot Off the Press (which isn't a press,
it's a burn, but hey..) We should make a README.stable indicating this is
generally just fine.
> Transitional releases are something we probably ought to start
> expecting, too. From what I've read, *every* release of Debian has been a
> transitional release [a.out -> ELF, libc5 -> glibc, FSSTND -> FHS, ...],
> and I think the above would work reasonably well for that. We could,
> for example, make releases with a process something like:
>
> bo-released: stable = libc5, unstable = libc5 + misc updates
Debian's good with backward compatibility. If we make that a goal for the
stable and unstable trees (backward compatibility with the last release)
then the libc5 -> 6 upgrade would be no biggie. Hamm is backward compatible
with bo as it is if you install altgcc and libc5-altdev. We should follow
that sort of a tradition.
> Then we discover that getting libc6 bootdisks is difficult, say, so we
> can't move to libc6 yet in its entirety, but there's some neat libc5
> enhancements to various programs, so those are added to frozen, while
> people work on bootdisks in unstable.
>
> stable = libc5, frozen = libc5+misc updates, unstable = libc6 + libc5
>
> Then we decide, yup, frozen's stable enough, so let's make a point
> release, so we relink stable to frozen, and release 1.3.1, say.
As soon as libc6 is deemed stable it can be moved, and if any other libc6
packages were already considered stable they could move in a week or so.
> Then we finally get bootdisks compiled in unstable, and a fair few of
> our packages have gone libc6, so we move libc6 into frozen, and start
> testing it.
>
> stable = libc5+misc u/dates, frozen = libc6/libc5, unstable = libc6/libc5
>
> Then we decide it's time to go on a libc6 recompiling spree, and end up
> with all of unstable recompiled to libc6, say, just when the testing group
> get frozen tested. [and you *know* something like that's going to happen]
>
> So the testing group get fed up and decide to release what they've done so
> far as pre2.0 or 1.99, or just plain 2.0, or whatever, and we end up with:
>
> stable = libc6/libc5, frozen = libc6, unstable = libc6, FSSTND/FHS
>
> And we keep on moving on.
Very much like I've been saying.. GMTA! =>
> As is probably obvious, I tend to think it's probably more feasible to
> move the "base" packages over to {libc6,FHS,the new debian-doc standard,
> whatever} and then move everything else over in the next release cycle.
Yes, for anything in base or priorities of standard on up there should be a
grace period before upgrading packages dependant on these changes, just in
case. The libc6 issue is a good reason. libc6 may be stable, and
libc6-using packages may be stable, but if you move them all at once you
have a higher chance of breaking SOMETHING which would be bad.
> [0] I'm assuming that we'd have a file something like:
> Category: Unix Workstation
> Packages: cron | anacron, mail-transport-agent,
> mail-reader, ...
>
> Category: X Terminal
> Packages: xbase, xserver, ...
>
> In which case adding:
>
> Category: Certified by the Debian Testing Group
> Packages: perl, perl-base, cron, ...
>
> Would be quite simple.
No need under my proposed design, which is admittedly similar to yours other
than how packages get moved.
> I'm tempted to go further and suggest that packages be grouped
> in a manner similar to:
>
> Category: Unix Workstation
> Required: binutils, textutils, vi, sysvinit, ...
> Standard: emacs, tex, rcs, make
> Optional: ...
Nah. Required packages for Debian don't change no matter what application
you have in mind. Standard packages in Debian should be on the system in
most cases, with the exception of when you KNOW you want different. Some
install options like router or such might not use all the standard packages,
but there's no reason to change that.
Optional packages are optional to debian, though they may be required for
some things. Extra should still be toys that may break stuff in other
classifications, etc but then again in some cases that's what you want and
it should be there for some installations. Doesn't change that they're
generally not needed/wanted for most systems.
Priority should remain a Debian system thing, not an application specific
one.
I would suggest that the install scripts should let you choose any of these
in place of showing you apt. It should allow custom (select required and
standard packages and toss you in apt to figure out what in addition you
want) and other (locate a profile listing packages to install, that's not in
the list--useful for installing several machines I'd imagine)
I await people's opinions! =>
Raul Miller
Rev. Joseph Carter <kngh...@earthlink.net> wrote:
> Prolly because anacron conflicts lots with cron and cron is important. =>
From dpkg -s anacron:
Recommends: cron (>= 3.0pl1-43)
--
Raul
Rev. Joseph Carter
> > Prolly because anacron conflicts lots with cron and cron is important. =>
>
> >From dpkg -s anacron:
>
> Recommends: cron (>= 3.0pl1-43)
Oh? Interesting. This makes me ask then as well: Why not move this to
Standard priority? It was apparently explained to me incorrectly.
Craig Sanders
On Fri, 29 May 1998, Philip Hands wrote:
> > Sorry, now I don't understand. I think we should release twice a year.
>
> What about encouraging people to press ``Debian Unstable Snapshots''
> once every couple of months.
>
> We could do the snapshot images ourselves (so that everyone's ``May
> 98'' image was exactly the same), give it a few days testing to ensure
> that it's not completely broken, and suggest in the documentation that
> people look at the web site for any problems and work-arounds found
> after release.
>
> As long as it is published with warnings that it is just a snapshot,
> and not a tested release, we should not be tarnish our image, while
> providing the bandwidth limited folks with an alternative ``download''
> method.
yes, i think this is essential....but it should be every month, not
every 2 or 3.
so this means we need automated tools which can seamlessly make a
snapshot cd image from the current unstable tree.
i also think that debian should have three main teams:
1. developers. this is everyone, including members of teams 2 & 3.
release packages into unstable as usual. develop neat things like
install-mime and menu and so on. hack, hack, hack.
2. release team. they do whatever they need to do to make a release.
if they need to modify a package, they just do it without waiting
for the package maintainer to get around to it. they should submit
their mods to the maintainer, but are not bound by the maintainer's
packaging decisions - the release is their baby, and their word is
final.
3. marketing and market research team. promotion of debian, and
researching user's needs/wants. drafting proposals to implement those
needs.
craig
--
craig sanders
Craig Sanders
On Sat, 30 May 1998, Bdale Garbee wrote:
> I had an interesting chat with one of my cohorts at work today about
> this topic. We spent some time thinking about the various Debian
> users we know, and tried to characterize what they want from the
> distribution. What we came up with was the notion that it splits
> three ways.
> [...deleted...]
Wow!
an excellent post. couldn't agree with it more.
(btw, this sort of thing is one the things i envisioned being done by
the 'marketing & market research' team i suggested).
> We think the third group represents the primary target market for a
> distribution like Debian. This group has good net access, wants to
> stay reasonably current, but can't tolerate dealing with the worst 10%
> or so of the package churn that happens in a bleeding-edge "unstable"
> tree. They would prefer not to bump into any real problems, but
> they're willing to stumble once in a while if that's the price of
> keeping up with security patches, new development tool releases,
> and the like. This group might be characterized by those who are
> currently running 'hamm' on production servers, as we do at work.
these are the people who would really benefit from having monthly or
bi-monthly snapshot cd-roms.
i think that some, but not all, would have good net access. if they
all had net access then the number of people in group 1 would be much
higher as their desires are closer to group 1 than group 2. So regular
snapshot CDs are very important for these people.
> [...deleted...] but also to build a "stable but unreleased" tree for
> this third group. The key concept is that if a package version has
> been released for some period of time (a week, a month, not sure how
> long makes sense) without being retracted or superceded, then it is,
> by definition, "stable"... even though it's absolute quality is still
> an unknown.
yes, this is a great idea too. and as you say, quite easy to automate.
> So, group one wants nothing between them and the developer's uploads,
> group two wants a human testing team to have reviewed and approved
> each package that is on their CD, and group three doesn't want to wait
> for a human testing team, but wants to distance themselves a touch
> from the bleeding edge.
so:
group 1 - usually upgrades via ftp or from a nfs-mounted local mirror.
probably a debian developer.
group 2 - upgrades from a CD release which has been through the
unstable -> frozen -> stable testing cycle.
group 3 - upgrades from monthly snapshot CD, and occasional via ftp for
some urgent fix.
this is just a 'me too' post in disguise. what you wrote says it all,
really.