Re: Lots of bug fixes; possible release

[Charles Levert]

* On Thursday 2005-11-03 at 21:20:59 +0000, Julian Foad wrote:
> Charles Levert wrote:
> >
> >What I have solved:
> 
> Excellent.  I'm very impressed with your continuing work on this, Charles.

Thanks.


> >   -- The "egrep" and "fgrep" script vs. program
> >      situation.  I have a solution with programs
> >      (no scripts or argv[0]-recognition)
> >      where those two are smaller than the full
> >      featured "grep", yet still standalone
> >      (much smaller for "fgrep", which doesn't
> >      use the dfa or regex stuff).
> 
> That's historically been a touchy subject, but I like the sound of your 
> solution.  I think it is acceptable that "fgrep" wouldn't support "-E" or 
> "-G", and "egrep" wouldn't support "-F" or "-G".

That's exactly what I have done (my "egrep"
and "fgrep" don't recognize -G, -E, -F, -P, or
-X at all), plus customized the --help message
of each program to explain what's going on and
what usages are deprecated.  Invoking "egrep -G"
cannot be justified by legacy practices anyway.
Although this adds a few preprocessor defines,
it also makes clearer what program/mode uses
what in the code.

In previous discussions, we already remarked that
distributors can always elect to use a different
solution in their product (such as a script-based
one), but that this is then _their_ burden.


> I'd love to get them applied soonish, but whether it is reasonable "at this 
> point in time" depends on how complex they are.

Hopefully, I can make them as orthogonal as
possible to other issues.


> >What I rely on to get other things right:
> >
> >   -- The remaining stuff from the
> >      Red Hat/Fedora Core patches.
> 
> That would be a good place to start.  Last time I looked, I was unable to 
> determine whether and why some of those remaining patches correctly fixed 
> what they claimed to fix, or in some cases unable even to determine what 
> they claimed to fix.
> 
> If you are prepared to re-submit those patches in a clearly understandable 
> form, then I'll undertake to review them.  I suppose in the course of your 
> work on the above bugs, you have implicitly accepted the correctness of 
> these Red Hat patches, but I will not be happy for us to apply them if they 
> are not understandable.

Assuming it is orthogonal, I'd rather commit the
work I did myself because it is simpler in scope,
and because I necessarily understand it better
and can defend its correctness (or else fix any
valid issues with it).

I can observe that the RH/FC patches don't break
existing tests, but that's not a total proof of
correctness.  I can also observe that they live
up to their promised performance improvements.
But, as Claudio Fontana pointed out a few months
back, some of it is ugly and repetitive, and
could stand up to be tightened.


> >   -- The regex stuff that's in gnulib CVS.
> 
> Yikes - that's quite a big change, is it not?  Still, I accept that we need 
> to do it some time soon.

Again, hopefully orthogonal and doesn't break
existing tests.  (Well, it does break one Spencer
test, but that test's expected exit code is
what's incorrect.)

In both cases (RH/FC and gnulib/regex), if I
don't at least try them in my personal copy,
then I won't have the opportunity to find any
obvious issues with them.


> I know there is a significant amount of work in making a release, but I 
> could do some of it with guidance.  Although it's been years since the last 
> one, and that fact would seem to make another few months unimportant, I 
> think we might get into a real mess and much bigger delay if we start to 
> make drastic changes to the source and then find unforseen difficulties 
> without having released a stable version beforehand.
> 
> Would you be prepared to help with such a release before applying all your 
> good bug fixing work?

Making a release requires knowledge.
Not general knowledge, but more the arbitrary
customs of the GNU project regarding this.
(This isn't meant as criticism in the least;
all projects/companies/etc. have them.)  So I
have been looking forward to such a release for
a long time, if only for its value to me as a
learning/accustoming experience.  This way, the
next time I find a release too long in coming, I
will be able to say "why don't you let me handle
it, you now can trust that I know the drill".

At the moment, since I can't undertake a release
on my own, I'd rather not stop doing bug fixes,
but I am holding any new feature proposal.


> Alternatively, could we at least create a "version 2.5.x" bug-fixing branch 
> from the current CVS code, and then continue developing the mainline 
> (trunk) as heading towards version 2.6?  I'm not really keen to work with 
> branches in CVS, but it would be better than just continuing with ever 
> bigger changes.

To me, there aren't any pending new features
(not bug fixes) that are experimental in their
very existence to justify this.  Much of what we
are doing is plain bug fixing, plus filling out
missing specifications on the exact behavior of
already introduced GNU extensions (another form
of bug fixing, in a feature-interaction way).

Creating another branch would just further
add to a workload that isn't being handled.
Branches do have to be kept synchronized for
common bug fixes.