emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Making better use of the "release blocking list" [was: bug#23288: 25.0.9


From: John Wiegley
Subject: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]
Date: Thu, 12 May 2016 10:21:55 -0700
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.93 (darwin)

[I'm moving this discussion from Bug #23288 to Emacs-Devel, to widen
participation]

>>>>> Glenn Morris <address@hidden> writes:

> Eli Zaretskii wrote:
>> Sorry, I don't see the list of blocking bugs being treated seriously. If we
>> did treat it seriously, we wouldn't have had "deep freeze" on emacs-25, and
>> wouldn't be planning the release in less than a month.

> Indeed. Though I have noticed some people looking at those issues recently
> (thanks!).

> I'd hope those in charge would be encouraging people to work on those
> issues, but I haven't noticed it happening.

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.

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

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?

If you'd prefer to do this in an unstructured way -- if that's what will
improve our bug closure rate and our code quality -- then by all means. But I
want to hear that from the core developers first, as it also introduces a bit
of chaos (for example, I'd have no real metric by which to ask people to
revert a change they just made on a release branch, other than gut feeling).

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]