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

Re: HOWTO debug dracut

On 10/01/2009 10:26 PM, Adam Williamson wrote:
On Thu, 2009-10-01 at 22:09 +0000, "Jóhann B. Guðmundsson" wrote:

Please also see
https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the
permanent reference for this topic. I'll add anything in Harald's mail
that's not currently on that page to it. Thanks.

Is this the new format/path of debugging pages for a given component
how_to_debug_<component>_problem as opposed to
https://fedoraproject.org/wiki/Dracut/Debugging  or
<component>/Debugging>  and are we going to move all debugging pages
under how_to_debug??
It hasn't been officially discussed anywhere - I was using
Bug_info_componentname myself - but I think it's a good choice by
whoever came up with it. It also fits in with the request of the Wiki
admin team that we use flat page names, not nested ones.

Well I think the documentation team ( doc list cc-ed ) should provide us with rules and regulation ( or templates ) on how component page should be written including bug reporting etc.. and who the target audience is so at-least some consistency exist in the wiki, I personally write pages targeted at novice end user so they tend to be more step by step oriented since I believe that we should expose testing of a component to as wide audience as possible regardless of the individual skill ( it might be a kid taking his first step into the linux, Fedora community and participate or it might be an experienced user ) set while other voices in the community think that they should have University, RHCE or some other degree stuck up their ass to be able to participate in testing or other aspects of the community. When an indvidual changes the layout of my wiki written pages ( other than simply fix my ken-lee English ) I believe ( since he thinks he does a better job than me delivering the content of the page to well what he sees as the target audience ) that he will maintain the given component pages and keep it update to upstream documentation. ( since he has the time to totally rewrite the page he should have the time to do the necessary research and keep it updated to upstream documentation/changes/git logs ). It's not enough simply write those pages they need to be maintained and updated as well and I for one don't participate in wiki writing ping pong game..


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