Re: Basic questions about the triage process

[Eli Zaretskii <eliz@gnu.org>]

> From: CHENG Gao <chenggao@royau.me>
> Date: Tue, 29 Dec 2015 14:46:48 +0800
> 
> > Andrew, I think your strategy is good, but can we turn that clock back
> > to two years? Emacs doesn't move all that rapidly. If you can't
> > reproduce something From 2013 or earlier, close it as cannot reproduce
> > with a CC to the original reporter. Otherwise, ping the submitter with
> > a CC to the bug address saying it can't be reproduced, but leave it
> > open.
> 
> Maybe the strategy needs a clarification of version supporting policy or
> should be based on said policy if it exists.

We always support only the latest released version, but if a bug
reported in an old version still exists in the latest one, we try
fixing it in the next release.

IOW, I don't see any relation between version support policy and the
strategy of triage of bug reports.

> The priority could be as below:
> 
> Number one: emacs-25 branch related
> Should have highest priority since they'll block the release.
> 
> Number two: emacs git
> They slow down moving train.
> 
> Number three: emacs 24.x
> Maybe a policy to include accumulated fixes in a new release untill
> support dropped, for example yearly bugfix on Dec. 25 or Dec. 31.
> Bug fixes only, no new feature backports.
> 
> Number four: emacs 23.x/22.x etc (justing kidding. No kidding?)
> If bothered by "cannot sleep thinking users are abandoned in darkness"
> syndrome, accept users submitted patches and release accumulated bugfix
> minor version each year as above.

I don't think triage should depend on bug priority.  On the contrary,
priority can only be established once the triage has been done; thus,
triage should always have the highest priority, IMO.