And next name after Sarge? or PROPOSAL for Codenames' election
Hello to everybody,
Recently, I'm worried about the election of codenames of Debian: 1) how they
are choosen and by who, and 2) what will happen when the Toy Story names
finish.
In the following, I relate you what I did and what I got, and a proposal for a
future codenames of Debian. I present it to you in item list mode for more
easy read. I wish that anyone heard me...
1) I asked what's the next name after Sarge (and in general how the names of
Debian are choosen) in many places: <a
href="http://groups.google.com/groups?hl=ca&lr=&ie=UTF-8&oe=UTF-8&threadm=9ce021f0.0309151451.601d9aa6%
40posting.google.com&rnum=13&prev=/groups%3Fq%3Dxan2%2540ono.com%26hl%3Dca%
26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd%26start%3D10%26sa%3DN">in
Usenet groups</a> (<a
href="http://groups.google.com/groups?hl=ca&lr=&ie=UTF-8&oe=UTF-8&threadm=9ce021f0.0309301055.2f92a703%
40posting.google.com&rnum=12&prev=/groups%3Fq%3Dxan2%2540ono.com%26hl%3Dca%
26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd%26start%3D10%26sa%
3DN">several times</a>), in <a
href="http://www.debianhelp.org/modules.php?op=modload&name=phpBB_14&file=index&action=viewtopic&topic=2765&5";>Debian
Help(.org)</a> and to my Linux friends, and all these tries were fruitless,
i.e. I did not get any reasonable answer.
2) So it's seems that no one knows what's the next codename after Sarge, and
next after next, and, in general, it seems that no one knows how the
codenames of Debian are elected.
3) I suspect that the election of the next codename is arbitrary and is made
by the cupola of Debian. [By "cupola of Debian" I want to say "The
organization/administration of Debian", that is the leader project and all
his team (tecnic comitee and secretary...). See
http://www.debian.org/intro/organization]
4) Having the consideration of the spirit of Debian and, in general, the open
spirit of Linux Community, I think that the codenames of Debian should be
elected in open way. That is, that anyone could see and follow any step of
the process of election of Debian codenames. Nowadays, the codenames are
given, but the process of why they elected this or another codename is not
open (in far as I know).
5) There are severals ways of doing this:
5.1) The election is made by the cupola
The cupola elects the codename of the next release of Debian in an _open_
way.
For example, it could be done with open and public votation of codenames by
any member of cupola.
The votes could be secrets, but the results should be open.
5.2) The election is made by the package developers+the cupola
The cupola plus all the package developers elect the codename of the next
release of Debian
in an open way.
The public votation is a nice way in this case too.
5.3) The election is made by the users of Debian.
All the users of Debian distribution elect the codenames.
5.4) the election is made by anyone who wants (being or not Debian user).
- In all the cases, the election results and all the election process should
be public in the way the it could be.
6) Personally, I vote for the penultimate option (that the Debian users elect
the codenames) + that anyone could propose (but not vote) new codenames'
names.
7) For do that, it's necessary that we have a debian package that:
- allows "to query the possible codenames"
(that is, that anyone could see the codenames that could be elected for
the next release of Debian)
- allows "to vote the codenames"
(that the people that we choose (5.1-5.4) could vote somehow the codenames
for the next release)
- allows "to propose one/several new codename"
(that anyone could propose new codenames)
8) How do this package should be?
I think that this has two differentiate parts:
8.1) A program itself.
8.2) A database.
- This two parts are independent: the database in which we have all the
possible codenames (and its current "preference" of election), and the
program that allows to "modify" this database.
8.1) I think that the best election is make two parts: a back-end and the
gui. The back-end is really what modify and query the database, and
communicate with the gui. The gui could be text-based or graphic. I think
that, for functionality of people, if text-based gui is made, I think that it
should be in ncurses, because it should contains more options.
The separation of back-end and gui implies more code lines, but it's more
functional: we could make more gui's independently.
8.1.1) The system of election of the codenames should be the most suitable
mathematically for assure:
a) Each person (of the group elected (5.1-5.4)) is equal to others.
It means that no one has more privileges than others and the elections
of
one person have the same weight as the elections of another.
b) Each person can choose several codenames.
That is, each person can choose one codename as its prefered codename,
one less
prefered codename, one less less prefered codename, .... [It's the same
that we
have to elect what do in vacations: I prefer to go to Madrid. Else, I
prefer to
go to Lisboa. Else, ....] [Personally, I do that in the following way:
1) Anyone could elect a number of codenames.
This number of possible codenames for elect depends of how many
codenames are in database. A good election is that anyone _could_
(not should) elect max{10% of total codenames, 10}.
2) If the desired codename for me is A, then I assign a "1" to this
codename.
If the second I prefer is B, then I assign a "2" to this codename. And
so
on.
3) Internally, the number of puntuation "1" plus the number of puntuation
"2"... that one codename has got is traducted somehow as a
puntuation.]
c) The system of election should be the most automatically as it could be.
This means
that no human intervention is desirable. For example, in case of draw
of two or more
codenames, the system should be capable of decide what is elected (even
randomilly).
The decission and the criterias of the system of election not could be
change: if
the system elects codename A, then no one could change this election
and choose B
as the codename of the next release. And if we choose the most popular
name, then
we could not change this criteria (else if there is consensus about
it).
d) The system should favor the variety:
- it's best with more proposed codename (much codenames is best than few)
- it should estimulate that it could elect codenames for the next release
which are not very elected by the users for their local character. Ex.:
the codename "Impulsiu" is local to catalan. So it were elected few
times
than other english localized names (as "Impulsive"). If we _only_ elect
the
"most popular" codenames, then there are much more election of users
that
were ignored. It's not worthy.
- For this reason, I suggest that:
- the system of election could be multivotal: anyone can elect
(with order) more than one codename that he/she prefer. I think
that it's recommended to study other alternatives
mathematically.
- periodically (for example after 5 releases), codenames were
elected randomilly.
- periodically, the codenames could be elected randomilly in
one category: non-US language, region, cientific topic, ...
For this, when anyone propose a new codename, he/she should
specify the data of this codename (is proper name?, to what
language it belongs, to what it's related, ...)
e) Perhaps, the system should favor the shortest codenames, because
(perhaps [I don't
know this]) the symbolic links to short names are more efficient.
f) Perhaps, technically the system could not allow some codenames as:
- codenames with spaces
- codenames with control characters
- codenames with more than x characters (if it happens, then the number
of
codenames is finite, and the sense of this program is _more_
discutible.
I hope this not happens)
g) Perhaps, tehcnicaly the system needs that the codenames have occidental
codification
translation: if we elect a chinese codename, perhaps it's not supported
for the
mirrors of debian. I beleive that we have to treat this point more
accutery.
For other hand, I think that good election is UTF-8 codification for
codenames.
8.1.2) The programs should allows:
- query the more/less popular codenames
- query the database randomilly
- show alphabeltically list of proposed codenames
- show historically (the time the codenames were proposed criteria) list
of proposed
codenames.
8.2) I think that the database should be accessible through the web site of
debian. So, for example,
in codenames.debian.org anyone could see this database.
9) What were the name of this project?. Is it another package for doing
this? ;-). I thinked in "NDeb" because "name" in the majorty of languages
begins with "N" and "Deb" with evident reasons. But we could change it!.
Regards,
Xan.
Bibliography
- http://www.debian.org/doc/FAQ/ch-ftparchives.en.html#s-codenames:
5.3 What are all those names like slink, potato, etc.?
They are just "codenames". When a Debian distribution is in the development
stage, it has no version number but a codename. The purpose of these
codenames is to make easier the mirroring of the Debian distributions (if a
real directory like unstable suddenly changed its name to stable, a lot of
stuff would have to be needlessly downloaded again).
Currently, stable is a symbolic link to woody (i.e. Debian GNU/Linux 3.0) and
testing is a symbolic link to sarge. This means that woody is the current
stable distribution and sarge is the current testing distribution.
unstable is a permanent symbolic link to sid, as sid is always the unstable
distribution (see What about "sid"?, Section 5.4).
5.3.1 Which other codenames have been used in the past?
Other codenames that have been already used are: buzz for release 1.1, rex for
release 1.2, bo for releases 1.3.x, hamm for release 2.0, slink for release
2.1 and potato for release 2.2.
5.3.2 Where do these codenames come from?
So far they have been characters taken from the movie "Toy Story" by Pixar.
* buzz (Buzz Lightyear) was the spaceman,
* rex was the tyrannosaurus,
* bo (Bo Peep) was the girl who took care of the sheep,
* hamm was the piggy bank,
* slink (Slinky Dog) was the toy dog,
* potato was, of course, Mr. Potato,
* woody was the cowboy.
* sarge was the sergeant of the Green Plastic Army Men
Reply to: