Re: Operation "Careful Emacs"
Philip Kaludercic <[email protected]>
| Newsgroups | gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
Richard Stallman <[email protected]> writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > Decision-making about installing packages has a tendency to be rushed > rather than careful. What do you mean by "installing"? I don't suppose you mean this in the sense of package-install. Are you talking about adding packages to the core (such as with transient, which-key, etc.) or to GNU and NonGNU ELPA? I'll assume you mean the latter -- which is also not related to the message you were responding to which is about distributing packages that are already in GNU ELPA together with an release of Emacs, but ok. > Important questions may go unasked, or their > answers may zip past with little scrutiny. What examples do you have in mind? Specifically what are the "important questions"? If it is whether the package has nonfree dependencies or uses some SaaSS, don't worry because I am taking care of that. > We need to improve the quality of these decisions, not the speed. These are not necessarily unrelated, at least when we consider the overall quality for all participants. If package reviews are artificially lengthened and burdened with low-hanging questions that can be easily answered by a quick internet search, then that scares people away and drives them to third-party archives with lower standards. > To do this, I am thinking of introducing some formal steps into the > process of evaluating a package. I would be untested in seeing the list of steps. > We need to send the list of usual questions, and probe until they have > all been answered with full answers. > > After that, we should schedule a week or two weeks for discussion of > that package. With no decision until that period has finished. > > Instead of using emacs-devel, we should have a separate list > specifically for these discussions. I wouldn't be that enthusiastic about these changes, but it depends on the details and the exceptions.