I .. kinda like the idea. What might even be nice, is to have news items about the project pop up. Maybe just use the tech-notes as input? Latest tech-node is shown once...

Maybe just use the tech-notes as input? Latest tech-node is shown once...

That's an interesting idea. i was thinking the motd should be transient, but we already have technotes, and that might be a good reuse of them.

Also could use a wiki page with the name MOTD/clone or some such. MOTD/ would go out for all interactions (pull, clone etc.). Change the part after the / for different interactions MOTD/pull is only shown on pulls etc.

Not sure how you would restrict access to this though. Having the ability to review previous MOTD messages could be useful.

This would also mean no changes to the transfer protocol to send the MOTD. It just moves as part of the blockchain. Then the client can see if it has changed and issue the MOTD. This allows the user to say:

• motd - every time
• motd - if not already shown
• motd - I know all I need to know

i like this approach as well, but share Sean's concern (is it real?) about potential blindness resulting from over-use by arbitrary team members. The wiki would probably be the most natural place for it, but we don't have (and probably don't want) the ability to limit write access to specific pages to certain user classes (probably setup in this case).

We have the convention of tying wiki pages to stuff using a name prefix, so motd/pull, motd/clone, etc, would be a perfectly reasonable place to pack such messages.

i'm now wondering if, when updating to a branch/tag/checkout, if there's a corresponding wiki page we should simply dump that to the screen (if it's plain text) or start fossil ui at that wiki page? That would effectively provide the motd feature using only existing infrastructure.

I don't like that, if you have a branch with lots of text then your screen will get quickly full of what might be nonsense.

Hi Stephan:

about potential blindness resulting from over-use by arbitrary team members.

Yeah it can be a thing. I ignore the motd on a number of sites I log into. In fact when I write them. I make obvious changes (more lines, additional markup) to make a visual distinction between older and newer motd messages.

The blindness is also why I suggested a client side option to control the display of the motd.

we don't have (and probably don't want) the ability to limit write access to specific pages

Actually I kind of would like this (e.g. to prevent defacing of the wiki content on the Home page). But that's another kettle of fish.

If what we want is to control if the changes to a wiki page should be emitted, what about some sort of checksum under the control of the setup or admin users. If the MOTD page checksum matches the blessed value then the motd is shown. Otherwise it's not.

I am not in love with this idea as a change to MOTD and not updating the checksum will result in the MOTD silently failing and the MOTD author will have no idea.

i'm now wondering if, when updating to a branch/tag/checkout, if there's a corresponding wiki page we should simply dump that to the screen (if it's plain text) or start fossil ui at that wiki page?

I am not sure that works. I see MOTD more as a repo notification and not a branch notification. E.G. you have a security patch that has been put in trunk that everybody working on private feature branches needs to merge. (I realize being able to turn off the motd like I suggested upstream makes it less useful for this purpose.)

Actually I kind of would like this (e.g. to prevent defacing of the wiki content on the Home page). But that's another kettle of fish.

Agreed.

If what we want is to control if the changes to a wiki page should be emitted, what about some sort of checksum under the control of the setup or admin users. If the MOTD page checksum matches the blessed value then the motd is shown. Otherwise it's not.

i was thinking about the page's timestamp for that - only show the motd if it's newer than the last time we showed it (which we would need to record locally), but a hash token might make more sense. Hmmm... except there doesn't appear to be a fast/efficient way to get a wiki page's timestamp (or its hash, for that matter - the info in the event table (the timeline) maps to the raw wiki artifact, not its name).

Would it really be "of the day" so that if there's nothing in the last ~12-24 hours it would drop off? I have a feeling some folks may a)overlook it or b) forget or just don't change it out.

Plenty of people at my employer write "update", "new", "fixed", "bug fix", etc for their commit messages (not via fossil). While it's possible that people would write nice messages in this proposal, I don't know if everyone would read them/notice them, and then there's the possible vague messages. "bug fixed now" would be a terrible thing to see with this proposal.

tl;dr It's nice but I don't know if it would be taken advantage of enough and effectively. (though I realize that's not a technical limitation).

Would it really be "of the day" so that if there's nothing in the last ~12-24 hours it would drop off?

That wasn't my intent. motd comes from the conventional message file on Unix-style systems: if /etc/motd exists then it is shown to users when they log in.

While it's possible that people would write nice messages in this proposal, I don't know if everyone would read them/notice them, and then there's the possible vague messages. "bug fixed now" would be a terrible thing to see with this proposal.

Yeah, i was thinking more about post-clone instructions which might be needed for a repo, e.g. setting the "safe-html" flag to a value compatible with the repo's content. (That flag is, since yesterday, now pulled on the first clone and whenever the skin is synced, but older versions don't do that.) Similarly, maybe a reminder about how to pull the latest versions of the repo or a pointer to the main documentation wiki/file. Or maybe it shows a warning that the project is no longer maintained and directs the user to alternative projects. Presumably the website would say so, but people who cloned it long ago might pull regularly without ever visiting the site.

tl;dr It's nice but I don't know if it would be taken advantage of enough and effectively. (though I realize that's not a technical limitation).

My proposal is that only a setup user would be able to modify this, not a developer or even a non-setup admin. That "should" help keep the noise level down.

I'm not sure about MOTD, but I do see a need for real-time comms between developers. The need for this is illustrated by two recent events:

1. Fixing a bad merge which resulted in some concurrent developer confusion.

2. Merging a branch before it was ready resulting in a trunk version that segfaults.

On the SQLite project, the developers have a private chat room that we use to coordinate activity. Perhaps something like that could be added to Fossil to help coordinate activities.

Your forum post links don't work, and I don't know why. I'd like to think they're to be interpreted relative to the current URL directory, but Fossil is choosing not to emit href attributes for <a> at all. Tellingly, it's also not eliding the square brackets. My guess is Fossil doesn't recognize those hex strings as check-ins or files.

Here are the corrected links:

• bad merge
• developer confusion
• before it was ready

My guess is Fossil doesn't recognize those hex strings as check-ins or files.

That makes sense since the forum is a separate fossil repo and those checksums/ids don't exist in the forum fossil's list of artifacts.

That was my first guess too, but when I looked into it, they are actually the IDs of forum posts in this same repository.

Your forum post links don't work, and I don't know why.

They work for me but they're taking me to the /info entries rather than the /forumpost entries.

Edit: looking at the source of that post, he wrote the links like:

[bad merge](1477c7840b) ...
[developer confusion](8588a991ad) ...

Whereas /forumpost/hash would probably be preferred.

The question is whether what we've got is fine or if we really do want to allow linking to forum posts using the same syntax as linking to artifacts. I don't have an opinion here.