unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Welsh Duggan <md5i@md5i.com>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: 6174@debbugs.gnu.org, emacs-devel@gnu.org
Subject: bug#6174: 23.2; mouse-sel-mode doc is misleading
Date: Wed, 06 Jul 2011 16:36:52 -0400	[thread overview]
Message-ID: <87sjqjf8nv.fsf@maru.md5i.com> (raw)
In-Reply-To: <m3oc174aay.fsf@quimbies.gnus.org> (Lars Magne Ingebrigtsen's message of "Wed, 06 Jul 2011 18:56:53 +0200")

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>> I was thinking of something more specific like:
>>
>> user emacs24.2
>> usertags fixme
>>
>> but since "pending" is sufficiently general to be applicable to other
>> debbugs packages (and since bugs.debian.org supports it), you can have
>> that as a "normal" tag, if "the Emacs community" would like such a tag.
>
> What do the rest of you think?
>
> The suggestion is to add the flag "pending" for stuff that should be
> done (and we know how to do; like with a patch or the like), but that
> has to wait until after Emacs is opened up for new features the next
> cycle.
>
> This is not for "wishlist" stuff, but concrete fixes that should be
> applied, but not right now.
>
> The idea is that once the next cycle starts (in this case, Emacs 24),
> one could then go through all the "pending" bug reports pretty speedily
> and apply the stuff then.

Glen Morris's suggestion above attaches a specific version to the tag
(possibly in a non-standard fashion).  I think a pending flags is just
fine, but it needs to be attached to a version number somehow.
Otherwise it is inevitable that a report with the pending tag will
remain "pending" at the time of the next release, with no one possibly
realizing that it was meant for that release, and not the one
succeeding.

-- 
Michael Welsh Duggan
(md5i@md5i.com)





  parent reply	other threads:[~2011-07-06 20:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 20:05 bug#6174: 23.2; mouse-sel-mode doc is misleading Drew Adams
2011-07-03  1:10 ` Lars Magne Ingebrigtsen
2011-07-04  1:32   ` Stefan Monnier
2011-07-04 12:20     ` Lars Magne Ingebrigtsen
2011-07-05  0:21       ` Glenn Morris
2011-07-05 13:51         ` Lars Magne Ingebrigtsen
2011-07-06  2:48           ` Glenn Morris
2011-07-06 16:56             ` Lars Magne Ingebrigtsen
     [not found]             ` <m3oc174aay.fsf@quimbies.gnus.org>
2011-07-06 20:36               ` Michael Welsh Duggan [this message]
2011-07-07 20:38                 ` Stefan Monnier
2012-04-10  2:31     ` Lars Magne Ingebrigtsen
2012-04-11  7:07       ` Chong Yidong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sjqjf8nv.fsf@maru.md5i.com \
    --to=md5i@md5i.com \
    --cc=6174@debbugs.gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).