bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Applying outstanding patches [bug-grep]


From: Charles Levert
Subject: Re: Applying outstanding patches [bug-grep]
Date: Wed, 13 Apr 2005 22:00:01 -0400
User-agent: Mutt/1.4.1i

* On Wednesday 2005-04-13 at 20:10:41 +0200, Claudio Fontana wrote:
> 
> --- Julian Foad <address@hidden> wrote:
> > I have finally got around to spending some time on
> > Grep, and have started by 
> > going through the issues in the Savannah tracker and
> > resolving those that are 
> > easy to resolve.  This includes applying patches
> > that are simple and/or 
> > testable and that won't get in the way of applying
> > some of the larger patches 
> > that are waiting.
> > 
> > Stepan Kasal wrote: "Our main goal for grep 2.5.2 is
> > to get sane performance 
> > with utf-8."  While that is an important issue, my
> > main goal for the short term 
> > is to fix as many correctness bugs as can be fixed
> > without making very large 
> > (and therefore inherently dangerous) changes.
> 
> I would suggest freezing the Red Hat UTF8 speedup
> patch. I studied it with attention and it addresses a
> real performance problem, but I think it needs some
> restructuring to avoid code dups, and generalize some
> functionality in appropriate functions to be more
> maintenable in the future.

Here's my 0.02 CAD.

I think that, given the current freeze we've
been in for some time, any motion (not even
necessarily proven progress) is good and we
should go ahead and apply the long-in-waiting
Red Hat patches.

Remember the obvious (IMHO):

  -- CVS is supposed to be bleeding edge and
     anybody who downloads it should know
     what they're getting themselves into.
     Users should look in the official releases
     for stability.

  -- It's even ok to break the CVS build, as long
     as it's detected and fixed within a few
     hours.

  -- Things that build don't have to be perfect
     the moment they enter CVS.  There are
     several ways to correct them afterwards:

     -- by incremental improvements that build
        upon the first commits;

     -- by first backing out of commits that
        turned out to have been unequivocal
        mistakes after having received some
        testing, and then applying newer cleaner
        patches from scratch based on gained
        experience.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]