>>>>> Eli Zaretskii writes: >> From: John Wiegley >> >> I'm wondering if you and some of other core devs would be willing to spend a >> few days scanning through the blocking bugs list[1], to see which ones really >> need to be fixed in the next month, and which can be deferred until later? > We'd need clear criteria for nominating blocking bug reports. Could you > publish what you think should be those criteria? Sure, that's a great question. These would be my criteria at this point: A bug should be considered release blocking for 25.1 if: 1. It causes loss of user data. 2. It renders core functionality unusable without any acceptable workaround. This includes: crashing, hanging, runaway memory consumption, exhaustion of limited resources such as file handles, etc. The extent of "core" is open to debate, but basically I mean features used by a great many users. 3. The presence of the bug makes basic functionality annoying or cumbersome. 4. The presence of the bug would cause widespread breakage in community packages, unless there is an acceptable upgrade path. 5. It impairs the goals of the Free Software Foundation. In other words, as long as the presence of bug X doesn't make Emacs unsuitable for use, I'm willing to live with bug X until the next point release. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2