On 5/15/24 10:20, Don Bailey wrote: > This is part of the issue I've had with 9front. If there are valid reasons > for things to disappear or not be used, that's OK. But please document them > and provide rationale/evidence for their removal. That way, even if another > group chooses not to remove those items, they can learn from other teams' > decision making. This is especially imperative for file system stability, for > those that have not had trouble with Fossil, but need to understand that it > is problematic enough to be pulled from > 9front. How was the lack-of-stability tested? To what degree was it tested? > etc. >
I think many of the reasons and rational has been explained in this list. Really we don't entirely rip out programs often. It's fairly rare. This change was made fairly early on in 9front's history, I think things would have gone over different these days. A technical write-up would be nice, sure I don't disagree but I think people just wanted to stop dealing with the crash reports and lost data and get back to spending time on code they enjoyed to work on. For what it is worth I think our commit messages these days are quite descriptive of the problem being addressed, the details put in commonly directly include the crash repro or failure state or technical description as to why things were done. Also a huge portion of things are discussed on irc, nearly everything that gets put in to the system is discussed with at least 1 additional person and usually more depending on the weight of the patch. There is a lot of thought that goes in to what changes these days. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M18079e3e58e96c530d8a56c5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
