Re: A GNU Binutils wiki

[Nick Clifton <nickc@redhat.com>]

Hi Joel,

> Not to be negative but what type of content is going to go in the Wiki?

Well I am hoping that there will be two types of content:

  1. Things that will encourage people to contribute to the binutils.
  2. Information that will help binutils users solve their problems
     (without having to post questions to the mailing list).


> Over at RTEMS, I've become quite disillusioned with Wikis for most
> content. Not being integrated with the source processes, version
> control, and releases, it can become out of sync and out of date.

To be fair I am expecting that much of the content will not be that
sensitive.  Things like the descriptions of what the tools do, how to
contribute changes, where to ask for help, the history of the project
and so on.  These are all fairly static.


> It's usually much easier to keep documents in any markup system
> up to date than a wiki.

Would you feel happier if the text for the wiki was kept in the sources
and then uploaded to the site on a semi-regular basis ?  (eg when releases
are made, or once a month, or some other schedule).


> This ignores that Wikis get vandalized and have spam account attempts
> which doesn't seem to happen with source code in git (or cvs).

Ideally the fact that only people in the EditorGroup can make changes
to the wiki should help to reduce/eliminate this problem.


> What's the process for ensuring any links in the wiki don't break?

There isn't one.
(I would assume that broken links would be reported and fixed, but
there is no formal scheme for verifying that any links continue to
work).


> What review processes are going to be used for content?

Similar to the current process for patch review would be my assumption.
People with EditorGroup access can make changes directly.  Others
would submit changes for review and eventual application.


> What's the driving content need for a wiki?

Apparently wikis have been successful for other projects, eg glibc,
and I am trying, in a small way, to bring the GNU Binutils up to date.

It was pointed out for example that we do not have a Code of Conduct
or a Mission Statement.  Now some people might feel that these things
are not really necessary, but would it hurt to have them ?  And if we
do have them, where would a naive, unexperinced-with-the-binutils
person look for them ?


> Sorry to be negative. I like the "control" in source code control
> and a wiki is lacking there.

That's fine.  It is good to have an opinion and I am glad that you
are willing to express it.  My counter would be - what can we do instead ?

I know that most of the information intended for the wiki can be found
by digging through the sources, but that will not work for people who
are not already deeply familiar with the binutils.  So I wanted to create
a place where people with at least some experience with other part(s) of
the GNU toolchain would expect to be able to find information on the
binutils.

Plus I wanted to provide a location for binutils users and contributor to
be able to provide their own content.  Descriptions of the problems that
they encountered whilst porting the binutils; advice for users of small
devices that need custom linker scripts in order to work properly and so
on.

Plus a location with responses to frequently asked questions(tm) which we
can use when answering those I-have-found-a-name-mangling-bug and
why-doesn't-the-assembler-auto-correct-my-bugs type questions on the
mailing list.

Cheers
   Nick