Re: Poll: personal convenience vs. global improvement of docs
On Thu, May 25, 2006 at 01:30:45AM +0200, markus reichelt wrote:
> * Gary Johnson <garyjohn@xxxxxxxxxxxxxxx> wrote:
>
> > In short, the benefit of changing names is minimal.
>
> I agree.
ditto, but (and there is always a "but") ...
First off, changing the variable names would be a great idea as the
proposed changes do make a lot of sense ... if only it weren't for the
drawbacks. ;-) Both sides have made valid points, and this may sadly
prove to be the greatest hurdle in this discussion. I don't think
we're faced with a question of what is right, but a matter of
preference which inevitably is going to vary between people.
Before this turns into a bikeshed debate[1], I propose that we see if
there is room for a compromise here? I think most of the issues have
come forward and any more stomping will probably just drive people
deeper into their trenches.
I was sceptical of the move from the beginning and have to admit that,
though there are some good ideas out there, I don't think they
outweigh the frustration of broken setups that plenty of (mostly
non-technically oriented) people will face. Not everyone uses mutt by
choice and sysadmins may deceide to rather not upgrade or change the
default mailer rather than face a potential hassle. I agree with both
Gary and Markus that the intended benefits can be approached by
improving the documentation and categorising the variables.
Others will disagree and I can see their point. So, is there any
chance we can make a compromise between the two camps? Something like
an improvement for newbies that involves the variable change and won't
break configs (at least not right away).
FVWM has for quite a while now supported two sets for some of their
variables. Is there any reason why mutt couldn't either (parsing the
config doesn't seem to take long)? The new ones could be introduced in
an upcoming release. A later one would spit out a message to the
terminal at startup alerting the user that (s)he is using deprecated
variables, which ones have replaced them and that support will
eventually be removed.
As this won't do a lot of good without the documentation, how about
improving it before diving into the change? There could be a todo list
of critical items that needed to be added and changed before changing
the variables.
Granted, it could possibly be the first upgrade of software
documentation which precedes actual software upgrade. Seeing that the
purpose of the change is explicitly to help newbies and making
configuration easier, I don't think anyone think anyone will get
kicked out of their hax0r clubs. ;-)
Sincerely,
Martin Swift
[1]
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
--
\u270C