You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1998/07/10 03:07:43 UTC
Re: cvs commit: apache-1.3/src/modules/standard mod_setenvif.c
On 10 Jul 1998 coar@hyperreal.org wrote:
> coar 98/07/09 17:54:18
>
> Modified: src/modules/standard mod_setenvif.c
> Log:
> Yes, I know this is style-guide/indent stuff, but I'm tracking down
> a possible bug and want to have a clean basis for any changes. I.e.,
> I'm not just being capricious..
It's not about being capricious.
It's about folks who try to maintain patch sets against the base code.
For example: the SSL patch set. apache-nspr. The dozen or so
performance and other tweaking patches referenced off www.apache.org. Any
"contrib"/suspended patches sitting in the bugdb. Untold others.
Every time you make one of these damn changes you potentially fuck those
up *FOR ABSOLUTELY NO GOOD REASON*.
I'm sorry, but I just do not agree with this. Everyone had their chance
to do style guide crap ages ago. That time is past. We can let it come
again when we've got 1.3.x stabilized -- such that we're not trying to
pull changes into apache-nspr.
If a patch breaks because someone fixed a bug in the area of the patch,
then that's fine. That's expected. But it's just wrong to force people
to have to hand patch every single minor revision.
Am I the only one that thinks this way? If you want the joy of dealing
with this crap then I suggest you try the next merge of 1.3.1 into
apache-nspr. You'll be cursing these changes just like me in no time.
Dean
Re: cvs commit: apache-1.3/src/modules/standard mod_setenvif.c
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodent of Unusual Size wrote:
>
> Ben Laurie wrote:
> >
> > BTW, if Ken needs to have it formatted a certain way to fix a bug,
> > surely he can format it, track the bug down, blow away the formatting
> > changes, then fix the bug? Or even fix it twice (after all, all he
> > needs to do is take a diff, blow away the formatting changes, then
> > apply the diff. What's that you say? The diff won't apply? Oh, well,
> > blow me down...).
>
> Fer crying in yer beer..!
>
> There has been enormous yammer about "don't mix cleanup with fixes."
> Fine, so I don't. But if you don't want cleanup AT ALL, then
> bloody well say so! (Not you, Dean; you've expressed yourself
> loud and clear. ;-)
I'm not sure whether I do or not, I'm just agreeing that it causes pain
for people who maintain patches against the source. Whether that's a
good enough reason to not do it, I dunno. Particularly since there are
always people with patches against the source, so it would seem there's
never a good time to do cleanup. OTOH, it causes less distress during
betas than during releases.
Of course, I'm no major fan of cleanup because my Index of Unhappiness
is the biggest (for those who missed the style guide construction, this
was a measure of how far away the style guide is from each person's
personal preference), so cleanup doesn't noticably improve readability
for me, in general.
> Many of the changes will disappear as the fluff they are if you
> diff with -b. But you all knew that, and it doesn't address the
> bracketisation cleanup issue at all, granted.
>
> As for the semi-relevant argument about 'it should have been
> done months ago' - true. I have no idea why http_core resembled
> the pile of ordure it did re the indent effort. I feel good enough
> about that bit of cleanup that I'll cut it out for now. But only
> out of respect and consideration for people, not because I think it's
> a Good Thing to leave the code uncleaned.
I guess if a piece of code is going to get substantially changed, it may
as well get cleaned, too (as two patches, of course), coz any patches
against it will be bust anyway.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: cvs commit: apache-1.3/src/modules/standard mod_setenvif.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Laurie wrote:
>
> BTW, if Ken needs to have it formatted a certain way to fix a bug,
> surely he can format it, track the bug down, blow away the formatting
> changes, then fix the bug? Or even fix it twice (after all, all he
> needs to do is take a diff, blow away the formatting changes, then
> apply the diff. What's that you say? The diff won't apply? Oh, well,
> blow me down...).
Fer crying in yer beer..!
There has been enormous yammer about "don't mix cleanup with fixes."
Fine, so I don't. But if you don't want cleanup AT ALL, then
bloody well say so! (Not you, Dean; you've expressed yourself
loud and clear. ;-)
Many of the changes will disappear as the fluff they are if you
diff with -b. But you all knew that, and it doesn't address the
bracketisation cleanup issue at all, granted.
As for the semi-relevant argument about 'it should have been
done months ago' - true. I have no idea why http_core resembled
the pile of ordure it did re the indent effort. I feel good enough
about that bit of cleanup that I'll cut it out for now. But only
out of respect and consideration for people, not because I think it's
a Good Thing to leave the code uncleaned.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: cvs commit: apache-1.3/src/modules/standard mod_setenvif.c
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On 10 Jul 1998 coar@hyperreal.org wrote:
>
> > coar 98/07/09 17:54:18
> >
> > Modified: src/modules/standard mod_setenvif.c
> > Log:
> > Yes, I know this is style-guide/indent stuff, but I'm tracking down
> > a possible bug and want to have a clean basis for any changes. I.e.,
> > I'm not just being capricious..
>
> It's not about being capricious.
>
> It's about folks who try to maintain patch sets against the base code.
>
> For example: the SSL patch set. apache-nspr. The dozen or so
> performance and other tweaking patches referenced off www.apache.org. Any
> "contrib"/suspended patches sitting in the bugdb. Untold others.
>
> Every time you make one of these damn changes you potentially fuck those
> up *FOR ABSOLUTELY NO GOOD REASON*.
>
> I'm sorry, but I just do not agree with this. Everyone had their chance
> to do style guide crap ages ago. That time is past. We can let it come
> again when we've got 1.3.x stabilized -- such that we're not trying to
> pull changes into apache-nspr.
>
> If a patch breaks because someone fixed a bug in the area of the patch,
> then that's fine. That's expected. But it's just wrong to force people
> to have to hand patch every single minor revision.
>
> Am I the only one that thinks this way? If you want the joy of dealing
> with this crap then I suggest you try the next merge of 1.3.1 into
> apache-nspr. You'll be cursing these changes just like me in no time.
Yes, I agree. Looking at why Apache-SSL patches fail to apply is bad
enough without having to deal with whitspace/rearrangement differences.
BTW, if Ken needs to have it formatted a certain way to fix a bug,
surely he can format it, track the bug down, blow away the formatting
changes, then fix the bug? Or even fix it twice (after all, all he needs
to do is take a diff, blow away the formatting changes, then apply the
diff. What's that you say? The diff won't apply? Oh, well, blow me
down...).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: cvs commit: apache-1.3/src/modules/standard mod_setenvif.c
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Thu, 9 Jul 1998, Dean Gaudet wrote:
> For example: the SSL patch set. apache-nspr. The dozen or so
> performance and other tweaking patches referenced off www.apache.org. Any
> "contrib"/suspended patches sitting in the bugdb. Untold others.
>
> Every time you make one of these damn changes you potentially fuck those
> up *FOR ABSOLUTELY NO GOOD REASON*.
[...]
> Am I the only one that thinks this way? If you want the joy of dealing
> with this crap then I suggest you try the next merge of 1.3.1 into
> apache-nspr. You'll be cursing these changes just like me in no time.
I agree with Dean in practice, but not in principle: It seems to me
silly to disallow changes to our code base just because someone,
somewhere, might (okay, okay, does) have patches that they apply against
the source that those changes would screw up. If it is necessary to apply
patches to the source code of a product to add desired functionality, then
that product's public API is faulty.
As a practical matter, however, that's baloney, especially for Apache 1.3,
since there are known functionalities that cannot be accomplished within
the API framework, and there are known collections of major patches to the
source to acheive these (Apache-SSL, etc...), so it makes sense not to
change the source without good cause (although one could make the argument
that style is good cause.)
It is, however, a good reason to make sure the 2.0 API is a good one.
"Introducing the server so perfect, you don't have to patch it. In fact,
we're not going to give you source code, so you can't screw it up. Well, I
guess if you *really* wanted the source code, you could have it. For
$5,000,000. And you can't give it to anyone. And if you make any changes,
we get to keep them and use them however we want."
(from the release announcement of Microsoft Apache; Dec 1, 1999)
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *