Subject: Re: "buzz" created

From: [email-masked] (Bruce Perens)
Date: Thu, 13 Jun 96 10:15 PDT

I don't know if we should create a 1.1-updates directory or if we should
simply point people at the moving-target version. Some discussion might
help.

	Bruce

---

From: Rob Browning <[email-masked]>
Date: 13 Jun 1996 12:27:32 -0500

> simply point people at the moving-target version. Some discussion might

I'f we're actually going to be able to hold to the new release every
few months cycle, then I think it's probably sufficient just to point
people to the moving-target version, and it may be less confusing than
having three categories: last-stable, stable-updates, moving-target.

(my 2 cents)
--
Rob

---

From: Dale Scheetz <[email-masked]>
Date: Thu, 13 Jun 1996 13:44:43 -0400 (EDT)

> simply point people at the moving-target version. Some discussion might
As you may know, I feel strongly that the "release", whatever that is,
should be a static "thing". While development should continue, it should
do so elsewhere.

Thanks,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: Mike Coleman <[email-masked]>
Date: Thu, 13 Jun 96 12:49 CDT

Resent-Cc: recipient list not shown: ;
   Old-Return-Path: <[email-masked]>
   Date: Thu, 13 Jun 96 10:15 PDT
   From: [email-masked] (Bruce Perens)
   Cc: [email-masked], [email-masked]
   Precedence: list

The moving-target option looks good except for one (big) worry--the
possibility that a significant package with a significant bug will be present
at the moment that some significant outfit presses a cdrom of Debian.  The
Debian gets a rep as being buggy, etc.

In an alternative scenario, multiple cdrom vendors press multiple snapshots,
meaning that a single coherent errata statement (a la Redhat) is not possible.

I think we should go with the frozen, or nearly frozen snapshot (where "nearly
frozen" would mean only serious bugfixes).  This concept seems to work well
for kernel releases, and I think it would work well here, too.

--Mike

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Thu, 13 Jun 1996 20:04:12 +0200 (MET DST)

> for kernel releases, and I think it would work well here, too.

I like Guy Maors suggestion (that was mailed to debian-private) the best.
It keeps the mirror size down, and a release is a release. "buzz" must
be frozen. Otherwise you never know what version of buzz is on a CD.
buzz-fixes or buzz-upgrades cannot be frozen but that is OK. We do need
a ChangeLog in the buzz-upgrades directory though so that you can check if
a CD has all the nessecary upgrades on it.

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Guy Maor <[email-masked]>
Date: Thu, 13 Jun 1996 13:25:49 -0500 (CDT)

> for kernel releases, and I think it would work well here, too.

I agree with everything except the "nearly frozen" idea, exactly for
the reason you suggest - multiple snapshots are possible.

Read the mail I posted to debian-private a few minutes ago (or perhaps
you were one of the people on the cc list).  I outlined a method where
there would be 3 distributions -

1. a static `release' directory
2. a dynamic `release-updates' directory.  This would contain important updates
   only.
3. a dynamic `development' directory containing a mix of files and slinks to
   release.

All CD pressings have an identical static release directory.  All users
should upgrade all the packages in release-updates.  They can upgrade
to development if they're adventurous.

Guy

---

From: Mike Coleman <[email-masked]>
Date: Thu, 13 Jun 96 14:04 CDT

Date: Thu, 13 Jun 1996 13:25:49 -0500 (CDT)
   From: Guy Maor <[email-masked]>

I missed your original message, but I like your solution.  So, by analogy to
the kernel,

	(1) would correspond to kernel 1.2.0
	(2) would correspond to versions 1.2.x, and
	(3) would correspond to versions 1.3.x

Excellent.

--Mike

---

From: Doug Geiger <[email-masked]>
Date: Thu, 13 Jun 1996 15:22:55 -0400 (EDT)

> simply point people at the moving-target version. Some discussion might

I vote for a 1.1-fixes directory. This would be contain bug-fix only
updates - new releases, etc. would go into the unstable directory for the
next release.

-- Run.exe
[email-masked] http://www.ntplx.net/~runexe/ Finger me for PGP key
--------------------------------------------------------------------------
Nine megs for the secretaries fair,    | One disk to rule them all,
Seven megs for the hackers scarce,     | One disk to bind them,
Five megs for the grads in smoky lairs,| One disk to hold the files
Three megs for system source;          | And in the darkness grind 'em.
---------------------------------------------------------------------------
Hi! I'm a .signature virus!  Add me to your .signature and join in the fun!

---

From: Lars Wirzenius <[email-masked]>
Date: Thu, 13 Jun 1996 22:34:46 +0300

[ Note: I read this mailing list.  There is no need to CC me on replies,
  unless it is _really_ urgent.  I pay for my PPP connections.  Thanks. ]

> having three categories: last-stable, stable-updates, moving-target.

I agree about this.  There will be relatively few really important
bug fixes in three months.

---

From: Kevin Dalley <[email-masked]>
Date: Fri, 14 Jun 1996 07:48:23 -0700

It will be difficult to have a specific numbered release 1.2.x, unless
the x is updated each time a new package is added to the
release-updates directory.  Is this a good idea?  I suppose that we
could try 1.2.date, but that would need to be UTC.  Mirror sites
cannot guarantee timely updates.  I do believe that an release-updates
directory is necessary.  I just don't know how to number the release.
I plan to release a few less stable elements in the unstable section.
I don't want those changes going out as stable until some amount of
time has passed.

kevin

>>>>> "Mike" == Mike Coleman <[email-masked]> writes:

---

From: [email-masked]
Date: Fri, 14 Jun 1996 21:41:47 +0300

> It will be difficult to have a specific numbered release 1.2.x, unless

First, I doubt we need a three level version number.  Debian won't
make releases that often.  Two levels is enough (major number changes
when there are major changes in the distribution -- such as support
for multiple architectures or support for RPM's -- and the minor number
changes every three months).

Second, there's no difficulty.  The release has a version number, the
updates or fixes do not, precisely because it would be too silly to have
a new release number for every new package.

There will be people running `plain 1.1' and `1.1 with foo, bar, and baz
from the release-updates directory'.  (There's also going to be people
running `0.93 with most of the base in 1.1 and a lot of local hacks', but
those people tend to take care of things for themselves. :)

> I don't want those changes going out as stable until some amount of

This is why I think we're going to have a test period (`code freeze')
before making a release.  A period when only bug fixes (and, possibly,
new packages) will be placed in the soon-to-be-a-release directory.  
(Other packages will presumably put on hold or put into the 
next-release-after-the-next-release-directory.)

(Note: Upon re-reading the above, I find that I'm sounding a bit too
authoritative.  I'm not.  I haven't even produced a single package yet,
since I'm waiting for 1.1 to happen first.  All this is based on how I've
understood things are going to work, and colored by how I would like them
to work.)

-- 
Lars Wirzenius, 
[email-masked]

---

From: Mike Coleman <[email-masked]>
Date: Fri, 14 Jun 96 19:35 CDT

Date: Fri, 14 Jun 1996 07:48:23 -0700
   From: Kevin Dalley <[email-masked]>

   It will be difficult to have a specific numbered release 1.2.x, unless
   the x is updated each time a new package is added to the
   release-updates directory.  Is this a good idea?  I suppose that we
   could try 1.2.date, but that would need to be UTC.

Just to clarify, with my mention of 1.2.x I was making an analogy, not a
suggestion.  In particular, as someone else was suggesting, I think there
should be a place for "errata" packages which fix serious Debian 1.1 bugs, but
it should be a single place and not a series of 1.2.date directories.

--Mike