Re: bug#6174: 23.2; mouse-sel-mode doc is misleading

Re: bug#6174: 23.2; mouse-sel-mode doc is misleading

[Lars Magne Ingebrigtsen]

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#6174: 23.2; mouse-sel-mode doc is misleading

[Michael Welsh Duggan]

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)

bug#6174: 23.2; mouse-sel-mode doc is misleading

[Stefan Monnier]

>> 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.

Sounds good, tho IIUC debbugs already has a notion of "pending" as a bug
state, so maybe we should use another word, such as "postpone".

> 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.

That's a risk, indeed.  We could use a script to un-postpone all bugs
whenever the new branch is opened.

OTOH, we've used a different approach in the past: create a new branch
`pending' and install patches there.


        Stefan

New tag(s) for debbugs.gnu.org? [was Re: bug#6174: 23.2; mouse-sel-mode doc is misleading]

[Glenn Morris]

As a general comment, please can we think about changing the subject and
the cc list when starting a new topic. This discussion has nothing to do
with mouse-sel-mode, and isn't appropriate for bug#6174's record.

Stefan Monnier wrote:

> Sounds good, tho IIUC debbugs already has a notion of "pending" as a bug
> state, so maybe we should use another word, such as "postpone".

Not really. As I said, bugs.debian.org has "pending" as a tag, but
debbugs.gnu.org does not. ("pending state" does appear in the search
terminology, but I'm not sure that is relevant.)

> We could use a script to un-postpone all bugs whenever the new branch
> is opened.

I don't see what there is for a script to do. You just want someone to
search for all the bugs tagged "pending" (or whatever) and fix them.
Someone (TM) just has to remember to do that when the time comes.