[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Compressed streams (take 2)

From: Eric Dorland <eric.dorland_at_mail.mcgill.ca>
Date: 2003-04-01 06:12:51 CEST

* Greg Stein (gstein@lyra.org) wrote:
> On Tue, Apr 01, 2003 at 01:29:42AM +0100, Philip Martin wrote:
> > Eric Dorland <eric.dorland@mail.mcgill.ca> writes:
> >...
> > > It's probably
> > > not worth it though. But hey, if it gets my patch in, I'll do it :)
> >
> > I'm not trying to be awkward, I'm just trying to understand the patch
> > without going to the trouble of reading the zlib documentation.
> How about a slight change in approach here?
> * is the concept useful and applicable? do we really want this feature?

I like to think so :)

> * is the current code "close enough"? can the tweaks be made to the code
> after it has been applied?

> My concern here is that if we ask patch submitters to tweak a nit here, and
> tweak a nit there, each coming in at different times as different reviewers
> find time to look at the code, that eventually the submitter will just throw
> their hands up in the air and go away.

I'm not about to walk away, but I think you do have a point here...
> Now, I'm not saying "apply bad patches and fix them later." But I am saying,
> "can we alter the buffer size after the code is in?" or "can the data
> generation occur after the code is in?" It would seem that neither of those
> is fundamental to having the code added such that people can begin to
> exercise it in new ways.

Well hopefully my next patch will basically satisfy everyone.

Eric Dorland <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 

  • application/pgp-signature attachment: stored
Received on Tue Apr 1 06:13:52 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.