Re: Preparing the Release / Freezing potato

[Joseph Carter]

On Mon, Nov 08, 1999 at 06:10:04PM -0500, Adam Di Carlo wrote:
> If you are arguing that 3.0.x policy packages should be banned from
> potato, I still think you're wrong.  Instead, you should say that any
> 3.x stds compliant package much also comply with the tech ctte
> decision.

I have some 3.0.x policy packages from before the tech-ctte vote.  They're
built with debhelper and use /usr/doc.  A rebuild would result in
/usr/share/doc without pain.  I don't think they should be rebuilt on that
account alone--wasted bandwidth, especially since I believe quake-lib is
among them.

I might need to upload a new quake-lib for other reasons (internal changes
to the quake packages and their configurations themselves) but not every
3.0.x package fully complies with 3.0.x--many were FHS sans /usr/share/doc
because /usr/share/doc wasn't ready to be used.

-- 
- Joseph Carter GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED]   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--
* Knghtbrd notes he has mashed potatoes for brains tonight
 yum, can I have some?
 um ...
* Knghtbrd hides from Valkyrie



pgpHCR9xr5uzC.pgp
Description: PGP signature

Re: Preparing the Release / Freezing potato

[Raul Miller]

On Mon, Nov 08, 1999 at 06:10:04PM -0500, Adam Di Carlo wrote:
> Actually, you mean people who comply with the letter of 3.0.x,
> without complying with the tech committee decision, are breaking
> things. AFAIK, you can comply with the tech ctte w/o breaking 3.0.x
> compliance. (Note: in policy, only 3 version levels are significant.)

You're still missing the point.  The point is not what people are able
to do.  The point is that people trusting policy could reasonably make
the wrong decision.

While not as critical as the boot floppies situation, this is a release
quality issue.

-- 
Raul

Re: Preparing the Release / Freezing potato

[Adam Di Carlo]

Raul Miller <[EMAIL PROTECTED]> writes:

> On Sat, Nov 06, 1999 at 03:17:55PM -0500, Adam Di Carlo wrote:
> > You guys are all acting wierd.  Debian has never instituted a minimum
> > policy version for a release. 

> You're completely missing the point.

Well, you've overstated the point.

> Before 3.1.0.0 was out, we had policy 3.0.x.x, and any package which
> complied with that policy (which at that time was the most recent package
> version) was (is) broken, from the point of view of release management.

Actually, you mean people who comply with the letter of 3.0.x, without
complying with the tech committee decision, are breaking things.
AFAIK, you can comply with the tech ctte w/o breaking 3.0.x
compliance.  (Note: in policy, only 3 version levels are significant.)

If you are arguing that 3.0.x policy packages should be banned from
potato, I still think you're wrong.  Instead, you should say that any
3.x stds compliant package much also comply with the tech ctte
decision.

Here's hoping for seriousness about policy, without literal-mindedness
or legalistic interpretations of the same.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Preparing the Release / Freezing potato

[Raul Miller]

On Sat, Nov 06, 1999 at 03:17:55PM -0500, Adam Di Carlo wrote:
> You guys are all acting wierd.  Debian has never instituted a minimum
> policy version for a release.  Try to pretend that Policy 3.x is
> required for release is only going to delay release until 2001.  The
> only reasonable lower bound, if we wanted to have a lower bound at all
> (which I doubt), would be something like 2.5.1.

You're completely missing the point.

Before 3.1.0.0 was out, we had policy 3.0.x.x, and any package which
complied with that policy (which at that time was the most recent package
version) was (is) broken, from the point of view of release management.

Yeah, people could have ignored the policy and stuck with earlier
policy versions, but many trusted the most recent policy.

-- 
Raul

Re: Preparing the Release / Freezing potato

[Adam Di Carlo]

Raul Miller <[EMAIL PROTECTED]> writes:

> Ship's Log, Lt. Yann Dirson, Stardate 011199.1654:
> > > I was under the understanding that we should use /usr/share/man and
> > > /usr/share/info at once, without symlinks, as all readers look in both
> > > places; and that we should start moving does to /usr/share/, leaving
> > > symlinks from /usr/doc to /use/share/doc for now.
> > > 
> > > Is there a misunderstanding on my part ?
> 
> The most current policy is not suitable for release.

You guys are all acting wierd.  Debian has never instituted a minimum
policy version for a release.  Try to pretend that Policy 3.x is
required for release is only going to delay release until 2001.  The
only reasonable lower bound, if we wanted to have a lower bound at all
(which I doubt), would be something like 2.5.1.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Preparing the Release / Freezing potato

[Raul Miller]

Ship's Log, Lt. Yann Dirson, Stardate 011199.1654:
> > I was under the understanding that we should use /usr/share/man and
> > /usr/share/info at once, without symlinks, as all readers look in both
> > places; and that we should start moving does to /usr/share/, leaving
> > symlinks from /usr/doc to /use/share/doc for now.
> > 
> > Is there a misunderstanding on my part ?

The most current policy is not suitable for release.

-- 
Raul

Re: Preparing the Release / Freezing potato

[Alexander N. Benner]

Hello

Ship's Log, Lt. Yann Dirson, Stardate 011199.1654:
> 
> I was under the understanding that we should use /usr/share/man and
> /usr/share/info at once, without symlinks, as all readers look in both
> places; and that we should start moving does to /usr/share/, leaving
> symlinks from /usr/doc to /use/share/doc for now.
> 
> Is there a misunderstanding on my part ?

I am not aware of the policy status. But right now dhelp finds only some of
the packages as the HTML dir. is only created in one or the apache
configuration lists only one of them.

Greetings

-- 
Alexander N. Benner -=- [EMAIL PROTECTED] (if you like, remove the NO)

Re: Preparing the Release / Freezing potato

[Joey Hess]

Adam Di Carlo wrote:
> Hmmm...not a bad idea.  Would even work after release.  Bring it up on
> the debian-apt list.  We don't control that in boot-floppies.

Yeah, but it makes a lot more sense after release for most users to have
"stable" in there. Tracking potato will be a dead end when woody[1] comes
out after all, and we don't want to force everyone to go in and edit it by
hand.

-- 
see shy jo

[1] Or whatever we call it.

Re: Preparing the Release / Freezing potato

[Adam Di Carlo]

tony mancill <[EMAIL PROTECTED]> writes:

> I did a successful network-based new install on the 29th with the only
> real glitch being the fact that /etc/apt/sources.list points to stable,
> which is right now, not very useful.  What would be the possibility of
> changing the _distribution_ field from "stable" to "potato" until right
> before the release?

Hmmm...not a bad idea.  Would even work after release.  Bring it up on
the debian-apt list.  We don't control that in boot-floppies.

> BTW, kudos to the boot-floppies team for the good work.

Thanks for the kind words -- I'm pleased it worked for you.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Preparing the Release / Freezing potato

[Yann Dirson]

[Why -private ?]

Rob Browning writes:
 > >There *is* confusion wether to use /usr/share/man or /usr/man,
 > >/usr/share/info or /usr/info and /usr/share/doc or /usr/doc, also
 > >where, if and when to add softlinks somewhere.
 > 
 > Same here.  I have no idea what's been decided.

I was under the understanding that we should use /usr/share/man and
/usr/share/info at once, without symlinks, as all readers look in both
places; and that we should start moving does to /usr/share/, leaving
symlinks from /usr/doc to /use/share/doc for now.

Is there a misunderstanding on my part ?

-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
debian-email:   <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
| Cheaper, more Powerful, more Stable !
http://www.altern.org/ydirson/  | Check 

Re: Preparing the Release / Freezing potato

[tony mancill]

On Sat, 30 Oct 1999, Joey Hess wrote:

> Martin Schulze wrote:
> >  . Our boot-floppies are not ready yet.  Freezing the distribution
> >without working boot-floppies will extend the freeze time which
> >would be a very bad idea.  Adam di Carlo today told me that he
> >doesn't believe that our boot-floppies will be read before
> >January.  (Since I haven't been able to work on them I can't say
> >anything about that.)
> 
> We've already done successful (nfs!) installs with the potato boot floppies,
> though there are of course glitches.

I did a successful network-based new install on the 29th with the only
real glitch being the fact that /etc/apt/sources.list points to stable,
which is right now, not very useful.  What would be the possibility of
changing the _distribution_ field from "stable" to "potato" until right
before the release?

BTW, kudos to the boot-floppies team for the good work.

  [EMAIL PROTECTED] | Linux: because a PC is a terrible thing to waste
http://www.debian.org  |-- [EMAIL PROTECTED] put this on Tshirts in '93 

Re: Preparing the Release / Freezing potato

[Martin Schulze]

Massimo Dal Zotto wrote:
> > I see several problems with freezing potato in one week:
> ...
> > Therefore I propose to postpone the freeze (and the release) for at
> > least two months, hoping to get the FHS issue, Incoming and
> > boot-floppies resolved.
> > 
> > Thanks for your attention,
> > 
> > Joey
> 
> I agree with you.
> 
> Can we also require that all packages use debconf in their postinst scripts?

Not if you want to release potato before summer.

> This would be make debian ready for automatic installation, and probably the
> only distribution able to do that.

Debconf is not stable (in the meaning that it's still changing) and
there are a lot of bugreports covering problems in connection to
debconf.  Requiring to switch to it now, will make a potato release
impossible for a whole while.

> In two months we could easily made the transition to debconf, at least for
> the most common packages which are used in common installations.

No, we can't.  This would require 1/4th of all packages to be reworked
on, and recompiled for all arch's.

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.

Please always Cc to me when replying to me on the lists.

Re: Preparing the Release / Freezing potato

[Rob Browning]

Martin Schulze <[EMAIL PROTECTED]> writes:

>  . Our boot-floppies are not ready yet.  Freezing the distribution
>without working boot-floppies will extend the freeze time which
>would be a very bad idea.  Adam di Carlo today told me that he
>doesn't believe that our boot-floppies will be read before
>January.  (Since I haven't been able to work on them I can't say
>anything about that.)

To me it makes no sense to bother freezing until we have working
boot-floppies.  If we don't, then the freeze should wait.

>  . I still haven't seen an announcement what to do with the FHS
>transition and which policy versions should be used for potato
>packages.  Additionaly when I have asked other developers they
>could only shrug their head.
> 
>There *is* confusion wether to use /usr/share/man or /usr/man,
>/usr/share/info or /usr/info and /usr/share/doc or /usr/doc, also
>where, if and when to add softlinks somewhere.

Same here.  I have no idea what's been decided.

FWIW.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: Preparing the Release / Freezing potato

[Adam Di Carlo]

>Adam Di Carlo wrote:
>> Mssr Schultz misinterpreted my comments.  We *do* have working
>> boot-floppies now, although they are not yet feature complete.  There
>> are many critical features which aren't yet implemented (task
>> selection, automatic CD detection and apt's sources.list
>> configurator).

>Woah, this _is_ implemented.

Kinda sorta.  It's implemented using debconf, which isn't yet
base-ready, at least last you told me.  We need a system which uses
base only, or else we need to get base changed.

.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Preparing the Release / Freezing potato

[Joey Hess]

Adam Di Carlo wrote:
> Mssr Schultz misinterpreted my comments.  We *do* have working
> boot-floppies now, although they are not yet feature complete.  There
> are many critical features which aren't yet implemented (task
> selection, automatic CD detection and apt's sources.list
^^
> configurator).
  

Woah, this _is_ implemented.

> Well, I don't know what slushy freeze means.

We tend to have degrees of freeze -- we tend to start out with a freeze that 
isn't too solid.

-- 
see shy jo

Re: Preparing the Release / Freezing potato

[Adam Di Carlo]

Joey Hess <[EMAIL PROTECTED]> writes:

> Martin Schulze wrote:
> >  . Our boot-floppies are not ready yet.  Freezing the distribution
> >without working boot-floppies will extend the freeze time which
> >would be a very bad idea.  Adam di Carlo today told me that he
> >doesn't believe that our boot-floppies will be read before
> >January.  (Since I haven't been able to work on them I can't say
> >anything about that.)
> 
> We've already done successful (nfs!) installs with the potato boot floppies,
> though there are of course glitches.

Mssr Schultz misinterpreted my comments.  We *do* have working
boot-floppies now, although they are not yet feature complete.  There
are many critical features which aren't yet implemented (task
selection, automatic CD detection and apt's sources.list
configurator).  I think we can get a feature complete boot-floppies in
2-3 weeks.

> > Therefore I propose to postpone the freeze (and the release) for at
> > least two months, hoping to get the FHS issue, Incoming and
> > boot-floppies resolved.
> 
> I would much rather go to a slushy freeze now and make it a more solid
> freeze when some of these issues have had time to be worked on more.
> Delaying the freeze is just going to let other issues develop.

Well, I don't know what slushy freeze means.

The question is whether you want a short freeze or a long freeze.  If
you want a short freeze, then we're kinda getting into hot water with
the whole christmas/new years vacation coming up.  Furthermore, as
pointed out, there are a number of issues which would prevent a freeze
now from being very successful.

However, tactically, maybe Richard is threatening to freeze in a week
or so just to motivate people to work on RC bugs.

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Preparing the Release / Freezing potato

[Joey Hess]

Martin Schulze wrote:
>  . Our boot-floppies are not ready yet.  Freezing the distribution
>without working boot-floppies will extend the freeze time which
>would be a very bad idea.  Adam di Carlo today told me that he
>doesn't believe that our boot-floppies will be read before
>January.  (Since I haven't been able to work on them I can't say
>anything about that.)

We've already done successful (nfs!) installs with the potato boot floppies,
though there are of course glitches.

>  . I still haven't seen an announcement what to do with the FHS
>transition

This is going to be in the next version of policy, which Julian Gilbey is
working on now. It simply includes the Tech Ctte's decision.

> Therefore I propose to postpone the freeze (and the release) for at
> least two months, hoping to get the FHS issue, Incoming and
> boot-floppies resolved.

I would much rather go to a slushy freeze now and make it a more solid
freeze when some of these issues have had time to be worked on more.
Delaying the freeze is just going to let other issues develop.

-- 
see shy jo

Preparing the Release / Freezing potato

[Martin Schulze]

I see several problems with freezing potato in one week:

 . Our Incoming directory still contains 350MB of unprocessed (NEW or
   changed) packages.  They ought to go into potato.

   Adding them just a few days before potato is frozen would be stupid
   since they can't be tested well.

   Not adding them is also stupid since they were ment for potato and
   some of them probably contain useful additions for potato (like
   OpenSSH or the new GPL'ed CAD program), or splitted packages.

 . Our boot-floppies are not ready yet.  Freezing the distribution
   without working boot-floppies will extend the freeze time which
   would be a very bad idea.  Adam di Carlo today told me that he
   doesn't believe that our boot-floppies will be read before
   January.  (Since I haven't been able to work on them I can't say
   anything about that.)

 . When we freeze now, we will probably have to extend the freeze time
   for several weeks or months.  This will make potato quite out-dated
   at the time we may release it, just like it has happend with the
   slink freeze.  We should not make that same mistake again.

 . Freezing now and extending the freeze time may affect Debian being
   frozen during xmas where only few people can work on it.

 . I still haven't seen an announcement what to do with the FHS
   transition and which policy versions should be used for potato
   packages.  Additionaly when I have asked other developers they
   could only shrug their head.

   There *is* confusion wether to use /usr/share/man or /usr/man,
   /usr/share/info or /usr/info and /usr/share/doc or /usr/doc, also
   where, if and when to add softlinks somewhere.

Therefore I propose to postpone the freeze (and the release) for at
least two months, hoping to get the FHS issue, Incoming and
boot-floppies resolved.

Thanks for your attention,

Joey

-- 
Linux - the choice of a GNU generation.


pgp9uCJqZbhGj.pgp
Description: PGP signature