Re: release

Re: release

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Is there a list of things that need to happen for the release?
>
> We have a bug tracker now, can the bugs that need to be fixed for the
> release be marked somehow?  Are all the must-fix bugs in the bug
> tracker?

As we get closer to the release, we will use the severity tag in the bug
tracker to indicate release-blocking bugs.  I think we are not close
enough to the release for that, yet.  The main outstanding issues, off
the top of my head, are: (1) bugs in the new internationalization and
font-handling code.  Bug reports are still slowly trickling in,
indicating that the code has not converged sufficiently yet.  (2)
Several files in the Emacs and Emacs Lisp reference manual still need to
be checked (progress seems good, but this is a slow process.)

Re: release

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Is there a list of things that need to happen for the release?
  > >
  > > We have a bug tracker now, can the bugs that need to be fixed for the
  > > release be marked somehow?  Are all the must-fix bugs in the bug
  > > tracker?
  > 
  > As we get closer to the release, we will use the severity tag in the bug
  > tracker to indicate release-blocking bugs.  I think we are not close
  > enough to the release for that, yet.

If there are bugs that are known to be release blocking, why not mark
them ASAP?  If  they prove later to not be so important, they can be
unmarked.

Again, knowing what needs to be done provides an extra incentive for
people to do it.

Too bad that the number of people that can fix the most critical of bugs
(unicode) is so tiny...

Re: release

[Stefan Monnier]

> We have a bug tracker now, can the bugs that need to be fixed for the
> release be marked somehow?

Supposedly there is a way to do such things (mark a bug as "blocking"
some release), tho I haven't figured it out yet.  I think using the
severity for it is OK, as well.

> If there are bugs that are known to be release blocking, why not mark
> them ASAP?

No reason at all.

> Are all the must-fix bugs in the bug tracker?

AFAIK, yes.


        Stefan

Release

[Glenn Morris]

It's now 3 days past the projected released date included in RC2.
Yet there continue to be (trivial) changes made to the emacs-25 branch.
I suggest absolutely forbidding all changes, making another RC with a 3
day timer, and then shoving the release out the door. Or if you feel
braver, just go straight to release.

Re: Release

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:

GM> It's now 3 days past the projected released date included in RC2. Yet
GM> there continue to be (trivial) changes made to the emacs-25 branch. I
GM> suggest absolutely forbidding all changes, making another RC with a 3 day
GM> timer, and then shoving the release out the door. Or if you feel braver,
GM> just go straight to release.

Changes that are purely documentational are no problem.  They don't change the
purpose of the RC, and so we can accept them up until the very last moment,
when Nicolas cut the final tarball and we ship it.

Put another way: cutting an RC for doc changes cannot tell us anything new
about the potential stability of the release. And so, *modulo documentation
changes*, there have been no recent changes to emacs-25 that Eli did not deem
critical.

Changes to *code* should absolutely not be happening now, unless there is
enough justification to require pausing the release process and sending out
another RC and another waiting period.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]