You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2006/05/08 13:36:26 UTC
Dealing with Regressions
OK, we all know we get some embarrassing regressions in our new
releases. PR#39490 in 1.3.35. Or 2.0.55 being effectively unusable
in a proxy due to PR#37145. Look at the number of duplicates of
37145 - that's a lot of people with the confidence to report it,
and who didn't find it 'cos it's marked as fixed (despite no fixed
version being released until last week).
We should do better than leaving the users to rediscover and deal with
regressions themselves, once we know there's a problem. Can I suggest
an Errata page, to list *all* known regressions in current/recent versions,
linked from the main page alongside "Download/New Features/Changelog"?
--
Nick Kew
Re: Dealing with Regressions
Posted by Nick Kew <ni...@webthing.com>.
On Monday 08 May 2006 14:56, Niklas Edmundsson wrote:
> On Mon, 8 May 2006, Jeff Trawick wrote:
> >> We should do better than leaving the users to rediscover and deal with
> >> regressions themselves, once we know there's a problem. Can I suggest
> >> an Errata page, to list *all* known regressions in current/recent
> >> versions, linked from the main page alongside "Download/New
> >> Features/Changelog"?
> >
> > +1
> >
> > [REGRESSION] in the changelog might be good too for permanent tracking.
> >
> > Most useful would be to ship a new version within a small amount of
> > time that corrects only regressions and has no other changes (if at
> > all practical; desire is to limit testing concern to speed up
> > delivery).
>
> The same goes for security issues. For apache 2.2.0 there was only a
> note that "the following issues are fixed in the development version"
> or something similar, not exactly what you want as an end user when
> you're affected by that particilar issue.
Agreed. An Errata page could have up to three subheadings:
* Security [known issues in current or near-current versions]
* Regressions [known issues where we broke something that worked before]
* Critical bugs [the most serious unpatched bugs from bugzilla,
as determined by us rather than some random bod who may or
may not have a clue].
> Either provide a patch, or provide a new version. Neither should be
> too difficult if you limit the scope to only fix the specific issue.
PR#37145 had a patch fairly quickly. But it wasn't adequately publicised,
so every other poor sod proxying with 2.0.55 had to struggle with
exactly the same thing. That's what we really should avoid.
Everything on the errata page needs a fix and/or a workaround.
So in the case of PR#37145 we'd have had "Apply the patch"
and "Downgrade to 2.0.54" as options.
--
Nick Kew
Re: Dealing with Regressions
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Mon, 8 May 2006, Jeff Trawick wrote:
>> We should do better than leaving the users to rediscover and deal with
>> regressions themselves, once we know there's a problem. Can I suggest
>> an Errata page, to list *all* known regressions in current/recent versions,
>> linked from the main page alongside "Download/New Features/Changelog"?
>
> +1
>
> [REGRESSION] in the changelog might be good too for permanent tracking.
>
> Most useful would be to ship a new version within a small amount of
> time that corrects only regressions and has no other changes (if at
> all practical; desire is to limit testing concern to speed up
> delivery).
The same goes for security issues. For apache 2.2.0 there was only a
note that "the following issues are fixed in the development version"
or something similar, not exactly what you want as an end user when
you're affected by that particilar issue.
Either provide a patch, or provide a new version. Neither should be
too difficult if you limit the scope to only fix the specific issue.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
I didn't do it nobody saw me you can't prove anything
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Dealing with Regressions
Posted by Jeff Trawick <tr...@gmail.com>.
On 5/8/06, Nick Kew <ni...@webthing.com> wrote:
> OK, we all know we get some embarrassing regressions in our new
> releases. PR#39490 in 1.3.35. Or 2.0.55 being effectively unusable
> in a proxy due to PR#37145. Look at the number of duplicates of
> 37145 - that's a lot of people with the confidence to report it,
> and who didn't find it 'cos it's marked as fixed (despite no fixed
> version being released until last week).
>
> We should do better than leaving the users to rediscover and deal with
> regressions themselves, once we know there's a problem. Can I suggest
> an Errata page, to list *all* known regressions in current/recent versions,
> linked from the main page alongside "Download/New Features/Changelog"?
+1
[REGRESSION] in the changelog might be good too for permanent tracking.
Most useful would be to ship a new version within a small amount of
time that corrects only regressions and has no other changes (if at
all practical; desire is to limit testing concern to speed up
delivery).
Re: Dealing with Regressions
Posted by Graham Leggett <mi...@sharp.fm>.
On Mon, May 8, 2006 1:36 pm, Nick Kew wrote:
> We should do better than leaving the users to rediscover and deal with
> regressions themselves, once we know there's a problem. Can I suggest
> an Errata page, to list *all* known regressions in current/recent
> versions,
> linked from the main page alongside "Download/New Features/Changelog"?
In theory, making the entries in Changelog in an easier-to-find location
(for example an Errata page as you suggest), coupled with some
release-early-release-often should help prevent this sort of thing.
Regards,
Graham
--
Re: Dealing with Regressions
Posted by Joe Orton <jo...@redhat.com>.
On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote:
>
> On May 8, 2006, at 7:36 AM, Nick Kew wrote:
>
> >OK, we all know we get some embarrassing regressions in our new
> >releases. PR#39490 in 1.3.35.
>
> That is an unexpected and unwelcome regression. If I had
> known about it I would have vetoed the patch. I'd be willing
> to actually release a 1.3.36 simply to address that.
I don't think any of this should be unexpected. All of the recent
1.3.x/2.0.x regressions I can think of have been caused by adding new
features. New features come at an increased risk of regressions - live
with it, or stop doing it! :)
joe
Re: 1.3.35 status: Was: Re: Dealing with Regressions
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>
> In any case, this is notice that I will be RM for 1.3.36
Thanks for voulenteering :)
My point in the earlier thread is that I'll make a 1.3.36 binary for
windows, leave it on the mirror for three days. But will then pull
down that binary, and notes about 1.3, leaving users to look
>>> over there if they want to download this flavor for windows in
particular. I think folks know I'm not an anti-1.3 bigot, but the
bugs remaining in httpd 1.3 windows are either beyond solving, or
will never get the attention, and we have a supported solution.
Bill
1.3.35 status: Was: Re: Dealing with Regressions
Posted by Jim Jagielski <ji...@jaguNET.com>.
There are several bug reports due to the updated Include
code (eg: 39490, 39513 and 39516). Looks like we got bitten
by what we usually get bitten by: last minute updates :(
My plan is that we release 1.3.36 very soon to address this.
I'd prefer a fix that (1) doesn't replicate lots of code
and (2) causes no more regressions, but if that takes
too much time, I will simply release 1.3.36 with the reverse
applied.
I will see what I can come up with.
In any case, this is notice that I will be RM for 1.3.36
Re: Dealing with Regressions
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
+1 here as well, but could you attach this to both bugs and get confirmation
that the double-free and wildcards again act as expected for our reporters
after applying the patch?
Bill
Jim Jagielski wrote:
> I'd prefer just fixing the regression and keeping
> both behaviors :)
>
> +1
>
> On May 8, 2006, at 10:45 AM, Colm MacCarthaigh wrote:
>
>> On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote:
>>
>>> That is an unexpected and unwelcome regression.
>>
>>
>> Yep, my bad, I never had such a block in my testing largely because I
>> didn't even know 1.3.x had that feature, *sigh*, it's not even
>> documented and I can't see it in a changelog and it didn't have that
>> functionality when I first wrote that patch.
>>
>>> If I had known about it I would have vetoed the patch. I'd be willing
>>> to actually release a 1.3.36 simply to address that.
>>
>>
>> Patch attached, courtesy of Matthijs van der Klip. Or simply revert the
>> whole change.
>>
>> --
>> Colm MacCárthaigh Public Key: colm +pgp@stdlib.net
>> <apache_1.3.35-include.patch>
>
>
>
> .
>
Re: Dealing with Regressions
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'd prefer just fixing the regression and keeping
both behaviors :)
+1
On May 8, 2006, at 10:45 AM, Colm MacCarthaigh wrote:
> On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote:
>> That is an unexpected and unwelcome regression.
>
> Yep, my bad, I never had such a block in my testing largely because I
> didn't even know 1.3.x had that feature, *sigh*, it's not even
> documented and I can't see it in a changelog and it didn't have that
> functionality when I first wrote that patch.
>
>> If I had known about it I would have vetoed the patch. I'd be willing
>> to actually release a 1.3.36 simply to address that.
>
> Patch attached, courtesy of Matthijs van der Klip. Or simply revert
> the
> whole change.
>
> --
> Colm MacCárthaigh Public Key: colm
> +pgp@stdlib.net
> <apache_1.3.35-include.patch>
Re: Dealing with Regressions
Posted by Jim Jagielski <ji...@jaguNET.com>.
What I did is reversed #396294... this keeps HEAD
in a non-regressed state and gives us time to
come up with a full fix.
Re: Dealing with Regressions
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Mon, May 08, 2006 at 03:45:21PM +0100, Colm MacCarthaigh wrote:
> Yep, my bad, I never had such a block in my testing largely because I
> didn't even know 1.3.x had that feature, *sigh*, it's not even
> documented and I can't see it in a changelog and it didn't have that
> functionality when I first wrote that patch.
Turns out it is documented. I should have caught it from inspection
anyway.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Dealing with Regressions
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote:
> That is an unexpected and unwelcome regression.
Yep, my bad, I never had such a block in my testing largely because I
didn't even know 1.3.x had that feature, *sigh*, it's not even
documented and I can't see it in a changelog and it didn't have that
functionality when I first wrote that patch.
> If I had known about it I would have vetoed the patch. I'd be willing
> to actually release a 1.3.36 simply to address that.
Patch attached, courtesy of Matthijs van der Klip. Or simply revert the
whole change.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Dealing with Regressions
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 8, 2006, at 7:36 AM, Nick Kew wrote:
> OK, we all know we get some embarrassing regressions in our new
> releases. PR#39490 in 1.3.35.
That is an unexpected and unwelcome regression. If I had
known about it I would have vetoed the patch. I'd be willing
to actually release a 1.3.36 simply to address that.