Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Eli Zaretskii <eliz@gnu.org>]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  p.stephani2@gmail.com,  emacs-devel <emacs-devel@gnu.org>, nilsb@google.com
> Date: Thu, 12 May 2016 10:21:55 -0700
> 
> I've already asked for everyone to focus on that list until release. Did you
> not see that? I've mentioned it in a few places.

That evidently doesn't help enough.

> > Previous Emacs releases weren't time-based, but were made when they were
> > ready.
> 
> I only introduced a date to focus our decision making around 25.1, and since
> this is what I'm used to doing to ship software.
> 
> HOWEVER, if having a date is stressful or unpleasant for those doing the work,
> we can get rid of it. I'm not doing this to put undue pressure on anyone.
> Personally, I don't mind if Emacs 25 takes another year to happen, since the
> pretests are working well and 24.5 is fully capable.

It's not stressful.  It's just strange, to say the least, to see a
long list of bugs designated as blocking, with the imminent release
date approaching fast, and almost no one investing any work of any
kind on the blocking bugs, be it re-classifying them so that the list
becomes shorter, or solving them.  Instead, almost everyone work on
master, as if the release is not important at all.

> I want to know what works best for those doing the actual release work. Do you
> want a timeframe? Do you want a release-blocking list?

FWIW, I'd like to see more people working on the bugs deemed blocking
the release.  For instance, some of the bugs identify the commit that
caused it, so the people who made those commits should hopefully step
forward and work on the issues.

Bottom line, there seems to be a certain dissonance between the
announced release date and how we invest our resources.  It's
confusing, at least from my POV.