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

DEMOCRATICAL election of Codenames of Debian [Before "Re: And next name after Sarge? or PROPOSAL for Codenames' election"]



In 07 Jan 2004 17:09, I wrote the following in Usenet, and it seems that 
anyone answered essentially that
1) I have to send this to "aj", the release manager, and that
2) it is a example of overengineered suggestion.

Well, I have to say that it was a solution (perhaps overengineered) to achieve 
that the election of codenames of Debian were more democratically than now. 
I'm sad (and worry) that to no body likes this suggestion and overall the 
possibility that the choose of codenames were democratical.

But I'm not surrender (by now):

1) I think that the democratical election of codenames is essential and it 
should were part of the political of debian. "How much" democratic or in what 
way it's democratic are things that you (the organization and developers of 
Debian) could discuss. I only suggested a solution for doing it.

   Anyway, I think that the trasparency of "why" this or another codename is 
choosen is essential. If this transparency implies to admit that "the 
codenames are choosen randomilly/arbitrarily by release manager", I think 
that it we/you have to admit this.

   It could be the difference between Debian and other (comercial) distros 
that the decission are choosen uniterally (by the cupola).

2) Seeing http://www.debian.org/intro/organization.en.html, I supose that "aj" 
is Anthony Towns, but I don't know it. So I decide to CC this post to him for 
what will happen.

3) With high probability this post and mail will be ignored or will answered 
with irony (or worst: with false wish of collaboration), but I do it at least 
for point out it.

Regards to all,
Xan.



[We could rectrict the democratic election of codenames to Toy Story names, 
but I _personally_ think that it's not nice (because it depends of a 
comercial film) and that it's not general]
> 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=9
>ce021f0.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=9
>ce021f0.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=i
>ndex&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: