[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
signature.asc
Description: PGP signature
- Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection],
John Wiegley <=
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Paul Eggert, 2016/05/12
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Glenn Morris, 2016/05/16
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], John Wiegley, 2016/05/18
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Eli Zaretskii, 2016/05/21
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Mike Kupfer, 2016/05/21
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Bill Wohler, 2016/05/23
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Bill Wohler, 2016/05/30
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Paul Eggert, 2016/05/21
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], John Wiegley, 2016/05/22
- Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection], Eli Zaretskii, 2016/05/22