Jump to content

Talk:Debian

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Mthinkcpp (talk | contribs) at 17:10, 7 October 2014 (→‎YYYY-MM-DD benefits). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Good articleDebian has been listed as one of the Engineering and technology good articles under the good article criteria. If you can improve it further, please do so. If it no longer meets these criteria, you can reassess it.
Did You Know Article milestones
DateProcessResult
July 3, 2004Featured article candidateNot promoted
June 6, 2008Peer reviewReviewed
December 4, 2008Good article nomineeNot listed
June 24, 2014Good article nomineeListed
Did You Know A fact from this article appeared on Wikipedia's Main Page in the "Did you know?" column on June 28, 2014.
The text of the entry was: Did you know ... that the name of the Debian operating system is a combination of the first names of its creator Ian Murdock and his then-girlfriend Debra?
Current status: Good article

FA preparation

Since the DYK process is over, let us continue. There is no A-class in this article's WikiProjects, so the next goal is the FA-class. These are the criteria.

Compliance

Feel free to overwrite this status to reflect the discussion.

    1. well-written:
    2. comprehensive:
    3. well-researched:
    4. neutral:
    5. stable:
    1. a lead:
    2. appropriate structure:
    3. consistent citations:
  1. Media:
  2. Length:

Discussion

Regarding "well-written", this should be left to a professional writer when all the other criteria have been dealt with.

About "comprehensive", I really feel that major facts are missing: e.g. Debian Women. Although modern literature like "The Debian Administrator's Handbook" barely mentions Debian Women (Krafft wrote more in 2005), it is an important part of Debian. Besides the diversity statement, female ratio, financial support, etc, incidents like this one eventually happen. I will not go further with this issue, but someone else should give the "comprehensive" OK.

Concerning "well-researched", I will check once more that claims are verifiable. There are some sentences that do not sound neutral; verification will help with this.

The article looks stable, with a good lead, appropriate structure, consistent citations and enough media. Citations could be improved a bit more.

I am not sure whether the article stays focused. I will leave this assessment to another editor. 84.127.80.114 (talk) 23:03, 30 June 2014 (UTC)[reply]

To the best of my knowledge, the "well-researched" criterion is met. The article was fairly neutral already and the information is presented without bias; the "neutral" criterion is met too. Although other featured articles have shorter tables of contents, I do not find this one overwhelming.

The next goal should be "length". The article is more focused but another opinion is needed. I will wait one week before doing a first pass for this criterion and then ask for a review, unless another editor wants to take over. 84.127.80.114 (talk) 00:43, 6 August 2014 (UTC)[reply]

A little help opening the peer review would be appreciated ("Engineering and technology" link at the top of the page). 84.127.80.114 (talk) 22:07, 25 August 2014 (UTC)[reply]

Because of events that have led to this edit, I will refrain from working in this article for one week, unless the Peer review or the FAC process (which I cannot initiate either) start. I hope that the article gets improved in the meantime. 84.127.80.114 (talk) 22:54, 29 September 2014 (UTC)[reply]

Featured article tools

It be helpful to run the Featured article tools. Lentower (talk) 03:02, 1 July 2014 (UTC)[reply]

Expected information

This section is meant to receive feedback from Wikipedia users that have been selected randomly. The purpose is to make the article useful to different types of readers. Of course, users are not expected to read the whole article. The question is: what else do you want to know about Debian?

Multimedia support

I would like to turn "Third-party repositories" into a "Multimedia support" section. Current paragraph is targeted at deb-multimedia.org. The Wheezy announcement and release notes mention the improved multimedia support. Debian asked Marillat to stop using the name "debian"[1] and the official blog announced the end of debian-multimedia.org.[2] This repository was interfering with official maintenance. As I see it, Debian has warned users more against deb-multimedia than against non-free software. I am not aware of any other unofficial repository in this situation.

The bit about libdvdcss would go in this section.

This is not the time for a dispute resolution. If anyone is against this change, please say so and I will desist. 84.127.80.114 (talk) 00:41, 10 July 2014 (UTC)[reply]

Release managers section

As noted, the release manager is an important role but there are more: e.g. the technical committee. The release management is carried by a team. Debian maintains a list of leaders and a list of releases, but does not seem to maintain a list of release managers.

I will drop the list and merge the section. 84.127.80.114 (talk) 09:22, 17 July 2014 (UTC)[reply]

Development flowchart

I ask an able editor to upload this SVG flowchart that will replace the one in "Development procedures".

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
	"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" width="170" height="400"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns="http://www.w3.org/2000/svg">
	<defs>
		<style type="text/css">
			text {
				font-family: sans-serif;
			}
		</style>
		<rect id="state" width="120" height="30"
			style="fill:#fff;stroke:#000"/>
		<rect id="distribution" width="120" height="30"
			style="fill:#333;stroke:#000"/>
		<g id="arrow">
			<path d="m 60,30 0,40" style="stroke:#000"/>
			<path d="m 60,70 -5,-10 10,0 z"/>
		</g>
	</defs>
	<rect width="170" height="400" style="fill:#fff"/>
	<g transform="translate(10,10)">
		<use xlink:href="#state"/>
		<text x="60" y="20" style="text-anchor:middle">upstream</text>
		<use xlink:href="#arrow"/>
		<text x="70" y="50">packaging</text>
	</g>
	<g transform="translate(10,80)">
		<use xlink:href="#state"/>
		<text x="60" y="20" style="text-anchor:middle">package</text>
		<use xlink:href="#arrow"/>
		<text x="70" y="50">upload</text>
	</g>
	<g transform="translate(10,150)">
		<use xlink:href="#state"/>
		<text x="60" y="20" style="text-anchor:middle">incoming</text>
		<use xlink:href="#arrow"/>
		<text x="70" y="50">checks</text>
	</g>
	<g transform="translate(10,220)">
		<use xlink:href="#distribution"/>
		<text x="60" y="20"
			style="text-anchor:middle;fill:#fff">unstable</text>
		<use xlink:href="#arrow"/>
		<text x="70" y="50">migration</text>
	</g>
	<g transform="translate(10,290)">
		<use xlink:href="#distribution"/>
		<text x="60" y="20"
			style="text-anchor:middle;fill:#fff">testing</text>
		<use xlink:href="#arrow"/>
		<text x="70" y="50">freeze</text>
	</g>
	<g transform="translate(10,360)">
		<use xlink:href="#distribution"/>
		<text x="60" y="20"
			style="text-anchor:middle;fill:#fff">stable</text>
	</g>
</svg>

84.127.80.114 (talk) 19:40, 22 July 2014 (UTC)[reply]

Internal communications

debian-private is a major fact. Krafft wrote about it ("Other uses include the discussion of problems related to individuals, or financial and organisational issues"); I wonder about the justification "I am mentioning it here for completeness". Coleman wrote about too ("some of the more interesting discussions unfold there [...] I have been told about many such conversations").

debian-private is used in the retirement process.[3] I already talked about expulsion or equivalent, and list bans. It is natural that people start to ask questions. Why a General Resolution for such a harmless list? Why some developers deny the importance of these channels that are used for more than announcing vacations? Debian has no intention of declassifying.[4]

When I read about lack of volunteers and problems processing a mailing list, I remember the different spam clean teams. Are the issues technical? Giacomo A. Catenazzi admits that they do not want to show all world "about personal issues we have with other people".

Developers say that issues relevant to the user base are not discussed in debian-private. The problem is that the private discussions are not mere rants, they translate into people getting out of the project. An important part of Debian is the people behind Debian. When human resources are discarded, the project has a problem.

Why cannot we use this kind of material? Zacchiroli mentioned TINC in his platform, why cannot we say "cabal"? It is a recurrent topic with a mix of joke and fear. I find the anecdote about Raul Miller's existence an interesting one.

"Sometimes the divisiveness spills out into the larger Debian community in unpleasant ways."[5] Indeed, the departure of Matthew Garrett in 2006 was noted.[6] According to Bruce Byfield, Garrett claimed that decisions were made in "poorly advertised (or even secret) IRC channels used by smaller groups [...] to get work done"; as I read it, somewhere more private than debian-private. Frustration existed and Benjamin Mako Hill summed up the attitude: "This is the Debian project. We run on fear. Grow a skin or get out."

Internal communications are important in Debian. This article cannot claim to be comprehensive without a single reference to debian-private. That is my opinion. 84.127.80.114 (talk) 04:48, 5 August 2014 (UTC)[reply]

The SL saga (take two)

On the grounds that consensus can change, I would like to explain the following. In 2009, Wikipedia Signpost published a review of a book that examines how authority works on Wikipedia. This book is of interest to this article:

O'Neil, Mathieu (2009). "7. The Imperfect Committee: debian.org". Cyberchiefs: Autonomy and Authority in Online Tribes. Pluto Press. ISBN 978-0-7453-2796-9.

The chapter starts with an event related to Debian Women's origin. Later, O'Neil mentions the encyclopedic nature of Debian, as well as perfectionist: "Debian is the Mary Poppins of operating systems". He talks about the SL case, SL being the author of this message.

Sven Luther was the reason for a topic in the 2006 election. According to Anthony Towns, Luther's conflict surely escalated: "Sven's conflict with Frans, the d-i team and others is probably the most extreme example of a problem we've had to resolve."[7]

I still believe that one of "the most extreme" social problems Debian had to deal with is a major fact. 84.127.80.114 (talk) 06:14, 14 August 2014 (UTC)[reply]

Debian 0.91 screenshot

Besides the Wheezy screenshot in the infobox, the History section features captures for Etch and Squeeze. I think that a screenshot of Debian 0.91 would greatly enhance the article.

The distribution is about 35 MiB. It can be installed on a virtual machine. The hard disk should not be bigger than 512 MiB. After the installation, the console should look like this:


                        *** Debian Linux 0.90 BETA ***

Copyright (C) 1994 Ian A. Murdock <imurdock@shell.portal.com> under the terms
of the GNU Public License.  Please refer to the GNU Public License for details.

debra.example.org login: _

This is a screenshot of the graphical environment in PNG format, base64 encoding:

Inline image (data URL)
data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgBAMAAADH/8HXAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAL
EwAACxMBAJqcGAAAAAd0SU1FB94IDhAMFwcPgrYAAAAeUExURQAAAEBo4EhASF9fX29vb5CAkL+/
v8+3z9jY2P///3YvduwAAAABYktHRAnx2aXsAAAMlUlEQVR42u3dT2vjPh7HccFUA7ntwj6CH/MA
BgKF3vqDsLQ3Hdb3QmFgrstCn0AO01sgodTPdi3LSeR/siSrSWu9rZ22GX7MMp+RXv5almUhVjTa
FZsQOxrtik0wCmkYSMNAGg0DaRhIo2EgDQNpNAykYSCN9rkN/LbO9fiZZuzvy/bR/byc467z+Wca
A791/tj1UvPbdwLc/0wz9r+Vv1rHuvN5Mcfz3VvncyIDsw0wmYHZBpjKwF/PrZPTfqEn3ds7+9Pv
KsBkBj7nUbbYf83bMqWBz3fZlTEVXAkNbAWYRxmzLpMaaPOax0mkDjCdgXkGmNLAiwf4JD5BD0xo
YJ4BfmUDrxTgb3M6+doGVtk9Vf/eVYL1r+/iqWrV94sEaH762gaeAqx+fddf6k9CXDzAL2tg1em+
P9Wd70mYAL/rL5cPMKmBtg4f3gWF6YZVhnro1gP4GgEmNdD+oz++C1rj+HoBpjXwggGeeuCVA0xr
4AUDbAw0kV0zwKQGmrme28ufRJZi4IXLmCdTxizIwAsH+OtcSC/EwDxmYz7QwDwCtKVnPjDr+cBP
MSONgRnPB149wLd0Bu7Xa/uW83MWN9af9WfWB36a9YF3ZW7HPun6wH2WAe5T1oHu/7fqn2e1uAA/
bG1MPgEmXRvTT2i1O/3mUgNMWAeWdkD1z7vdTv+0Wi04wJQGdgLcVW219ACTGriqutxKj1mx2tVf
m2EsBAZ6GVgFuKoG7a7pertjX1z0EE5r4K4euE2ApxPJontgWgMHA8TAAAPPAe4yGcJp60CdmTl9
7I4nEepAfwO71x5ZXIlwLfxVroUXORvzYc+JZBTgBxqYR4AXM3ChAWIgBmIgBmIgBmIgBmIgBmIg
BmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIg
BmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIg
BmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIg
BmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBmIgBi7cwM3EcY+BbgMf
O//x42vnMwa6DewEeOh+vsdAt4GP73/sY9v9fI+BbgMnA8TACQMnAsTAKQPf/4yfgl+rHoiBkwaO
B1hioI+Bm5eR438lBvoYOBrgjxIDvQx8KYYPHSAGehjoDBADPQx0BYiBHgY6AsRADLyQgcIcp+8Y
GGigaB8YGGqgkPqoolP6EBgYaqAOrul9OkgMDDaw7n7GQKsHYqC3gceBW7R7IAYGGChk9YMSGBhn
YDNy9VjGwKg6sO6CdY7UgTEGmpNHfTLBwAgDq9SaOlBniYHhBsp69OpxrDAwxkBZD189jBUGxlwL
mxOIOZFgYLCBpoSpCDSlDAaGGtgEZyqYJsB3DJw2cLNpDWFpD+HN5gEDPdYHjp5EWB/oYWBZHsbL
GNYHThtYlo5CmvWBAXXgyKUcBvrfExmcTMBA32vh4eksDPS+Fh6eUMVAfwOHp/Qx0NfAkZtKGOht
4OBtTQwMMXDgxjoGBq6NEayNia8DBxcXYSDrAy9jIOsDZxrIGumZBrJGGgOvaWAzA6gPiYERBio7
OAwMN7AOUM8GykKq+u4IBgYZqANU1dfqi2x+xMBQA+sAdU9UxTlADPQ1UJkQqyFcHG8MY2CYgape
oGACpA6cYaAqCgwMNnD0LIyBXAtzLcy1MPOBGIiBH2jgf/8aPv6DgX4GjuT3Fwb6GujauQgDPQx0
7FyEgdSB1IHUgdSBGIiBlzJQCYmBcwy0bhBjYIyBSp67IAZGGKiEEhg4pw4U5y6IgTF1oNUFMTCq
Djx3QQwMNPC4wPzYBTEwzMDzYyJNF8TAMAPNEyLnx0QwMMxAJc/HedcODPQ20OqAdg/EQO99YwQG
zjHQesyrdRbGQP/nhSV14AwDj7l1r0Qw0P95Ycm18BwDTzsmCOYDZxjIfOBMA3sz0hgYZiD3RObV
gZL7wrEGqtOT/twXjr8WlpndF9Z/p2TzgarZLSartTE++YXMB8rc1sbsEs4HFipDA3cJDTRbCGa2
NsY/QNYHzguQ9YEXMDDH9YFpDcxwfSAGYiAGYqAJUBa9vXcyMND7Us5jPlBfDedmoP9kgsd8YB2g
MNueWEs7mA/0NFBWwZmNO44bFzEfGGbgSIDcE/E0UCplklOq4L1yEQa2AuSeSISBp7ErCwyMqgOP
p19pvxYNA7kWvpCBPC/MtfB1DeR5YQy8moHOnYswcNpA185FGOhjoGvnIgz0MNCxcxEGUgdSB1IH
UgdiIAZeykCJgbMMVAIDZxnYWmKJgcEG2k/KYWCEgeen1TEwxsDzy60xMMpAcd6xAwMjDFTWu4Ux
MMJA/cSr7DyxjoH+BupTsPkfBkYZWPW9+k31rV07MDDkWbljkxgYY2DV9+onNgX7xsQZqN/LpwFU
rQDbBu7XtxkGWP2tPa+F288MDxi4Xq8zDFD/rVNdC5dljkO4LD2vhfs9sGtguc8ywL3nfOBAD6QO
DJkPnDSQOpD5wA+dD5w2kDoQAzEQAzEQA0cNFBg4y8DeEMbAMANlgYGzDCyODxpiYJSBrA+caSDr
A2cayPrAmQayRhoDMfCrGtjczFQYGGmgbGWHgcEG1ltNCP1FFrxTKcJAedxzR9bfMTDOwDo9O0AM
DNk3RglZD2Hheq/cOr/D28B6CNffxw38Zf/brBfb69rjLKWBv60/922xAbbXX7x57Z1Vn4VV7yzc
NbB1rDufF3M83721P6e7Fs41wGTXwrkGmOhaeN8+PT3vF3revb3rfk40H7jO9UhkIG3QQOfORWNj
n3Y20LVz0SMZDbSuga6dixiv7ja1cxEGehjoXwfSZtaBtJl1II06EAMx8PO2m43Pce9aH9hf3pbT
yDx0plXN58fO794710gXImMDbzpRbeoUOwEe7mc8J7LwdlP+aR0b/XlbRWQfHdWmFpnnZaBXgE4D
+4855GWgV4AuA/tDOC8D/2xbJ9xD9evh0f6d17pPjRvY74GZGbjtly32bz2UUwaqzA3cPjrLmEOJ
gW4DWwH2y5hNiYETBtqnjP5JZFNi4ISBvQBvugFioNvAyQAx0G3gdIAYGGSgDvDVnIIxMNbAV3MN
MmHg4OZjGNgLcNTA4e3vMLAX4Oj+gYMbMGZooC3eUICj+wcObQGao4F2XCEGDm5Cm6OBEwGO14GD
2yBnaOBUgKN14OBG3BkaaOavHoINHNwKnjrQ38DBlxFQBwYYOPg6jOzrwK2/gVwLjwVoq+i8Fu6/
EggDtyHzgf2XUmHgNmQ+cOC1aBgYMh+Y+fpAjx74PmFg3usDbw6bjX0bfdu7sb7Vn1kf+HHrAzNf
I32oV/+dgvrn8fjH6ad/TawPzN7A8nAv/t084joS4Mj6QIWBpg6cCnCsDlQYaOrA6QCHDVSmipb1
xhOiUCrXOtAjwEEDldk6RjZf6tsiWdaBHgGOGmjteqIwMMLAY4D6/iYGRhioA6wOfT2sCgyMMvDY
VIGBgQbWCzuOe5AVGBhqINfCMw3kWvhkoPtamPnASQNPR5CBzAeeDJwKEAMnDHQdN4MGOncuys3A
vwf63ZSBrp2LsjPQI8C+ga6dizK7J/IwEeBh8J6IY+ei7O6JTATIPZGpeyJTQ5h7IhP3RCYDPFAH
OuvA6ZMIdaCzDvQ4C7sMVL3VWdSBQdfC/VdDUgcGXQtPvFsTAyefFy46S3wxMMhAvY++xMB4A4Us
Oqv0MTDEQD2Ci8yfE5meznI9JyKVkkpiYKyB+kkl0XnUCwP9DdQj2D4PY2CggXp1luwGSB3oXwdW
yZk9EzAwzkC9MEHv2iEwMMpA3fPqU4iQGBhjoM6t7oHHMYyBYQaKoumBhcDACAPr6MzORc0YxsAg
A+vUTA+0X8yHgb4Gmre7ym6AGOhpoAmtuZATEgNDDTRzCM3ubUpiYKiBzTvqTXSmH7KPdP9wrJE+
1zLHOLPcS7/3MoLO2xxGnxMRrVvCpwBzM/DVyup94G0O7z0DN5vty7n0U6fvOsDD5iE3A4P30tfj
+sUawcoawz/0UqTMDPQJsG1g1UetAE97qNYB6qVIuRkY/D6RisqX8wTMqQfq7z80AFkZeOi8hqD/
Nofq82AdeAxQnX/IsQ7023RiqA4UorMySwjeKzfe+nXgwC1Q3ivn1ZoAVS8/ybs1xxtrpNM11kjH
tP8D4OJUXhYi2mkAAAAASUVORK5CYII=

I hope that this thumbnail helps:

84.127.80.114 (talk) 20:00, 15 August 2014 (UTC)[reply]

Official architecture ports

A port is official only if it is officially supported, i.e., it is part of stable. "Official Debian port" in the Debian Wiki is not a reliable statement. 84.127.80.114 (talk) 16:57, 16 August 2014 (UTC)[reply]

Uhm, arm64 has been moved from buildd.debian-ports.org to buildd.debian.org. It's not just an entry in the wiki, we are actually building official arm64 packages now and we are planning to include arm64 in Jessie. I don't see how this could be more official. — Preceding unsigned comment added by 92.206.40.85 (talk) 22:05, 16 August 2014 (UTC)[reply]

I repeat, it is official if it is part of stable: security support, official disc images, etc. ia64 and s390 are official, arm64 is not. The only ways to be official before the Jessie release are to provide those elements as Wheezy 7.6, Wheezy-And-A-Half or to be part of Wheezy backports. Theoretically, Debian could release a new architecture for stable, although I am not aware that such a thing has ever happened. I would expect this kind of event to be announced at least by the release team. In any case, a port is official when it actually is official, not because it will be or is called "official". 84.127.80.114 (talk) 07:24, 17 August 2014 (UTC)[reply]
Well, it's going to be a port for Jessie when it pops up on the main buildds now so I don't understand why not adding it right away. But if you insist waiting until Jessie has been released, then well, go ahead. I still think the article should contain the information that arm64 is actually now being built as part of the official buildd servers. — Preceding unsigned comment added by 92.206.51.66 (talk) 13:07, 17 August 2014 (UTC)[reply]
Nevertheless, the information has encyclopedic value.[8] 84.127.80.114 (talk) 18:57, 17 August 2014 (UTC)[reply]

Steam (2)

This was the previous discussion.

The edit about SteamOS is breaking the focus among other problems. On the other hand, Valve is tempting Debian developers and the temptation seems to work. Could the editors add an appropriate sentence with a citation in the "Derivatives" section? 84.127.80.114 (talk) 08:19, 17 August 2014 (UTC)[reply]

Table usability

I have reverted this recent edit to Debian. "People have small screens" does not seem a valid reason because "Release date" is longer than those dates. Furthermore, the timeline image below has a width of 860 pixels, wider than the table. Could Derianus provide more details about the display device on the article's talk page? 84.127.80.114 (talk) 06:50, 20 September 2014 (UTC)[reply]

@"People have small screens" does not seem a valid reason because "Release date" is longer than those dates. - But "Release date" has a space in the middle which enables display software to insert a new line. The old format is more concise. The table has seven columns, so it takes up a lot of space already.

Wikipedia:Manual of Style/Dates and numbers#Dates and years allows this format for tables. The object containing the dates in question is a table. Derianus (talk) 09:56, 20 September 2014 (UTC)[reply]

I advise Derianus to familiarize with the WP:BOLD, revert, discuss cycle and leave the status quo up, i.e., revert to the previous version. I would also recommend WP:Edit warring, given the activity in Regions of Ukraine.
Derianus is not addressing my concerns. Is the editor actually seeing the alleged problem? "Release date" is inside <span class="nowrap">. Inserting a new line means ignoring the CSS and that would mean ignoring <span style="white-space:nowrap;"> for the dates too.
The editor may have noticed the "Supported until" column. There are dates which cannot follow the yyyy-mm-dd format. What is Derianus' suggestion to solve the format inconsistency in the table?
(By the way, using the "Engineering and technology" link at the top of this page would really improve this article.) 84.127.80.114 (talk) 01:39, 21 September 2014 (UTC)[reply]
Why handing out advises to others that you don't follow yourself? I simply reverted to the ISO 8601 format. Derianus (talk) 04:10, 23 September 2014 (UTC)[reply]
Derianus is refusing to address my concerns. There is consensus for the mdy format: the bold edit using words was not disputed or reverted by subsequent edits; I revised that edit later in the good article review without dispute, reaching a new consensus; I have revised the date format specifically.
There is no evidence of consensus change. The other editors are not participating or reverting, but given that they are not answering my calls to improve this article either, I do not find silence to be a valid reason. They are busy and maybe they trust the current effort, which Derianus is invited to join in.
I repeat, what is Derianus' suggestion to solve the format inconsistency in the table? 84.127.80.114 (talk) 00:22, 24 September 2014 (UTC)[reply]
"I do not find silence to be a valid reason" - you take silence as you like. E.g. when it was changed in the direction you prefer you take it as evidence for new consensus. Now, you do exactly the opposite. Derianus (talk) 20:21, 26 September 2014 (UTC)[reply]
Well, at least I am disputing Derianus' edit; silence is definitely not a valid reason now. I do not remember using only silence to support the word-based date format, which is also supported by consensus through editing.
I would like to note that Derianus' arguments are focused on my reasoning consistency exclusively. I do not mind being in question, but some words concerning the table would be appreciated. 84.127.80.114 (talk) 23:26, 26 September 2014 (UTC)[reply]
"I do not remember using only silence" - did anyone claim that? "I would like to note that Derianus' arguments are focused on my reasoning consistency exclusively." - That is blatant misrepresentation of facts. Derianus (talk) 21:06, 28 September 2014 (UTC)[reply]
WP:SILENCE does not apply to this as an editor has opposed both sets of changes - a new consensus is only reached when a new undisputed version of the article is created.
Table: It is inconsistent to have one style of date in one column and one in another. If there is a policy regarding the use of one particular format in a column, then IMO both should use that format otherwise it would be based on preference. MOS:DATEFORMAT shows both are acceptable in tables. It is a stylistic issue rather than a major problem and I would select the template, dts, abbreviated date - testing on a 5" screen shows that neither format results in more columns/text being displayed. To get more displayed the nowrap on "Release date" would need to be removed - then the new format would be better justified.
mthinkcpp (talk) 12:55, 28 September 2014 (UTC)[reply]
"It is inconsistent to have one style of date in one column and one in another." - Maybe you can play the magician and add exact dates to the table where they are missing? As long as you cannot, the inconsistency cannot be removed without replacing exact days with month values in the other column. Derianus (talk) 21:06, 28 September 2014 (UTC)[reply]
Since Derianus cannot solve the inconsistency without discarding information, the user should revert to the mdy format until the missing exact dates are provided. The mdy and month-year formats are both word-based. 84.127.80.114 (talk) 21:39, 28 September 2014 (UTC)[reply]
LOL. The other format had the inconsistency too. Are you trolling? Derianus (talk) 21:45, 28 September 2014 (UTC)[reply]

yyyy-mm-dd limitation

I still believe Dsimic made a sensible decision. I have tried alternatives to express dates with month accuracy (c. 2000-10-01; 2000-10-??; 2000-10-00; 2000-10-); there is not a clean option. yyyy-mm is a valid ISO 8601 format, but is unacceptable as per WP:BADDATEFORMAT guideline. Word-based formats should be used.

However, this is exactly the same problem I am facing with citations in another article:

Reference date accessdate
1. Ghost in the Shell Preview September 1997
2. Ghost in the Shell 1997-12-10 2013-09-03

Access dates are exact, but source dates may be reduced to month accuracy.

No citation in the Debian article has month accuracy. If a new source about Debian appears with this accuracy, should the month information be discarded because of a style issue? Should all the other dates be converted to mdy? This consistency problem is not covered by the manual of style. A decision should be made:

  1. Ignore the style inconsistency (current state).
  2. Stick to ISO 8601 and ignore the manual of style.

I am fine with either. 84.127.80.114 (talk) 03:02, 29 September 2014 (UTC)[reply]

Hey everyone! FWIW, I prefer MDY dates in articles, and in text in general – in such "environments" MDY dates just look better and more readable to me. On the other hand, YYYY-MM-DD format is much more usable when it's about easier sorting etc., but that usually doesn't apply to articles. Also, the argument of small screens simply doesn't make sense to me, as there's little chance that a few characters more would cause readability issues. Just my $0.02. :) — Dsimic (talk | contribs) 04:08, 29 September 2014 (UTC)[reply]
Sorting isn't an issue as the dts template resolves it, showing the word format, but still sorting correctly (according to its page). mthinkcpp (talk) 17:04, 29 September 2014 (UTC)[reply]
Exactly, {{dts}} template covers that; I was referring to sorting dates in general, aside from the usage in Wiki markup language. Sorry I wasn't clear enough. — Dsimic (talk | contribs) 19:56, 29 September 2014 (UTC)[reply]
And that is why in table ISO 8601 is seen more often than in text. And the Debian article breaks easy copy-paste between other sources and the data in table. I thought Wikipedia and Debian have to do with sharing? Not their metadata? Derianus (talk) 22:38, 29 September 2014 (UTC)[reply]
Why would MDY break anything? Anyone can simply go to the page source and use ISO dates present there, if the goal is to fetch the dates formatted that way. — Dsimic (talk | contribs) 22:50, 29 September 2014 (UTC)[reply]
My position, keep all the information, but use MDY. It is reasonably clear when the day/month has been omitted. Also it is more consistent to use MDY and just omit parts than to use both YYYY-MM-DD and MDY. mthinkcpp (talk) 17:09, 29 September 2014 (UTC)[reply]

YYYY-MM-DD benefits

  • better for small screens
  • the only option for cross article consistency
  • easier sharing of data between different Wikipedia langauge editions, since ISO 8601 is an international standard
  • sortable without any extra templates or hidden javascript logic - WYSIWYG
  • easier sharing of data between table data in Wikipedia and tabular data from other sources — Preceding unsigned comment added by Derianus (talkcontribs) 22:43, 29 September 2014 (UTC)[reply]

The small screen argument has been given as one benefit. It was countered by:

  • "Also, the argument of small screens simply doesn't make sense to me"

Maybe that user never had looked at tables with several columns having a date format longer than ISO 8601 YYYY-MM-DD.

It is simple physics, more characters need more space on the screen and less need less. Derianus (talk) 22:29, 29 September 2014 (UTC)[reply]

Yeah, I've looked at Wikipedia articles on small screens. Though, if you want to deal with more complicated matter, you simply need a bigger screen, right? There's no point in trying to fit a pumpkin into something that was made for an apple, so to speak. — Dsimic (talk | contribs) 22:53, 29 September 2014 (UTC)[reply]
I've looked at that particular table, both editions and (as I said before) neither show more information. mthinkcpp (talk) 18:29, 30 September 2014 (UTC)[reply]
Despite of this, basic laws of physics hold - a place occupied by one object cannot be occupied by another. Adjust the screen so, that the date cells are exactly filled by YYYY-MM-DD. Now try to fit MDY in the same cell, without altering any table boundary nor the size of font. Derianus (talk) 22:39, 6 October 2014 (UTC)[reply]
At the same time, basic principles of economics also apply – as a result, even cellphones will soon have 4K screens. I'm not saying that having 4K screens in phones makes sense, but as a result in 2014 it's simply absurd to trade a few pixels for style and readability. — Dsimic (talk | contribs) 02:29, 7 October 2014 (UTC)[reply]
"Cross-article consistency"- The Wikipedia Manual of Style points (mostly) to MDY. mthinkcpp (talk) 18:29, 30 September 2014 (UTC)[reply]
MOS allows DMY and MDY and it prohibits switching articles from one form to the other. Using ISO 8601 in tables therefore is the only way to achieve cross-article consistency for tables. Derianus (talk) 13:48, 2 October 2014 (UTC)[reply]
Not quite, it prohibits changing the date format without either consensus or an accepted reason mandating the change, i.e. They cannot be just changed to ISO..., MDY or DMY without consensus - although I think there is now consensus for changing to/using MDY. mthinkcpp (talk) 17:10, 7 October 2014 (UTC)[reply]

MDY limitations

While using ISO 8601 leads to cross article consistency for tables, and values can be copied between Wikipedias in different languages, MDY values cannot be copied nor will their usage in the Debian article lead to cross article consistency for tables.

Compare

Derianus (talk) 22:18, 29 September 2014 (UTC)[reply]

Dubious information in timeline

Some versions have a supported until date before release of the next version.

This applies only to values that are presented with month-precision. I fixed Potato. Hamm and Bo still have the dubious information.

Derianus (talk) 22:05, 28 September 2014 (UTC)[reply]

I removed

  • 2.0 "Feb 1999" and
  • 2.1 "Oct 2000 "

neither had a reference. Derianus (talk) 21:58, 29 September 2014 (UTC)[reply]