Re: experimental codename: scud?
On Wed, Dec 17, 2003 at 11:56:30AM +0100, Toens Bueker [EMAIL PROTECTED] wrote: Hamish Harvey [EMAIL PROTECTED] wrote: I'm not on the list, just follow DWN. Just a thought, but naming something after a missile seems odd. Question is, after what the missile was named ... If I remember right, Scud is the name of Sid's dog, also broke a lot of things... /GCS
Re: experimental codename: scud?
On Wed, 17 Dec 2003 22:56:21 +0100, GCS [EMAIL PROTECTED] wrote: On Wed, Dec 17, 2003 at 11:56:30AM +0100, Toens Bueker [EMAIL PROTECTED] wrote: Hamish Harvey [EMAIL PROTECTED] wrote: I'm not on the list, just follow DWN. Just a thought, but naming something after a missile seems odd. Question is, after what the missile was named ... If I remember right, Scud is the name of Sid's dog, also broke a lot of things... /GCS Why not name it after the little girl in finding nemo. -- Matthew A. Nicholson Matt-Land.com
Re: experimental codename: scud?
Hamish Harvey [EMAIL PROTECTED] wrote: I'm not on the list, just follow DWN. Just a thought, but naming something after a missile seems odd. Question is, after what the missile was named ... by Töns -- There is no safe distance.
Re: experimental codename: scud?
On Wed, 2003-12-17 at 11:56, Toens Bueker wrote: Hamish Harvey [EMAIL PROTECTED] wrote: I'm not on the list, just follow DWN. Just a thought, but naming something after a missile seems odd. Question is, after what the missile was named ... Extract from http://en.wikipedia.org/wiki/Scud: Scud is the NATO reporting name (not an acronym) for a Soviet army short-range liquid propellant surface-to-surface ballistic missile, the SS-1. [...] The name Scud is also used to refer to an Iraqi modification of the same missile. by Töns -- There is no safe distance. There is: more than 700kms for a Scud-D (aka: SS-1e) :-) -- Vincent RENARDIAS http://www.renardias.com/
Re: experimental codename: scud?
Vincent Renardias [EMAIL PROTECTED] wrote:
I'm not on the list, just follow DWN. Just a thought,
but naming something after a missile seems odd.
Question is, after what the missile was named ...
Extract from http://en.wikipedia.org/wiki/Scud:
Scud is the NATO reporting name (not an acronym) for a Soviet army
short-range liquid propellant surface-to-surface ballistic missile, the
SS-1.
[...]
The name Scud is also used to refer to an Iraqi modification of the
same missile.
[EMAIL PROTECTED]:~$ dict scud
4 definitions found
From Webster's Revised Unabridged Dictionary (1913) [web1913]:
Scud \Scud\, v. i. [imp. p. p. {Scudded}; p. pr. vb. n.
{Scudding}.] [Dan. skyde to shoot, shove, push, akin to skud
shot, gunshot, a shoot, young bough, and to E. shoot.
[root]159. See {Shoot}.]
1. To move swiftly; especially, to move as if driven forward
by something.
The first nautilus that scudded upon the glassy
surface of warm primeval oceans. --I. Taylor.
The wind was high; the vast white clouds scudded
over the blue heaven. --Beaconsfield.
2. (Naut.) To be driven swiftly, or to run, before a gale,
with little or no sail spread.
From Webster's Revised Unabridged Dictionary (1913) [web1913]:
Scud \Scud\, v. t.
To pass over quickly. [R.] --Shenstone.
From Webster's Revised Unabridged Dictionary (1913) [web1913]:
Scud \Scud\, n.
1. The act of scudding; a driving along; a rushing with
precipitation.
2. Loose, vapory clouds driven swiftly by the wind.
Borne on the scud of the sea. --Longfellow.
The scud was flying fast above us, throwing a veil
over the moon.--Sir S. Baker.
3. A slight, sudden shower. [Prov. Eng.] --Wright.
4. (Zo[o]l.) A small flight of larks, or other birds, less
than a flock. [Prov. Eng.]
5. (Zo[o]l.) Any swimming amphipod crustacean.
{Storm scud}. See the Note under {Cloud}.
From WordNet (r) 2.0 [wn]:
scud
n : the act of moving along swiftly (as before a gale) [syn:
{scudding}]
v 1: run or move very quickly or hastily; She dashed into the
yard [syn: {dart}, {dash}, {scoot}, {flash}, {shoot}]
2: run before a gale [syn: {rack}]
[also: {scudding}, {scudded}]
by
Töns
--
There is no safe distance.
Re: experimental codename
On Tue, Dec 16, 2003 at 01:03:57AM +0100, Arnaud Vandyck wrote: Graham Wilson [EMAIL PROTECTED] writes: On Mon, Dec 15, 2003 at 08:44:42PM +0100, Arnaud Vandyck wrote: it's a bit different and for different arches. What about the arches `all'? Well, I'm maybe a particular case: powerpc + java ;) but it could be the same with sparc + perl or else. Where can I have more information about experimental? Hmm... I am not quite sure I understand you. Can you explain more? I don't know how to write a sources.list line for architecture `all'. Just as for sid and sarge and potato, you do not need a special line for Arch: all packages; they are referenced from the Packages file for every architecture. Am I correct if I say that it will not take more place than now, but only the Packages and Sources files will change? Yes, only the Packages and Sources files will increase in size, but, as Henning says, even this is not a good idea. But indeed, the same affect can be accomplished by using APT's preferences file. Yes, it's me not able to deal with the experimental apt/sources.list configuration and not able to configure apt correctly. Is it only me or maybe a better documentation about it could be a good thing? No, I also feel that documentation about using is experimental is spread out and hard to come by. I think maybe many problems with using experimental as a playground for development packages could be remedied by creating a central document about it. Things to include might be: * sources.lists lines * using APT's preferences to pin packages from experimental * how to build packages in experimental for arches that are missing (since there are not buildds) * anything else? -- gram signature.asc Description: Digital signature
Re: experimental codename
Graham Wilson [EMAIL PROTECTED] wrote: [...] I think maybe many problems with using experimental as a playground for development packages could be remedied by creating a central document about it. Things to include might be: * sources.lists lines * using APT's preferences to pin packages from experimental * how to build packages in experimental for arches that are missing (since there are not buildds) * anything else? I think the respective section in Developer's Reference might be a good place for this and it already features the sources.list entry. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: experimental codename
On Mon, Dec 15, 2003 at 01:50:00AM +0100, Christoph Berg wrote: since we are discussing codenames for the Debian/*BSD OSs, I noticed that the experimental distribution doesn't have a codename yet, as unstable has with Sid. I think that's the way it should be. Experimental isn't a complete distribution in the sense that the others are, so it doesn't really deserve a codename. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: experimental codename
On Mon, Dec 15, 2003 at 02:46:27AM +0100, Rene Engelhard wrote: Christoph Berg wrote: since we are discussing codenames for the Debian/*BSD OSs, I noticed that the experimental distribution doesn't have a codename yet, as unstable has with Sid. I'd propose to call it Scud, which is the Name of Sid's dog (which broke toys even worse than Sid did ;-). I think that although Scud looks nice in this context giving a codename to experimental is not something we have to do since experimental is not a full distribution -- it only contains packages and makes only sense with a normal, codenamed distro (sid) installed I like it too :) Prehaps it could be used as a codename for the new unstable when Sarge is released as stable? Regards, Neil McGovern -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5
Re: experimental codename
Colin Watson [EMAIL PROTECTED] writes: On Mon, Dec 15, 2003 at 01:50:00AM +0100, Christoph Berg wrote: since we are discussing codenames for the Debian/*BSD OSs, I noticed that the experimental distribution doesn't have a codename yet, as unstable has with Sid. I think that's the way it should be. Experimental isn't a complete distribution in the sense that the others are, so it doesn't really deserve a codename. Isn't it possible that `scud' (I like it too) or `experimental' to be a complete distribution with exactly the same packages from unstable *but* the experimental packages? What I'm trying to explain is that I like the idea of an extra pool with the buildd and bts but no automatic move to another pool. I think, DD and people with chroot can point to this distribution to test things and it could be a buffer for the new packages. You know, upload a package and a library and have to wait because the library is not available and so on... We put every new packages in `Scud' and when accepted, after some test by others, we can safer move it to `Sid' with less delay. I don't know if I'm clear, I don't know if I'm right... but I think a (new) release organization is necessary... It's just a proposal ;) Cheers, -- .''`. : :' :rnaud `. `' `- pgpRSU7H40AWi.pgp Description: PGP signature
Re: experimental codename
On Mon, Dec 15, 2003 at 01:38:37PM +0100, Christoph Berg wrote: Re: Neil McGovern in [EMAIL PROTECTED] I like it too :) Thanks :) Prehaps it could be used as a codename for the new unstable when Sarge is released as stable? That's not the way it works; Sid is not Sarge+1 but the never-to-be- released development version. Think of it as version infinity. And Beyond! Sorry, it had to be said. I'll go back in my hole now. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpm6og0gfCWW.pgp Description: PGP signature
Re: experimental codename
Re: Neil McGovern in [EMAIL PROTECTED] I like it too :) Thanks :) Prehaps it could be used as a codename for the new unstable when Sarge is released as stable? That's not the way it works; Sid is not Sarge+1 but the never-to-be- released development version. Think of it as version infinity. Christoph -- Christoph Berg [EMAIL PROTECTED], http://www.df7cb.de/ Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 signature.asc Description: Digital signature
Re: experimental codename
On Mon, Dec 15, 2003 at 02:10:22PM +0100, Arnaud Vandyck wrote: Colin Watson [EMAIL PROTECTED] writes: I think that's the way it should be. Experimental isn't a complete distribution in the sense that the others are, so it doesn't really deserve a codename. Isn't it possible that `scud' (I like it too) or `experimental' to be a complete distribution with exactly the same packages from unstable *but* the experimental packages? What I'm trying to explain is that I like the idea of an extra pool with the buildd and bts but no automatic move to another pool. I think, DD and people with chroot can point to this distribution to test things and it could be a buffer for the new packages. If this would lead to more developers and beta-testers being able to use experimental, then I think this would be a good idea. People might upload there newer more in-development packages here first, instead of to unstable. Now that I think about it though, this is already possible. You can pin all of experimental just as high as unstable in the APT preferences file. I think the only difference now between your proposal and reality is support from the buildd's (I believe experimental has fairly good support in the BTS). We put every new packages in `Scud' and when accepted, after some test by others, we can safer move it to `Sid' with less delay. Every new package, or every new upload? The former might be alright, but the latter would make experimental to unstable what unstable is to testing. -- gram signature.asc Description: Digital signature
Re: experimental codename
John Hasler writes: gram writes: Every new package, or every new upload? Perhaps every upload to Unstable should go to Experimental as well unless Experimental already has a newer package (or the same one), but uploads to Experimental should go to Experimental only. Nothing would ever move from Experimental to any other distribution automatically. Why have this duplication? At least for my limited use of the experimental distribution, apt's normal preference behavior (prefer unstable over experimental, but don't downgrade an installed package) is useful and stays out of the way. At least to me, unstable means a set of generally useful packages and experimental means a set of less stable packages useful if you want to beta-test future releases. Michael Poole
Re: experimental codename
gram writes: Every new package, or every new upload? Perhaps every upload to Unstable should go to Experimental as well unless Experimental already has a newer package (or the same one), but uploads to Experimental should go to Experimental only. Nothing would ever move from Experimental to any other distribution automatically. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: experimental codename
Michael Poole [EMAIL PROTECTED] writes: John Hasler writes: gram writes: Every new package, or every new upload? Perhaps every upload to Unstable should go to Experimental as well unless Experimental already has a newer package (or the same one), but uploads to Experimental should go to Experimental only. Nothing would ever move from Experimental to any other distribution automatically. Why have this duplication? At least for my limited use of the experimental distribution, apt's normal preference behavior (prefer unstable over experimental, but don't downgrade an installed package) is useful and stays out of the way. At least to me, unstable means a set of generally useful packages and experimental means a set of less stable packages useful if you want to beta-test future releases. Correct. -- .''`. : :' :rnaud `. `' `-
Re: experimental codename
Graham Wilson [EMAIL PROTECTED] writes: On Mon, Dec 15, 2003 at 02:10:22PM +0100, Arnaud Vandyck wrote: [...] What I'm trying to explain is that I like the idea of an extra pool with the buildd and bts but no automatic move to another pool. I think, DD and people with chroot can point to this distribution to test things and it could be a buffer for the new packages. If this would lead to more developers and beta-testers being able to use experimental, then I think this would be a good idea. People might upload there newer more in-development packages here first, instead of to unstable. Now that I think about it though, this is already possible. You can pin all of experimental just as high as unstable in the APT preferences file. I think the only difference now between your proposal and reality is support from the buildd's (I believe experimental has fairly good support in the BTS). Also, it's not the same url in the sources.list s/unstable/experimental/ it's a bit different and for different arches. What about the arches `all'? Well, I'm maybe a particular case: powerpc + java ;) but it could be the same with sparc + perl or else. Where can I have more information about experimental? We put every new packages in `Scud' and when accepted, after some test by others, we can safer move it to `Sid' with less delay. Every new package, or every new upload? The former might be alright, but the latter would make experimental to unstable what unstable is to testing. The first. As I explain in the begining of my mail, I don't want to reproduce unstable - testing because of the non automatic move from `Scud' to `Sid'. The main point for me is the buildd and experimental to be a copy *plus* exception distribution (the plus exception are _the_ experimental packages). Hope to be clearer, Cheers, -- .''`. : :' :rnaud `. `' `- pgpdGKAOGmMo1.pgp Description: PGP signature
Re: experimental codename
On Mon, Dec 15, 2003 at 08:44:42PM +0100, Arnaud Vandyck wrote: Graham Wilson [EMAIL PROTECTED] writes: If this would lead to more developers and beta-testers being able to use experimental, then I think this would be a good idea. People might upload there newer more in-development packages here first, instead of to unstable. Now that I think about it though, this is already possible. You can pin all of experimental just as high as unstable in the APT preferences file. I think the only difference now between your proposal and reality is support from the buildd's (I believe experimental has fairly good support in the BTS). Also, it's not the same url in the sources.list s/unstable/experimental/ Yes, I forgot this. But the potential users of experimental (developers) will probably know how to handle there sources.list and preferences files. it's a bit different and for different arches. What about the arches `all'? Well, I'm maybe a particular case: powerpc + java ;) but it could be the same with sparc + perl or else. Where can I have more information about experimental? Hmm... I am not quite sure I understand you. Can you explain more? The main point for me is the buildd and experimental to be a copy *plus* exception distribution (the plus exception are _the_ experimental packages). Yes, I think the buildd situation wrt experimental is a hindrance to wider use of the experimental distribution. However, I am not (nor do I believe a majority might be) that experimental should duplicate unstable, with only a few packages (the experimental ones) being newer. However, with the pool structure archive, this might not actually mean a duplication of too much space. But indeed, the same affect can be accomplished by using APT's preferences file. -- gram signature.asc Description: Digital signature
Re: experimental codename
Graham Wilson [EMAIL PROTECTED] writes: On Mon, Dec 15, 2003 at 08:44:42PM +0100, Arnaud Vandyck wrote: [...] it's a bit different and for different arches. What about the arches `all'? Well, I'm maybe a particular case: powerpc + java ;) but it could be the same with sparc + perl or else. Where can I have more information about experimental? Hmm... I am not quite sure I understand you. Can you explain more? I don't know how to write a sources.list line for architecture `all'. If I want to upload a java package in experimental (Architecture: all) where and how do I do that? And if I want debian-java users to install experimental packages, how do they have to write their apt/sources.list line? That was the 'question'. The main point for me is the buildd and experimental to be a copy *plus* exception distribution (the plus exception are _the_ experimental packages). Yes, I think the buildd situation wrt experimental is a hindrance to wider use of the experimental distribution. However, I am not (nor do I believe a majority might be) that experimental should duplicate unstable, with only a few packages (the experimental ones) being newer. However, with the pool structure archive, this might not actually mean a duplication of too much space. Am I correct if I say that it will not take more place than now, but only the Packages and Sources files will change? But indeed, the same affect can be accomplished by using APT's preferences file. Yes, it's me not able to deal with the experimental apt/sources.list configuration and not able to configure apt correctly. Is it only me or maybe a better documentation about it could be a good thing? Cheers, -- .''`. : :' :rnaud `. `' `-
Re: experimental codename
Scripsit Graham Wilson [EMAIL PROTECTED] However, I am not (nor do I believe a majority might be) that experimental should duplicate unstable, with only a few packages (the experimental ones) being newer. However, with the pool structure archive, this might not actually mean a duplication of too much space. Well, experimental's Packages file itself would become as large as the one for unstable. Most people would still want to have unstable as well as experimental in their sources.list, because the ride might get too rough if you pulled _everything_ from experimental that there is to pull. For example, one might be willing to help stress-test the packaging of perl6, but not at the same time as stress-testing new glibc packages. At least on my system, synchronizing the Packages file on a daily basis accounts for a significant fraction of the total amortized bandwith I use for tracking unstable, simply because I have to download it in full every day. So inflating experimental/Packages to full distribution size would probably have a measurable effect on mirror load level. -- Henning Makholm I've been staying out of family conversations. Do I get credit for that?
Re: experimental codename
Hi, Christoph Berg wrote: since we are discussing codenames for the Debian/*BSD OSs, I noticed that the experimental distribution doesn't have a codename yet, as unstable has with Sid. I'd propose to call it Scud, which is the Name of Sid's dog (which broke toys even worse than Sid did ;-). I think that although Scud looks nice in this context giving a codename to experimental is not something we have to do since experimental is not a full distribution -- it only contains packages and makes only sense with a normal, codenamed distro (sid) installed Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
