>>>>> Eli Zaretskii writes: >> 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. > Thanks. However, items 3 and 4 are IMO too vague, and can fit almost any > issue, as the criteria are open to subjective interpretation. Yes, if a person lobbies for a bug to be included in the blocking list under these criteria, they'd need to do some convincing on these points. > Also, we used to have criteria related to the age of the bug, on the > assumption that old bugs are less likely to be critical. I'm not saying that > we must keep such a criterion, but I think it should at least be considered > for inclusion. Sure, I'd be willing to add this. A bug that's been in the past 5 versions of Emacs can likely be in a 6th. >> 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. > This sounds like much more stringent criterion than the others. I meant it to summarize what a bug should "feel" like to be considered blocking, but I didn't add it to the list. "Unsuitable" is even vaguer still. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2