Bug#802159: New OpenSSL upstream version
On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote:
> On Tue, 20 Oct 2015, Don Armstrong wrote:
> > On Sat, 17 Oct 2015, Kurt Roeckx wrote:
> > > I've been waiting for the release team for a while to make a decision
> > > on #765639 for a year now. Could you help in getting a decision?
> > >
> > > I've actually been waiting for longer than that, I can't directly find
> > > all links, but previous discussions about it are at least:
> > > https://lists.debian.org/debian-devel/2013/09/msg00466.html
> > > https://lists.debian.org/debian-project/2013/12/msg00140.html
> >
> > Is there anything that it would be helpful for the technical committee
> > to do here to help facilitate coming to a decision on this?
>
> From discussions (briefly) on IRC:
>
> <adsb> my general thoughts offhand are that new upstream versions in
> stable always make me twitchy, new upstream versions that
> introduce features or are sensitive / important packages more
> so, new upstream versions that do both doubly. and we try and
> avoid ending up saying no to people, which often ends up
> actually making things worse as they linger (and we're not
> doing that well at keeping up with the "easy" requests right
> now)
So as already pointed out before, since the 1.0.0 release there is
a new release strategy that in the 1.0.x series, where x doesn't
change, no new features are added unless it's really needed for
either security reasons or compatibility reasons. As far as I
know between the version in oldstable (a patched 1.0.1e) and
1.0.1p only 1 feature got added, and people really have been
asking for that one.
OpenSSL upstream also already has a policy that at least 2 people
from the team should review all the changes. Since there are so
many changes I don't think it's reasonable for the release team to
review all of them.
The alternative is that I go and cherry pick the important bug
fixes. By this time there are really a lot that I would like to
have in the stable releases and I think going that way actually
has a higher chance of breaking things.
> So from what I'm gathering, this looks like a case where there isn't
> enough eyeballs to adequately review this particularly set of updates,
> coupled with the importance of making sure that these updates are
> correct and don't cause any unintended issues.
There is always the case that one persons bug is an other persons
feature. But those new upstream versions have been in stable and
testing for a while now without actually breaking anything.
Kurt
Reply to: