Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Dimitri John Ledkov]

On 20 April 2018 at 15:46, Marvin Renich  wrote:
> Package: base-files
> Version: 10.1
> Severity: wishlist
>
> * Stephan Seitz  [180420 07:38]:
>> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote:
>> > But being human I prefer names over numbers, even if it's just for
>> > aesthetic reason - "buster" is just more comfortable than "debian10".
>>
>> No, it’s not. I know that my systems are running Debian 8 or 9, but I always
>> have to think if stretch is 9 or was it jessie.
>>
>> I have to look up the name not the number.
>
> I have often wanted to have on my system a text file containing the
> correspondence between code name and release number.  I know this is one
> more thing for the base-files maintainer to do during an already busy
> period just before release, but if he is willing, it would be nice to
> have a file, suggested to be /usr/share/doc/base-files/debian_releases,
> that contains each code name with its Debian release number, as well as
> the code name for the current testing release.
>
> I know this info is in the Debian wiki, but having it in a local text
> file is more convenient.  I would also be okay if this were a text file
> in debian-history, but I find that solution less satisfactory than being
> in base-files which is essential/required.
>
> I would also like /etc/debian_version to contain both number and name,
> but I suspect there is some resistance to this on the grounds that
> scripts may be using $(cat /etc/debian_version) for comparisons.
> Perhaps /etc/debian_codename?  Since debian_version contains
> codename/sid for testing and unstable, debian_codename could just
> contain the codename.
>
> Santiago, if you are willing to do either or both of these, I would
> appreciate it, but I certainly understand if it is just one too many
> things to remember during release prep.  If you don't want
> debian_releases in base-files, I'll reassign this bug to debian-history.

Have you tried $ debian-distro-info at all?

There are multiple bindings to it. there is csv file at
/usr/share/distro-info/debian.csv

And one can call it in many helpful ways:

$ debian-distro-info --testing
buster

$ debian-distro-info --series buster -r
10

Fix released by distro-info package? It lets you query things about
all the releases. There is ubuntu-distro-info to check all the Awesome
Animals too

-- 
Regards,

Dimitri.

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Marvin Renich]

* Emilio Pozuelo Monfort  [180420 11:00]:
> On 20/04/18 16:46, Marvin Renich wrote:
> > I would also like /etc/debian_version to contain both number and name,
> > but I suspect there is some resistance to this on the grounds that
> > scripts may be using $(cat /etc/debian_version) for comparisons.
> > Perhaps /etc/debian_codename?  Since debian_version contains
> > codename/sid for testing and unstable, debian_codename could just
> > contain the codename.
> 
> You already have that information in /etc/os-release and the lsb_release 
> command.

Thanks much!  I completely missed that.

Closing the bug now.  Sorry for the noise.

...Marvin

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Chris Lamb]

Marvin,

> I have often wanted to have on my system a text file containing the
> correspondence between code name and release number.

This appears to be already in the archive in a number of places.

For example, in `debdate`, `debian-handbook` or even in the `debian-
timeline` package if you speak XML.. Naturally, these are not as
convienent as a simple text file, so I am simply pointing them out.

> I would also like /etc/debian_version to contain both number and name

[…]

To avoid conflation of topics, this sounds like this should be a
separate wishlist bug, at least in the first instance.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Emilio Pozuelo Monfort]

On 20/04/18 16:46, Marvin Renich wrote:
> I would also like /etc/debian_version to contain both number and name,
> but I suspect there is some resistance to this on the grounds that
> scripts may be using $(cat /etc/debian_version) for comparisons.
> Perhaps /etc/debian_codename?  Since debian_version contains
> codename/sid for testing and unstable, debian_codename could just
> contain the codename.

You already have that information in /etc/os-release and the lsb_release 
command.

Cheers,
Emilio

Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Marvin Renich]

Package: base-files
Version: 10.1
Severity: wishlist

* Stephan Seitz  [180420 07:38]:
> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote:
> > But being human I prefer names over numbers, even if it's just for
> > aesthetic reason - "buster" is just more comfortable than "debian10".
> 
> No, it’s not. I know that my systems are running Debian 8 or 9, but I always
> have to think if stretch is 9 or was it jessie.
> 
> I have to look up the name not the number.

I have often wanted to have on my system a text file containing the
correspondence between code name and release number.  I know this is one
more thing for the base-files maintainer to do during an already busy
period just before release, but if he is willing, it would be nice to
have a file, suggested to be /usr/share/doc/base-files/debian_releases,
that contains each code name with its Debian release number, as well as
the code name for the current testing release.

I know this info is in the Debian wiki, but having it in a local text
file is more convenient.  I would also be okay if this were a text file
in debian-history, but I find that solution less satisfactory than being
in base-files which is essential/required.

I would also like /etc/debian_version to contain both number and name,
but I suspect there is some resistance to this on the grounds that
scripts may be using $(cat /etc/debian_version) for comparisons.
Perhaps /etc/debian_codename?  Since debian_version contains
codename/sid for testing and unstable, debian_codename could just
contain the codename.

Santiago, if you are willing to do either or both of these, I would
appreciate it, but I certainly understand if it is just one too many
things to remember during release prep.  If you don't want
debian_releases in base-files, I'll reassign this bug to debian-history.

...Marvin

Re: Bits from the release team: full steam ahead towards buster

[Stephan Seitz]

On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote:

But being human I prefer names over numbers, even if it's just for
aesthetic reason - "buster" is just more comfortable than "debian10".


No, it’s not. I know that my systems are running Debian 8 or 9, but 
I always have to think if stretch is 9 or was it jessie.


I have to look up the name not the number.

Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bits from the release team: full steam ahead towards buster

[Philipp Kern]

On 2018-04-19 23:00, Christoph Biedl wrote:

Philipp Kern wrote...

Turns out that this is a terrible idea.

Because?


People will start to rely on names for sorting again. Regardless if it's 
the right thing technically people are people and will use what tools 
they have available.



We should use numeric values for
sorting. (And Ubuntu now does the same thing on the technical side.)


From a technical point of view there is no need for codenames at all.
But being human I prefer names over numbers, even if it's just for
aesthetic reason - "buster" is just more comfortable than "debian10".
However, above all is the rule "do not confuse". Starting two
consecutive releases with the same letter does. Adding a third one 
makes

it worse.


I'm fine with that.

Kind regards
Philipp Kern

Re: Bits from the release team: full steam ahead towards buster

[Russ Allbery]

Russ Allbery  writes:
> Adam Borowski  writes:

>> Thus, there are locales where a purely ASCII word sorts differently
>> when capitalized and when not.

> Yes, including en_US.

Just to head off the noise of the corrections for this error, this last
should have said "yes, including C."

-- 
Russ Allbery (r...@debian.org)   

Re: Bits from the release team: full steam ahead towards buster

[Russ Allbery]

Adam Borowski  writes:
> On Wed, Apr 18, 2018 at 10:19:46AM -0700, Russ Allbery wrote:

>> That said, nearly all US English writers will just omit the accents
>> anyway.  At least US English (I can't speak for UK) really aggressively
>> drops accent marks.

> About dropping accents: do you know what can upcase('i') and
> lowercase('I') be?  Even this is not invariant.

Yes?  Not sure that's super-relevant here, but that's a rather notorious
edge case in the Turkish locale.

> Thus, there are locales where a purely ASCII word sorts differently when
> capitalized and when not.

Yes, including en_US.

-- 
Russ Allbery (r...@debian.org)   

Collation discrepencies between locales [was: Re: Bits from the release team: full steam ahead towards buster]

[Clément Hermann]

On 19/04/2018 22:45, Holger Levsen wrote:
> I now wondered if it's not only en_GB.utf8 which is "different", but also
> the NZ and US variants sort like that (and so differently than C)... not 
> sure if en_FR.utf8 exist, but using it, it sorts differently / like C ;)
> 
> (probably because it doesnt exist, thus the default, C, is used.)

Indeed, it doesn't exist. At least , for fr_* locale, it seems to be
consistent both in the different charsets available (e.g. fr_FR and
fr_FR.UTF-8) and country (fr_BE, fr_CA, fr_CH, fr_FR and fr_LU).

Actually I thought the localization had been made consistently with the
apparition of unicode locales, that is, fr_* locale would all give the
same result regardless of the charset (but older fr_FR for instance
might give a different order than before the apparition of the unicode
variant). I may be wrong - one would probably have to check the code in
GNU libc to be sure.

However, Note that the generation of locale matters: at first I thought
fr_FR and fr_BE where behaving differently, but after uncommenting all
fr_* locales in /etc/locale.gen, everything became consistent.


Cheers,

-- 
nodens

Re: Bits from the release team: full steam ahead towards buster

[Christoph Biedl]

Philipp Kern wrote...

> Turns out that this is a terrible idea.

Because?

> We should use numeric values for
> sorting. (And Ubuntu now does the same thing on the technical side.)

From a technical point of view there is no need for codenames at all.
But being human I prefer names over numbers, even if it's just for
aesthetic reason - "buster" is just more comfortable than "debian10".
However, above all is the rule "do not confuse". Starting two
consecutive releases with the same letter does. Adding a third one makes
it worse.

Christoph



signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Holger Levsen]

On Thu, Apr 19, 2018 at 09:35:25AM +1200, Ben Caradoc-Davies wrote:
> In the C locale, all uppercase letters are sorted before all lowercase
> letters:
> 
> $ echo -e "buster\nStretch" | LC_COLLATE=C sort
> Stretch
> buster
> 
> In en_GB, by comparison:
> 
> $ echo -e "buster\nStretch" | LC_COLLATE=en_GB.utf8 sort
> buster
> Stretch

wow, madness. thanks.

(maybe just mild madness... :)

> -- 
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand

I now wondered if it's not only en_GB.utf8 which is "different", but also
the NZ and US variants sort like that (and so differently than C)... not 
sure if en_FR.utf8 exist, but using it, it sorts differently / like C ;)

(probably because it doesnt exist, thus the default, C, is used.)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Adam Borowski]

On Wed, Apr 18, 2018 at 10:19:46AM -0700, Russ Allbery wrote:
> That said, nearly all US English writers will just omit the accents
> anyway.  At least US English (I can't speak for UK) really aggressively
> drops accent marks.

About dropping accents: do you know what can upcase('i') and lowercase('I')
be?  Even this is not invariant.

Thus, there are locales where a purely ASCII word sorts differently when
capitalized and when not.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄

Re: Bits from the release team: full steam ahead towards buster

[Stephan Seitz]

On Mi, Apr 18, 2018 at 08:52:25 +0300, Adrian Bunk wrote:

On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote:

specifically, what locale sorts english words differently than LANG=C?

Estonian (et_EE) sorts z between s and t.


Boah, thanks for all the examples. I didn’t know you could sort so 
differently.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bits from the release team: full steam ahead towards buster

[Ben Caradoc-Davies]

On 19/04/18 03:11, Stephan Seitz wrote:
Can you please give an example for the sorting difference in different 
locales if you only have english words (and I would say it means only 
ASCII in this case)?


In the C locale, all uppercase letters are sorted before all lowercase 
letters:


$ echo -e "buster\nStretch" | LC_COLLATE=C sort
Stretch
buster

In en_GB, by comparison:

$ echo -e "buster\nStretch" | LC_COLLATE=en_GB.utf8 sort
buster
Stretch

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Bits from the release team: full steam ahead towards buster

[Chris Lamb]

Hi Gunnar,

> > Can you please give an example for the sorting difference in different
> > locales if you only have english words (and I would say it means only ASCII
> > in this case)?
[…]
> But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
> school, "ch" and "ll" were treated as single letters (sorted
> respectively between "c" and "d", and between "l" and "m".

What happens if a letter is not really defined in that alphabet?

For example, the Croatian alphabet has no "Q" (whilst it's locale
probably does, otherwise madness..).


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Bits from the release team: full steam ahead towards buster

[Miroslav Kure]

On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote:
> On Wed, Apr 18, 2018 at 02:47:11PM +, Holger Levsen wrote:
> >
> >yes, sorting depends on the locale... :)
> 
> specifically, what locale sorts english words differently than LANG=C?

Czech (cs_CZ) for one.

% cat animals
cheetah
dino
horse
jackal

% LC_COLLATE=cs_CZ sort animals
dino
horse
cheetah
jackal

"ch" belongs between "h" and "i".

-- 
Miroslav Kure

Re: Bits from the release team: full steam ahead towards buster

[Adrian Bunk]

On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote:
> On Wed, Apr 18, 2018 at 02:47:11PM +, Holger Levsen wrote:
> > On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:
> > > On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote:
> > > > Please define "sorted order", not everybody order letters the same way.
> > > really? there's more than one alphabetical order for english words?
> > 
> > yes, sorting depends on the locale... :)
> 
> specifically, what locale sorts english words differently than LANG=C?

