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
