kill dsc_setup

[geofft]

dsc_setup is really annoying and useless, and arguably helps perpetuate the myth that you should copy someone's .meetings file. If you run discuss without a .meetings file, it should just get you a normal discuss prompt (from which you can run add_meeting/am) instead of annoying you.

[jdreed]

While I don't disagree with the subject line, this is a pretty major change and we should talk about it at release-team. It seems there are several problems here:

• The default meetings are ~useless
• Discuss doesn't just create an empty ~/.meetings file if one doesn't exist.

I don't think anyone is going to suddenly start using discuss if they don't already have a good reason to, so fixing the first point may not be helpful. Perhaps someone from BITD can discuss the rationale behind the second point. If it was simply "to give people some default meetings" then perhaps things should change. If there's some other reason we're overlooking, then we'll find out what it is.

Also, "...but dsc_setup has a man page now!"

[mitchb]

I'd like to understand why Geoff thinks that dsc_setup perpetuates the idea
that you're supposed to copy someone else's .meetings file. Simply because
it makes you aware of that file's name?

It puts default meetings in your setup (and, obviously, creates the file for
you). We shouldn't simply punt that, whether we personally care about those
meetings or not. In fact, I'd argue that "everyone prior to November '09 had
these meetings set up for them, but that doesn't happen anymore" would more
strongly convince people that obviously they should start with an existing
.meetings from someone else.

It's pretty hard to imagine that the code to transition ancient .disrc files
to .meetings is needed in Debathena. And if you ask me, the truly annoying
thing about dsc_setup is that it causes discuss to pull in [t]csh. If we
want to fix sillinesses here, we shouldn't take away the default meetings that
everyone else has (and incidentally, the new_meetings meeting could be useful
if accounts and charon-maintainers decided to announce new public meetings...
I'm not sure why that practice changed). Easy mostly non-controversial things
to do are:

o Rewrite it in Bourne shell syntax, get rid of discuss's csh dependency
o Run it by default, instead of asking "run this thing you need to run?" when
you start discuss.

Note that the latter will change the behavior you see when you run discuss and
your tokens are expired. Of course "If you are using discuss for the first time
... Run dsc_setup now? (y or n)" wasn't as clear as "type 'renew', silly".
We should probably make the error message if it fails to create the file more
clear.

(I'd also be okay with incorporating the moral equivalent of touching the file
and putting those two lines in it into the discuss client, and killing off this
script, but that's mildly less trivial.)

[broder]

I think geofft is crusading or something again.

But I /do/ think it's the case that both of the default meetings are useless, and probably not what anybody actually wants when they start using discuss. eve's last transaction was early 2005, and new_meetings hasn't been updated since 2003. I don't think we should leave them around because somebody might/should start using them again.

[mitchb]

Geoff and I discussed the objection. It's essentially that people have
to answer a question about running dsc_setup. In the end, he doesn't
even mind if dsc_setup itself stays as long as people don't have to do
anything with it, and he's okay with leaving the default meetings.

As long as I'm pretending to be the discuss maintainer, I'll implement
this (either by punting the question, or hopefully with some more
enthusiasm, by ridding us of need to depend on csh).

[jdreed]

Fixed in r24478 - r24480 and uploaded to proposed. Yes, it uses system(), but since its arguments are hardcoded, I can't be convinced to care. "Patches welcome".

Also, dsc_setup.sh is now actually written in sh.

[jdreed]

Er, to clarify:

discuss will now run dsc_setup on your behalf (like edsc does)

I'm not comfortable ripping out dsc_setup entirely, because I bet it's hardcoded in a ton of places.

[broder]

This should be fixed now.