Re: Lots of bug fixes; possible release

[Julian Foad]

Charles Levert wrote:
> * On Thursday 2005-11-03 at 21:20:59 +0000, Julian Foad wrote:
>
> > Charles Levert wrote:
> >
> > > 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.  [...]
> >
> > [...]  I suppose in the course of your 
> > work on the above bugs, you have implicitly accepted the correctness of 
> > these Red Hat patches, [...]

I misunderstood you.  I thought you meant your bug fixes rely on these Red Hat 
patches (and the gnulib regex), but from your reply I see that by "to get other 
things right" you meant bugs other than the ones for which you have written 
fixes.  My thoughts, like "that would be a good place to start" and that we 
should release before making your fixes, were based on that misunderstanding 
and are no longer valid.

> 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).

That's fine.

> 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.

Yes.  We can leave these till later.

> 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.

OK.

> > 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).

Yes.  The reason I suggested the branch is because I thought we were talking 
about a large code churn - like ripping out lots of our own regex code and 
replacing it with gnulib - which might destabilise Grep (i.e. introduce bugs) 
for quite a while.  If we're not doing very large changes like that - or if we 
think we can manage that particular change well enough to avoid the trunk being 
unstable for a long time - then we don't need a branch.

> 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.

Yes.

- Julian