Estonian (et_EE) sorts z between s and t.

> Mike Stone

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bits from the release team: full steam ahead towards buster

[Russ Allbery]

Matthew Crews  writes:

> As far as diacritics go, American English is practically devoid of
> them. Where they are present, native (American) English speakers
> basically ignore them, so the words résumé (n) and resume (v) share the
> same spot in any given English dictionary. Other symbols like Æ and ß
> will be changed to ae and ss, and the like, and then sorted accordingly.

The above is the answer to the question "where does English sort
differently than LC_ALL=C."  The sorting behavior for résumé will vary
between the C locale and a proper en_US (or, I believe, en_GB) locale.

That said, nearly all US English writers will just omit the accents
anyway.  At least US English (I can't speak for UK) really aggressively
drops accent marks.  They normally don't survive more than a few years
into adoption of a word into the general vocabulary.  I almost never see
someone write résumé instead of resume in regular US business contexts.
(Some of this is because US keyboards are generally not set up to make
handling the accents easy, and most US typists have never learned how to
create those characters quickly, so it's a lot easier to just leave them
off.)

-- 
Russ Allbery (r...@debian.org)   

Re: Bits from the release team: full steam ahead towards buster

[Michael Stone]

On Wed, Apr 18, 2018 at 11:19:05AM -0500, Gunnar Wolf wrote:

Stephan Seitz dijo [Wed, Apr 18, 2018 at 05:11:47PM +0200]:

On Mi, Apr 18, 2018 at 02:47:11 +, Holger Levsen wrote:
> On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:
> > really? there's more than one alphabetical order for english words?
> yes, sorting depends on the locale... :)

Can you please give an example for the sorting difference in different
locales if you only have english words (and I would say it means only ASCII
in this case)?

I know that there are differences if you have words containing non-ASCII
characters like ü.


But why would ü not be part of the sorting? Yes, that was my example
before you censored my thought process - In Spanish, [áéíóú] and
[aeiou] share the same spot while ordering, as do ñ and n, as do u and
ü (and we have no further diacriticals). I understand that German
sorts äöü at the end.

But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
school, "ch" and "ll" were treated as single letters (sorted
respectively between "c" and "d", and between "l" and "m". So,
thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
and lobster < llama < manatee.


So, in the context of naming releases that are ordered by the first 
letter of the name, this seems to be a complete non-issue? We can safely 
assume that initial letters a

Re: Bits from the release team: full steam ahead towards buster

[Gunnar Wolf]

Matthew Crews dijo [Wed, Apr 18, 2018 at 01:10:06PM -0400]:
> On April 18, 2018 9:19 AM, Gunnar Wolf  wrote:
> > But why would ü not be part of the sorting? Yes, that was my example
> > before you censored my thought process - In Spanish, [áéíóú] and
> > [aeiou] share the same spot while ordering, as do ñ and n, as do u and
> > ü (and we have no further diacriticals). I understand that German
> > sorts äöü at the end.
> > 
> > But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
> > school, "ch" and "ll" were treated as single letters (sorted
> > respectively between "c" and "d", and between "l" and "m". So,
> > thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
> > and lobster < llama < manatee.
> 
> Not speaking as a programmer, but as a native American English
> speaker...
> 
> Your example is incorrect sorting behavior in English. Although
> Spanish might sort their words that way, English does not have
> double-character letters; ch and ll are treated as c then h, and l
> then l, for purposes of sorting. Therefore in English, it is correct
> that we sort cheetah < cow < dinosaur, and llama < lobster <
> manatee.
> (...)

Right - I was giving an example where a Latin-alphabet-using language
might sort differently than the C locale.

FWIW I *believe* we don't do that anymore in Spanish. But old
dictionaries did have this behavior. So, point in case – If you want
to sort, use numbers.

Re: Bits from the release team: full steam ahead towards buster

[Matthew Crews]

On April 18, 2018 9:19 AM, Gunnar Wolf  wrote:
> But why would ü not be part of the sorting? Yes, that was my example
> before you censored my thought process - In Spanish, [áéíóú] and
> [aeiou] share the same spot while ordering, as do ñ and n, as do u and
> ü (and we have no further diacriticals). I understand that German
> sorts äöü at the end.
> 
> But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
> school, "ch" and "ll" were treated as single letters (sorted
> respectively between "c" and "d", and between "l" and "m". So,
> thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
> and lobster < llama < manatee.

Not speaking as a programmer, but as a native American English speaker...

Your example is incorrect sorting behavior in English. Although Spanish might 
sort their words that way, English does not have double-character letters; ch 
and ll are treated as c then h, and l then l, for purposes of sorting. 
Therefore in English, it is correct that we sort cheetah < cow < dinosaur, and 
llama < lobster < manatee.

As far as diacritics go, American English is practically devoid of them. Where 
they are present, native (American) English speakers basically ignore them, so 
the words résumé (n) and resume (v) share the same spot in any given English 
dictionary. Other symbols like Æ and ß will be changed to ae and ss, and the 
like, and then sorted accordingly.

So if you are sorting words with an American English locale, and it diverges 
from this behavior, it is wrong.

Re: Bits from the release team: full steam ahead towards buster

[Gunnar Wolf]

Stephan Seitz dijo [Wed, Apr 18, 2018 at 05:11:47PM +0200]:
> On Mi, Apr 18, 2018 at 02:47:11 +, Holger Levsen wrote:
> > On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:
> > > really? there's more than one alphabetical order for english words?
> > yes, sorting depends on the locale... :)
> 
> Can you please give an example for the sorting difference in different
> locales if you only have english words (and I would say it means only ASCII
> in this case)?
> 
> I know that there are differences if you have words containing non-ASCII
> characters like ü.

But why would ü not be part of the sorting? Yes, that was my example
before you censored my thought process - In Spanish, [áéíóú] and
[aeiou] share the same spot while ordering, as do ñ and n, as do u and
ü (and we have no further diacriticals). I understand that German
sorts äöü at the end.

But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
school, "ch" and "ll" were treated as single letters (sorted
respectively between "c" and "d", and between "l" and "m". So,
thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
and lobster < llama < manatee.

Re: Bits from the release team: full steam ahead towards buster

[Stephan Seitz]

On Mi, Apr 18, 2018 at 11:14:50 -0400, Michael Stone wrote:

specifically, what locale sorts english words differently than LANG=C?


Since English words (or texts) can have 8bit characters you may get 
a different sorting in in different locales.


If you mean ASCII words I don’t know of any sorting difference.

Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bits from the release team: full steam ahead towards buster

[Stephan Seitz]

On Mi, Apr 18, 2018 at 02:47:11 +, Holger Levsen wrote:

On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:

really? there's more than one alphabetical order for english words?

yes, sorting depends on the locale... :)


Can you please give an example for the sorting difference in different 
locales if you only have english words (and I would say it means only 
ASCII in this case)?


I know that there are differences if you have words containing non-ASCII 
characters like ü.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bits from the release team: full steam ahead towards buster

[Michael Stone]

On Wed, Apr 18, 2018 at 02:47:11PM +, Holger Levsen wrote:

On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:

On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote:
> Please define "sorted order", not everybody order letters the same way.
really? there's more than one alphabetical order for english words?


yes, sorting depends on the locale... :)


specifically, what locale sorts english words differently than LANG=C?

Mike Stone

Re: Bits from the release team: full steam ahead towards buster

[Holger Levsen]

On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:
> On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote:
> > Please define "sorted order", not everybody order letters the same way.
> really? there's more than one alphabetical order for english words?

yes, sorting depends on the locale... :)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Michael Stone]

On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote:

Please define "sorted order", not everybody order letters the same way.


really? there's more than one alphabetical order for english words?

Mike Stone

Re: Bits from the release team: full steam ahead towards buster

[Aurelien Jarno]

On 2018-04-17 22:34, Christoph Biedl wrote:
> Also, choosing the names in sorted order (modulo wraparound) would
> create a list in historic order of the releases, easing some assessment
> when talking about releases. That's what Ubuntu does, although using

Please define "sorted order", not everybody order letters the same way.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Emilio Pozuelo Monfort]

Hi,

When all people can complain about are the codenames, it means we are doing
things fairly well :)

On 18/04/18 08:20, Lars Wirzenius wrote:
> On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote:
>> No, users and, I suspect, a large part of admins and developers cannot
>> easily say which of two codenames is newer, and it doesn't matter what are
>> those two codenames. Numeric versions are usually used to help with this,
>> but not so much in Debian.
> 
> I've been developing a habit of writing both number and codename:
> Debian 9 (stretch) and Debian 42 (billgates).
> 
> I think it would be a good habit for others as well, especially in
> public-facing communication.

That's a very good point, particularly for announcements. I'll try to keep it in
mind.

Cheers,
Emilio

Re: Bits from the release team: full steam ahead towards buster

[Andrey Rahmatullin]

On Wed, Apr 18, 2018 at 09:20:11AM +0300, Lars Wirzenius wrote:
> > No, users and, I suspect, a large part of admins and developers cannot
> > easily say which of two codenames is newer, and it doesn't matter what are
> > those two codenames. Numeric versions are usually used to help with this,
> > but not so much in Debian.
> I've been developing a habit of writing both number and codename:
> Debian 9 (stretch) and Debian 42 (billgates).
Unfortunately there is also a lot of tools where this would be helpful.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Lars Wirzenius]

On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote:
> No, users and, I suspect, a large part of admins and developers cannot
> easily say which of two codenames is newer, and it doesn't matter what are
> those two codenames. Numeric versions are usually used to help with this,
> but not so much in Debian.

I've been developing a habit of writing both number and codename:
Debian 9 (stretch) and Debian 42 (billgates).

I think it would be a good habit for others as well, especially in
public-facing communication.

signature.asc
Description: This is a digitally signed message part

Re: Bits from the release team: full steam ahead towards buster

[Andrey Rahmatullin]

On Tue, Apr 17, 2018 at 10:34:22PM +0200, Christoph Biedl wrote:
> There are people who don't follow every single action in Debian, plain
> stables users for example. For them it's helpful to tell the releases
> apart easily as they might not have the precise names and their order in
> mind. The first letter is a fairly simple way to aid this.
No, users and, I suspect, a large part of admins and developers cannot
easily say which of two codenames is newer, and it doesn't matter what are
those two codenames. Numeric versions are usually used to help with this,
but not so much in Debian.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Philipp Kern]

On 17.04.2018 22:34, Christoph Biedl wrote:
> Also, choosing the names in sorted order (modulo wraparound) would
> create a list in historic order of the releases, easing some assessment
> when talking about releases. That's what Ubuntu does, although using
> consecutive letters is nice but not necessary in my opintion. And yes,
> sid is a problem then. It would hit us in around the year 2055. I expect
> to be stable by then. Stable six feet under.

Turns out that this is a terrible idea. We should use numeric values for
sorting. (And Ubuntu now does the same thing on the technical side.)

Kind regards
Philipp Kern

Re: Bits from the release team: full steam ahead towards buster

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> We are about halfway through the buster development cycle, and a release
> update was overdue.

Thanks for all the updates, let's make this an exiting ride.


But briefly bleating by boldly bringing balking bits ...

> Future codenames
> 

So we'll see three consecutives releases starting with the letter "b":
buster, bullseye, bookworm - quite funny and I reckon it's no
coincidence. However, it's bad idea.

There are people who don't follow every single action in Debian, plain
stables users for example. For them it's helpful to tell the releases
apart easily as they might not have the precise names and their order in
mind. The first letter is a fairly simple way to aid this.

Also, people who do any kind of work related to releases would likely
use the names as an identifier, directory and screen session names in my
case. Different starting letters speed up tab completion and similar
matching procedures. Just another letter to type (or even two for buster
vs. bullseye) might sound like nothing, but in the long run it shows.
I might switch to the release numbers then which gives a sad feeling of
loosing some color in the work.


Probably it's too late to revert the decision. But for future codenames
I'm asking you to choose names in a way these aspects are considered as
well - and I regret I never sent this mail right after the buster and
bullseye name announcement as I wanted to.

So, please use names that are really easy to tell apart. Having unique
initial letters among all supported release is an essential part of
it. Taking also the symlinks into account was worth a consideration
although this would block any name starting with "e", "o", "s", "t", or
"u".

Also, choosing the names in sorted order (modulo wraparound) would
create a list in historic order of the releases, easing some assessment
when talking about releases. That's what Ubuntu does, although using
consecutive letters is nice but not necessary in my opintion. And yes,
sid is a problem then. It would hit us in around the year 2055. I expect
to be stable by then. Stable six feet under.

Christoph


signature.asc
Description: PGP signature