Criticising open-source software is like criticizing a democratic
government... It annoys lots of people, but it is ESSENTIAL to the
continued growth and betterment of the target of criticism. Hopefully
the target remains worthy of thoughtful people taking the time to make
such criticisms...
Every word which follows is intended to be constructive.
On Thu, May 25, 2006 at 04:27:50PM -0700, Martin Swift wrote:
> 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") ...
[...]
> 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.
I don't think this argument holds any water.
As I've already said, I believe if the transition is handled properly,
the impact to users is very nearly zero. If we're only talking about
renaming variables, then there will be a 1 to 1 mapping of old names
to new names. This mapping can be provided in a documentation file,
and more importantly it will be SIMPLE to write a script to convert
old .muttrc files to the new variable names. You can even have the
new version of mutt detect old configs, and run the conversion script
automatically (being cautious to save the old version, writing the new
version to .muttrc-new-version-number or some such thing.
As for re-learning variable names, this also seems like a silly
argument. Here's why:
1. Most variable names are just simply not remembered by the vast
majority of users -- there are way too many of them -- and need to
be looked up each time they want to make a change.
2. If you've got a commented sample .muttrc, and a conversion script
to change your existing configuration, 95% of the battle is won --
you will already have what you need, PLUS a reference to the
variables which you already had to change (the converted
configuration), PLUS a documentation file which maps all the rest of
the names to their new names. If you really do remember the old
name, getting the new name is simple. You could even have the
conversion script spit the names out, so getting the new name would
be as simple as:
$ muttrc-convert --list |grep old_variable_name
old_variable_name -> new_variable_name
3. Additionally, for people who are particularly obstinate about not
changing, there is no reason both names can't be used
simultaneously.
I imagine the percentage of people who genuinely know the mutt command
interface well, and would genuinely be significantly inconvenienced by
such a reorganization of variable names, is extremely small. Those
rare few people are mutt's uber-users, and such people should, I
think, expect to be inconvenienced by changes in the name of making
better software.
I honestly don't mean to be insulting, but I just can't see how this
is a real issue, except for people who are excessively lazy or
excessively brain-dead, or people who just oppose change for the sake
of being obstinate. The only real issue in my mind is whether someone
is willing to spend the time to organize the variables and make the
code changes. And it appears that someone is...
And the bottom line is, if such a change were made, and you don't want
to upgrade, no one is going to force you to. You can still use the
old variable names, by using the old version of mutt.
> 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.
If someone continues to use an old version of mutt, they are not
affected. Their old config will work fine. If someone decides to
switch to the new version, the conversion is done once, automatically.
If someone finds that they are running two different versions of mutt
in different places, and they don't feel like they want to maintain
two different muttrc versions, tough noogies. You have two choices:
suck it up, or choose to run whichever version of mutt you are forced
to run somewhere in both places you run mutt.
> I agree with both Gary and Markus that the intended benefits can be
> approached by improving the documentation and categorising the
> variables.
Only part of the benefits can be achieved. Re-organizing the names
makes the code easier to maintain, because the names are clearer, and
the coder should theoretically need to look at a lot less code to
figure out what a particular variable does, and whether or not the
changes they are working on will affect how it behaves. The benefit
to users (especially new ones) of having a clean, consistent
configuration interface can only be achieved by new variable names.
> 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.
A todo list goes against Mutt's development philosophy of not having
any sort of strategy or roadmap... :-D
OK, that last was mostly just a dig partially meant in jest, but
there's a kernel of contstructive criticism in there. In case this is
lost on the reader, whatever else you think of me and my opinions,
please understand that the reason I am so vocal and occasionally harsh
in my criticism of mutt and its current design trends is that I
genuinely do care about the quality and future of this fine piece of
software, and hope that my strong words encourage people to think
about what is on the table, and strive to make mutt ever better,
rather than just what's convenient right this moment... The prevalent
attitude here appears to be, "don't break compatibility, no matter how
much better the software would be," which I will remind you is one of
the biggest reasons most of you don't (want to) use Microsoft Windows
today. That design philosophy leads to software that sucks. Period.
Various people on this list not too long ago espoused the idea that
developers should not listen to users when making design decisions,
because "users are idiots" (someone else's words, not mine). This is
definitely true, when the users are clearly motivated by their own
convenience, and that hinders making the software better. [*] This
change is not a panacaea by any means, but it's a step in the right
direction and part of a much larger redesign that mutt is sorely in
need of, so that it can continue to grow flexibly and improve in the
future...
-=-=-=-
[*] Lots of users ARE idiots, and also lots of users ARE NOT idiots.
User input is a valuable tool when deciding what features will improve
a piece of software which is targeted at users... Not all ideas are
good ones, but a lot of ideas will be. The role of the developers,
IMO, should be to exercise good judgement in choosing what features to
implement, based on what features are consistent with the design of
the program, and MOST importantly, what features will make the program
easier to use, more fun to use, and give the user the most power,
without sacrificing the quality of the code. It is, IMO, NEVER the
roll of developers to shield users from the burdens of upgrades, when
the upgrades genuinely make the software better. And even if it were,
the improvements we're talking about here really don't represent much
of a burden on the vast majority of users, if they're handled well,
which I think I've clearly demonstrated.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpm9Dhv3j1LU.pgp
Description: PGP signature