[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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 
Usenet groups</a> (<a 
3DN">several times</a>), in <a 
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 

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_ 
		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' 

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 
				   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 
					   If the second I prefer is B, then I assign a "2" to this codename. And 
					3) Internally, the number of puntuation "1" plus the number of puntuation
					   "2"... that one codename has got is traducted somehow as a 
				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 
				   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 

				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 
					  than other english localized names (as "Impulsive"). If we _only_ elect 
					  "most popular" codenames, then there are much more election of users 
					   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
							- 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 
					  codenames is finite, and the sense of this program is _more_ 
					  I hope this not happens)
				g) Perhaps, tehcnicaly the system needs that the codenames have occidental 
				  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 
				  For other hand, I think that good election is UTF-8 codification for 

			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

		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!.



- 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: