Difference between revisions of "ArchWiki talk:Reports"

From ArchWiki
Jump to: navigation, search
(Minimum supported kernel version: re)
Line 75: Line 75:
  
 
::::So true, I'll find a way to add this to the style guide. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:34, 25 June 2012 (UTC)
 
::::So true, I'll find a way to add this to the style guide. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:34, 25 June 2012 (UTC)
 +
 +
==GNOME: Hiding icons in the top bar==
 +
 +
This report on [[GNOME#Hiding_icons_in_the_top_bar]] requires some discussion with more GNOME/GNOME-shell-extensions knowledge. Removed it and started a thread on [[Talk:GNOME#Hiding_icons_in_the_top_bar|talk page]]. -[[User:Emiralle|Emiralle]] ([[User talk:Emiralle|talk]]) 23:58, 8 July 2012 (UTC)

Revision as of 23:58, 8 July 2012

In this page you can list:

  • Edits that a contributor made to the wiki without a proper explanation (that is what the Summary field is for) and whose validity you lack the knowledge to judge by yourself. In this case, please add a link to the edit in question with a brief explanation why you think it should be investigated. Consider contacting the contributor to ask for an explanation, which is often an effective way to solve these issues. Please report the eventual answer (if any) below the initial report. You can also link to a discussion already started in the talk page of the edited article.
  • Links to discussions started in talk pages requesting to add, delete, or modify some content in the respective articles which you do not have sufficient knowledge to answer definitively by yourself.

Please sign your edits and feel free to comment on others' reports. Discussions will be deleted 3 days after closing.

See ArchWiki:Spam to report vandalism.

IPv6

Can someone have a look at some changes starting here? -- Karol 07:56, 27 September 2011 (EDT)

New templates

Just a heads-up, if you're OK with them [1] [2] , please close the report :-) -- Karol 07:42, 14 December 2011 (EST)

If we start applying them consistently in all the tables, probably adding a proper rule in Help:Style, then I'm ok with them, since coloring cells in tables is not very straightforward even with wiki syntax.
Note their Chinese counterparts have been created too: Template:是 and Template:否. Since those templates' code is very flexible, I suggest replacing them with only 2 templates, Template:Y and Template:N, which would produce "Yes" and "No" by default, but whose first optional argument would allow them to display any other string, including translations, without the need to have localized versions of each template.
Going even a bit further, since some tables use additional colors, we may base the templates' names on their color instead of their meaning, so that we would have Template:G, Template:R, Template:Y, Template:B, and if necessary also Template:P and Template:O (purple and orange, just to complete the secondary colors). These templates should require the first argument, but I think they would be easy to use anyway, for sure much easier than the current | style="color:...." | blabla.
Waiting for opinions. -- Kynikos 09:19, 15 December 2011 (EST)
This template group would also give us an excuse to delete The Status Table Series and related templates, since they have a too narrow field of application and practically just create nested tables in the end, thus giving almost no real advantage. -- Kynikos 13:13, 24 December 2011 (EST)
I support this idea. Similar to the Template:Box COLOUR templates, a series of table cell coloured templates would ensure consistency across articles. -- pointone 16:46, 19 January 2012 (EST)
So good :) However I don't consider this an urgent task, I'm linking this discussion from a new entry among my numerous template ideas in my todo list. Of course if you or someone else want to implement it, just go for it. Just reminding that the implementation should be accompanied by some related style rules.
Also note that among my template-related ideas there's one about the Box COLOR series that seems to go in the opposite direction than the cell color templates, but I think that the colors for the Note, Warning and Tip templates should be reserved for them, and not be usable in other ways.
-- Kynikos 06:47, 20 January 2012 (EST)

System recovery category

This edit adds some information to a category page, and it definitely doesn't belong there. I'm not sure what to do about it though. thestinger 17:06, 6 January 2012 (EST)

I decided to move the information to General Troubleshooting but it needs some work. thestinger 17:11, 6 January 2012 (EST)
Not a bad idea moving it there indeed. What about merging General Troubleshooting and Step By Step Debugging Guide now? And leave the merged article in Category:System administration only? -- Kynikos 07:29, 7 January 2012 (EST)
I'm not sure if we should merge them. I think adding a merge tag to the articles (we should really have the "merge to" and "merge from" templates like Wikipedia) and getting some more input would be the way to go. thestinger 13:08, 8 January 2012 (EST)
Ok, we can wait for more opinions :) Also this very report can be enough at the moment. I'm adding the Merge to/from idea to my todo list among the many others, of course if you want to implement it just go for it. -- Kynikos 09:02, 9 January 2012 (EST)
I vote for merging both into a Troubleshooting or Debugging article. -- pointone 09:55, 4 April 2012 (EDT)
My preferences: General Troubleshooting > Troubleshooting > Debugging > Step By Step Debugging Guide.
(BTW, for casual readers, the merge to/from idea was discarded in another discussion).
-- Kynikos 08:30, 5 April 2012 (EDT)
Related forum thread. -- Kynikos 11:59, 7 April 2012 (EDT)

Pacman Rosetta

[3] No idea what eix -i does, but pacman -Qs doesn't search inside packages. Asked for clarification on authors' talk page. -- Karol 07:57, 26 January 2012 (EST)

Probably should read "within [the subset of] [locally] installed packages." I think this page could use some clean-up -- the section headings within the chart are not visible enough. Commands could be better organized. -- pointone 13:21, 28 January 2012 (EST)

Java SE 6

A new page was created with instructions on Java 6, but it could be a lot simpler due to the existence of jre6AUR and jre6-compatAUR (is jre7-compatAUR needed too?). thestinger 00:43, 11 April 2012 (EDT)

The author should probably be contacted, it's his first contribution, maybe he's just inexperienced? Alternatively he may have indeed some reasons not to use the AUR packages?
In any case he edited also Java, so if we delete/modify the page we should take those modifications into account.
-- Kynikos 08:06, 11 April 2012 (EDT)

btrfs stable?

Some days ago User:Graysky edited btrfs as it had been declared stable: whole history, in particular [4] and [5]; see also [6] and Talk:Btrfs#Troubleshooting is now outdated. Then, User:MajorTom has disputed those changes with [7], and I somewhat agree, as I've not been able to find any official statement about btrfs being declared stable. I'm contacting Graysky. -- Kynikos 17:22, 14 April 2012 (EDT)

Guys-I based my statement on the fact the oracle released this in ol6 and back ported it to ol5. Couple that with some emails from Avi miller and there you have it. Graysky 17:52, 14 April 2012 (EDT)
I know that btrfs' wiki isn't really up to date, but we're clearly colliding with [8], so I think, in order not to confuse Linux users (as our wiki usually ranks quite high in many google searches), you should undo MajorTom's edit and add some reference links to support the points in Btrfs#Recent Developments as he requested; can you do it? Thanks ^^ -- Kynikos 18:45, 14 April 2012 (EDT)

Jumbo frames' "Real World Examples" section

Jumbo_Frames#Real_World_Examples <-- This section doesn't seem fitting on our wiki. This section just seems to be an advertisement for jumbo frames, and I think it should be removed. And I should also note that the methodology is a bit unreliable, in my opinion. To truly test just the difference that jumbo frames makes, one should make a RAM disk so hard disk performance is completely removed from the equation. And if we really want to sell people on switching to jumbo frames, I would rather we simply provide a one-liner plus a link to a technical white paper, IEEE conference paper, etc. Does anyone else agree? -- Jstjohn (talk) 21:59, 4 June 2012 (UTC)

Well, I don't know if we can really consider that section as an advertisement, however it's true that benchmarking sections are not really Arch-specific, and would probably better fit a blog or some other kind of website, which could be linked from the article. A similar article is SSD Benchmarking, for example.
On the other hand it looks like an original work and I would hesitate a bit before simply deleting it, maybe moving the "Using Jumbo Frames on Arch Linux" section more to the top could be a start. User:Graysky seems to have added that section in 2009, he may be interested in discussing also about the reliability of the methodology, but I would do that in Talk:Jumbo Frames (possibly adding e.g. Template:Accuracy to the article), since this talk page is more used for discussing recent changes reports :)
-- Kynikos (talk) 15:26, 5 June 2012 (UTC)
Another alternative would be moving it to a sub-page, and having a link to it somewhere in the article. thestinger (talk) 15:14, 7 June 2012 (UTC)

Minimum supported kernel version

I've decided to report this edit here without adding a simple quick report first because I think this is quite urgent: what's the minimum kernel version we're supporting in the wiki? While it's true that linux is now at 3.4.3, linux-lts is for example still at 3.0.35, so I think in these cases we should use flexible wordings and examples so as to cover all the supported possibilities.

What do you think? -- Kynikos (talk) 10:58, 21 June 2012 (UTC)

sorry, I didn't really think about LTS, so I agree that this edit can be undone (edit: also this doesn't really match with the rest of section which still talks about loading this module manually. Not sure what I was thinking there ;) ). On this particular page, the note I added earlier should do it for now, although a more flexible wording might indeed be better. 65kid (talk) 13:14, 21 June 2012 (UTC)
Um, I've tried to improve the situation a little bit, however my intention was also to discuss in general if we should define a minimum supported kernel version for wiki articles (this discussion should probably be moved to Help talk:Style now). I think that linux-lts's version could be a good reference point, do we have other opinions? -- Kynikos (talk) 10:24, 23 June 2012 (UTC)
We should take the kernel version of official iso image into consideration. User should upgrade to latest version immediately. But before that, users have to config network. For some wireless cards, it is very kernel version specific. -- Fengchao (talk) 14:01, 24 June 2012 (UTC)
So true, I'll find a way to add this to the style guide. -- Kynikos (talk) 09:34, 25 June 2012 (UTC)

GNOME: Hiding icons in the top bar

This report on GNOME#Hiding_icons_in_the_top_bar requires some discussion with more GNOME/GNOME-shell-extensions knowledge. Removed it and started a thread on talk page. -Emiralle (talk) 23:58, 8 July 2012 (UTC)