Mailing List Archive

0.5 distribution --- problems with B57.
When I was doing my usual round of tests on 0.5 prior to installing it
on port 80, I noticed some problems. It turns out that patch B57 (the
unmunge cleanup) introduces several new bugs ---

*) The SCRIPT_NAME CGI variable is set incorrectly if the script
gets PATH_INFO

*) Likewise for DOCUMENT_URI in code invoked from server-side includes

*) Automatically generated redirects for directories break (sorry,
Rob, not without a formal bug-ID).

*) [I believe] Some error messages for MultiViews come out broken.

What these all have in common is that some modified variant of the
translated name is being unmunged, with the expectation that the
result will be the original URL modified in the corresponding
fashion (and not an unmodified copy of it).

Backing out of B57 cures all of the above, and I've now put 0.5, as
de-amended, up on www.ai port 80. Just thought other people would
like to know. (I think we need to either fix this right or back it
out --- the old behavior was indeed subtly buggy, but given the choice
between those bugs and these bugs, the former are, IMHO, easier to
live with).

rst
Re: 0.5 distribution --- problems with B57. [ In reply to ]
> Backing out of B57 cures all of the above, and I've now put 0.5, as
> de-amended, up on www.ai port 80. Just thought other people would
> like to know. (I think we need to either fix this right or back it
> out --- the old behavior was indeed subtly buggy, but given the choice
> between those bugs and these bugs, the former are, IMHO, easier to
> live with).

Oh bum. I've upped a patch which reverses B57.

back where we started.
Re: 0.5 distribution --- problems with B57. [ In reply to ]
> > Backing out of B57 cures all of the above, and I've now put 0.5, as
> > de-amended, up on www.ai port 80. Just thought other people would
> > like to know. (I think we need to either fix this right or back it
> > out --- the old behavior was indeed subtly buggy, but given the choice
> > between those bugs and these bugs, the former are, IMHO, easier to
> > live with).
>
> Oh bum. I've upped a patch which reverses B57.
>
> back where we started.

I've upped an alternative fix. This new one makes the translate()
function remember which alias it used, later the unmunge() uses that
remembered value instead of cycling through all the aliases.

robh
Re: 0.5 distribution --- problems with B57. [ In reply to ]
>
> Having seen all these messages about B57 etc., here are my votes
> B57: -1 in fact, -1 on _any_ change to unmunge_name().

Having seen the "messages"... did you check the latest patch for B57 ?
I'd rather have see a good reason why this patch is wrong, than just
an outright veto on anything which touches unmunge_name()

> Can you please please rebuild 0.5 without B57?

I won't unless the majority ask for it. We have a system (voting etc)
which works reasonably well. If 0.5 is so bad, we can replace it with
a 0.6 or 0.5.1 pretty quickly, and long before next weekend.

robh
Re: 0.5 distribution --- problems with B57. [ In reply to ]
> > > Backing out of B57 cures all of the above, and I've now put 0.5, as
> > > de-amended, up on www.ai port 80. Just thought other people would
> > > like to know. (I think we need to either fix this right or back it
> > > out --- the old behavior was indeed subtly buggy, but given the choice
> > > between those bugs and these bugs, the former are, IMHO, easier to
> > > live with).
> >
> > Oh bum. I've upped a patch which reverses B57.
> >
> > back where we started.
>
> I've upped an alternative fix. This new one makes the translate()
> function remember which alias it used, later the unmunge() uses that
> remembered value instead of cycling through all the aliases.
>
> robh

Having seen all these messages about B57 etc., here are my votes
B57: -1 in fact, -1 on _any_ change to unmunge_name().

Can you please please rebuild 0.5 without B57?

Attempting to get unmunge_name() fixed is just the wrong way of doing things.
Its the IBM way; a complicated thing doesn't work, so try to introduce
an even more complicated solution, instead of starting again. (example: MVS/XA)
I'm not convinced that your latest patch will work; translate_name() could
be called several times with different ~users values by http_include.c.
The best solution is to try to remove unmunge_name() in the long term, and
in the short term to live with its bugs. Attempting to fix them is simply
a waste of time.

+1 to everything else you've currently got in 0.5.

I need to fix B59 and B60, and -1 on E55 and O58.

David.
Re: 0.5 distribution --- problems with B57. [ In reply to ]
+1 on 0.5.1 without B57, for two reasons. One is that it's useful to
be able to download a release and run it without having to fuss with it
any; the other is that a 0.5.1 like that would be something we could
give out as a prerelease in reasonably good conscience (aside from the
bugs introduced by B57, it has no major bugs that I'm aware of).

rst
Re: 0.5 distribution --- problems with B57. [ In reply to ]
>
> >We have a system (voting etc) which works reasonably well.
> So I don't feel as though I can agree, of late, at least for me in the UK
> timezone. Voting seems to start after I've gone home on Friday, and finish
> before I've woken up on Saturday (afternoon 8-( ). Yes, I could vote on
> Thursday or Friday morning (your time) but then I miss some late additions.
> I'm not sure what to suggest though, except maybe a deadline for patch
> submission late Thursday (PST) so that I can be sure to see the patches
> on Friday.

Okay, let's try not to vote on anything submitted with a datestamp
after thursday. Nobody should feel obliged to vote for something
uploaded after that date, but everyone is welcome to vote for whatever
they like, provided they have had a chance to test it.

All votes in by Friday by default. Anything later is subject to being
ignored.

robh
Re: 0.5 distribution --- problems with B57. [ In reply to ]
>We have a system (voting etc) which works reasonably well.
So I don't feel as though I can agree, of late, at least for me in the UK
timezone. Voting seems to start after I've gone home on Friday, and finish
before I've woken up on Saturday (afternoon 8-( ). Yes, I could vote on
Thursday or Friday morning (your time) but then I miss some late additions.
I'm not sure what to suggest though, except maybe a deadline for patch
submission late Thursday (PST) so that I can be sure to see the patches
on Friday.

This isn't really a complaint, certainly not directed at RobH who is doing the
work of building the distributions (thanks Rob..).

David.