>I submit these as possible ways to prevent another fiasco like that following the >fork. I do not demand that either be implemented. > >1. Before a major change such as this is taken, which will modify people's nodes >severely and may cause some not to want to upgrade, send mails to announce and devl. >Say, a day or a few hours, or even just an hour before - anything. Then, people concerned about this can check announce and/or devl before upgrading. >There would not have to be discussion; the devs could still unilaterally change >things, as long as there was fair warning. So comments on these pre-change messages >would not necessarily be listened to. Some discussion is a good thing, but if there is no consensus or real convincing arguments (as with the fork discussion), then it's the devs' decision.
yes, that would be fine and everybody stays happy >2. Send mails to announce and devl every time a new build is released, naming its >changes. Then, people can upgrade only once they see this message and they decide >they like the changes. This is more work for the devs than #1, but might be more pleasant for the users. Certainly, it's nice to see what has changed, even if it's nothing major. And advanced auto-update scripts could listen for it. subscribe to the cvs mailinglist! no need for the devs to type everything twice, as cvs commits already inform you en detail what was changed _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
