Release-critical bugs

Release-critical bugs

[David Engster]

What are the remaining bugs which are actually critical for 24.4?

I'm looking at

http://debbugs.gnu.org/cgi/pkgreport.cgi?severity=important;package=emacs

and remember Glenn saying that everything below 16000 or even 17000 is
not critical for the next release. Looking at the others, I'm often not
sure if that is something which really has to be fixed for 24.4, while
other bugs are in some kind of limbo where I wouldn't even know what
should be fixed now. Others seem to be solved, more or less (like
#18182, for instance; can that be closed?).

Maybe we could mark the actually release-critical bugs as, say,
'critical', and maybe also list them here and discuss how to fix them?
Especially the GnuTLS stuff goes way over my head, I'm afraid.

-David

Re: Release-critical bugs

[Glenn Morris]

David Engster wrote:

> What are the remaining bugs which are actually critical for 24.4?

Thanks for asking! :)
I'm not keeping particularly close track myself.

> #18182, for instance; can that be closed?).

I don't think it's fixed, but on the other hand I don't think
anything more is going to happen with it.

> Maybe we could mark the actually release-critical bugs as, say,
> 'critical', and maybe also list them here and discuss how to fix them?

Feel free to do that if you think it will help.
I think using severity in this way was a bit of a quick-and-dirty hack.
Maybe a usertag would have been better.

> Especially the GnuTLS stuff goes way over my head, I'm afraid.

And most people's I think. That's why these are long-term issues that
don't see much progress. It seems far too late to make any changes
related to GnuTLS for this release anyway. But nevertheless they remain
important issues (which is why using severity in this way is not great).

Of the important ones, the only ones I would like to see fixed are:

18334
18444

Neither is truly important, and both could be left unfixed at no great
loss for 24.4, but I think someone should at least have a go...

If there are other issues people would like to draw attention to, they
should do so here I guess.

This release is really dragging...

Re: Release-critical bugs

[Ivan Andrus]

On Sep 17, 2014, at 1:40 PM, Glenn Morris <rgm@gnu.org> wrote:

> If there are other issues people would like to draw attention to, they
> should do so here I guess.
> 
> This release is really dragging...

There was at one point a list of “grunt work” that needed to be done before the release that could be done by a non-core developer.  I don’t have a lot of time, but I would really like to see 24.4 released so I would be willing to read/write documentation etc. if it would help.  Where is the list of things someone like me can do (i.e. copyright assigned, but not familiar with the inner workings)?

-Ivan

Re: Release-critical bugs

[Glenn Morris]

Ivan Andrus wrote:

> There was at one point a list of "grunt work" that needed to be done
> before the release that could be done by a non-core developer. I don't
> have a lot of time, but I would really like to see 24.4 released so I
> would be willing to read/write documentation etc. if it would help.
> Where is the list of things someone like me can do (i.e. copyright
> assigned, but not familiar with the inner workings)?

I don't think any such issues remain, but thanks for the offer!

Re: Release-critical bugs

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 17 Sep 2014 15:40:39 -0400
> 
> This release is really dragging...

I don't think I agree with that.  There are important bugs being
reported and fixed all the time, so I think we still have some fallout
from the major changes that went into this release.

Re: Release-critical bugs

[Rasmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Date: Wed, 17 Sep 2014 15:40:39 -0400
>> 
>> This release is really dragging...
>
> I don't think I agree with that.  There are important bugs being
> reported and fixed all the time, so I think we still have some fallout
> from the major changes that went into this release.

I would be interested in this as well.  The critical bugs are really
to difficult for me.

-- 
Together we will make the possible totalllly impossible!

Re: Release-critical bugs

[Eli Zaretskii]

> From: Rasmus <rasmus@gmx.us>
> Date: Thu, 18 Sep 2014 14:57:46 +0200
> 
> > There are important bugs being reported and fixed all the time, so
> > I think we still have some fallout from the major changes that
> > went into this release.
> 
> I would be interested in this as well.

Then please jump on the bugs being reported by saying something "I'm
on this one".  And thanks in advance.

(It's not like there's a list I have of those bugs that others don't
know about.  I'm talking about things being reported regularly, and
usually fixed within a day or two.)

Re: Release-critical bugs

[Glenn Morris]

Eli Zaretskii wrote:

>> This release is really dragging...
>
> I don't think I agree with that.

That makes me feel a bit better! :)
But I still think it's going too slowly.
Some packages (and even entire distributions) manage releases on a
six-month cycle (not that that is necessarily something to emulate).
But 9+ months of pretesting feels like too much.

Re: Release-critical bugs

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 18 Sep 2014 13:28:29 -0400
> 
> Eli Zaretskii wrote:
> 
> >> This release is really dragging...
> >
> > I don't think I agree with that.
> 
> That makes me feel a bit better! :)
> But I still think it's going too slowly.
> Some packages (and even entire distributions) manage releases on a
> six-month cycle (not that that is necessarily something to emulate).
> But 9+ months of pretesting feels like too much.

Suggestions for how to make it faster will be welcome, I'm sure.

Re: Release-critical bugs

[Glenn Morris]

Eli Zaretskii wrote:

> Suggestions for how to make it faster will be welcome, I'm sure.

A test-suite for absolutely everything, so we can just type `make check'
and be done. ;)

Less flippantly, more concentrated focus on the release, less "a handful
of people try to get the release in shape while the majority play with
the trunk (and argue about VCS)". (But this might just be my biased
impression.) Also a defined release manager position, with the authority
to set deadlines and decide what needs to be done, which I think was
lacking this time. (I don't want the job; it needs to be someone
motivated and with Emacs experience.)

And more documenting of changes closer to the time they happen, by the
person who makes the change, rather than leaving it to the end.

Some way to get more people using the release branch rather than the
trunk. (Maybe the trunk should be the release branch, and the
development should happen elsewhere; but I think this was rejected
before for various reasons?).

We have ~ 200 developers, in theory. I think say 6 months from feature
freeze to release ought to be doable, though I would not want to be
dogmatic about it; it should take as long as it takes.

When it takes too long, people get disheartened and lose focus.

Re: Release-critical bugs

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 19 Sep 2014 12:49:13 -0400
> 
> Less flippantly, more concentrated focus on the release, less "a handful
> of people try to get the release in shape while the majority play with
> the trunk (and argue about VCS)".

I can't agree more, but the question is how to reach that goal?

> (But this might just be my biased impression.)

My impression is similar, FWIW.

> Also a defined release manager position, with the authority
> to set deadlines and decide what needs to be done, which I think was
> lacking this time. (I don't want the job; it needs to be someone
> motivated and with Emacs experience.)

We need a volunteer, yes.

> And more documenting of changes closer to the time they happen, by the
> person who makes the change, rather than leaving it to the end.

I suggested that once, but the suggestion was rejected.  I still think
it's a good policy, successfully implemented in other projects.

> We have ~ 200 developers, in theory. I think say 6 months from feature
> freeze to release ought to be doable, though I would not want to be
> dogmatic about it; it should take as long as it takes.
> 
> When it takes too long, people get disheartened and lose focus.

I absolutely agree, but the problem is a practical one; I think we are
all together on the principles front.

Re: Release-critical bugs

[Ted Zlatanov]

On Wed, 17 Sep 2014 15:40:39 -0400 Glenn Morris <rgm@gnu.org> wrote: 

GM> David Engster wrote:

>> Especially the GnuTLS stuff goes way over my head, I'm afraid.

GM> And most people's I think. That's why these are long-term issues that
GM> don't see much progress. It seems far too late to make any changes
GM> related to GnuTLS for this release anyway. But nevertheless they remain
GM> important issues (which is why using severity in this way is not great).

Let me try to summarize (adding CCs to the parties involved that may not
read emacs-devel):

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16978 [i|*| ] [emacs] 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities 
  Reported by: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>; Date: Mon, 10 Mar 2014 07:00:02 UTC; Severity: important; Tags: security; Found in version 24.3; Filed 198
  days ago; Modified 184 days ago; 

We made some fixes. To make things work well we'll need a certificate
management UI, which IMO can happen after the current release.

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17625 [i|*| ] [emacs] details of package signing mechanism 
  Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>; Date: Thu, 29 May 2014 03:12:01 UTC; Severity: important; Tags: security; Found in version 24.4.50; Filed 118 days
  ago; Modified 89 days ago; 

Daiki Ueno made some fixes. Stefan got the detailed steps for generating
a package signature and we need at least one package plus the
archive-contents signed by the maintainer in the GNU ELPA to test the
client behavior. This seems OK to me as far as the code.

Stefan suggested some behavior changes that we can implement and test
easily, but are not IMO critical for the release.

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17660 [i|*| ] [emacs] 24.3; gnutls-min-prime-bits is 256 
  Reported by: Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr>; Date: Sun, 1 Jun 2014 13:25:01 UTC; Severity: important; Tags: security; Found in version 24.3; Filed 115
  days ago; Modified 110 days ago; 

This touches several older tickets.

I said "the proper fix seems to be to change the default for
`gnutls-algorithm-priority' but that may break some people's setups
(just like raising `gnutls-min-prime-bits' would)" and it's still the
case.  Opinions are welcome.

Considering the Emacs user base, I'd rather live with a slightly
insecure setting in 24.4 and address this in 24.5 together with the
certificate management UI.

I hope that's helpful.

Ted

Re: Release-critical bugs

[Stefan Monnier]

>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17625 [i|*| ] [emacs] details
> of package signing mechanism 
>   Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>; Date: Thu, 29
> May 2014 03:12:01 UTC; Severity: important; Tags: security; Found in version
> 24.4.50; Filed 118 days
>   ago; Modified 89 days ago; 

> Daiki Ueno made some fixes. Stefan got the detailed steps for generating
> a package signature and we need at least one package plus the
> archive-contents signed by the maintainer in the GNU ELPA to test the
> client behavior. This seems OK to me as far as the code.

> Stefan suggested some behavior changes that we can implement and test
> easily, but are not IMO critical for the release.

The GNU ELPA archive is now signed and the emacs-24 branch comes with
the corresponding public public key.  In my tests, this works OK, but
please try to install packages from GNU ELPA with and without GPG
installed, and try it also with package-check-signature set to t.


        Stefan

Re: Release-critical bugs

[Jens Lechtenboerger]

On 2014-09-24, Ted Zlatanov wrote:

> Let me try to summarize (adding CCs to the parties involved that may not
> read emacs-devel):
> [...]
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16978 [i|*| ] [emacs] 24.3;
> SSL/TLS with multiple man-in-the-middle vulnerabilities
>   Reported by: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>; Date:
> Mon, 10 Mar 2014 07:00:02 UTC; Severity: important; Tags: security; Found in
> version 24.3; Filed 198
>   days ago; Modified 184 days ago; 
>
> We made some fixes. To make things work well we'll need a certificate
> management UI, which IMO can happen after the current release.

I agree.

Thanks for adding me
Jens