> 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.
and i agree that we should hold everybody to this standard. Preferably a big change like this should be mentioned in a verbose commit message, and maybe in the release notes. the problem is that this removal was kind of the joke that started 9front, and back then these kinds of jokes were not documented well yet and a good release process had not been established yet. when it turned out that the joke that was 9front was better than all the serious bizznezz competition, over time, (maybe accidentally?) professionalism set in. i would presume that nowadays there would be better notice in this regard to explain to all the many users in detail (back then there were just few) what awaits them in each release. yes, 9front was trolling, to some extent, but the troll has turned into something extremely useful. > 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. agreed. i'm confident that most of the releases are taking this kind of approach nowadays. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M7234c91e28ba41a8fbd73af7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
