Please start a release branch (was: CVS 1.11.5 Released <strong>(Security Update)</strong>)

[Paul Edwards]

"Larry Jones" <lawrence.jones@eds.com> wrote in message 
news:mailman.704.1043168238.21513.bug-cvs@gnu.org...
> Paul Edwards writes:
> >
> > Can you tell me whether these bugs are generally being introduced
> > by enhancements, or whether they are long-standing bugs, recently
> > uncovered?
>
> What do you mean by "these" bugs?  This particular bug seems to have
> existed since at least 1997.

What percentage of bugs, or reported problems, in the last
year, have been due to bugs that have been undiscovered for
over 2 years.

What's your gut feel?

If the percentage is high, e.g. 90%, no worried, the current
regimen is as good as it gets, there's just quite a number of
bugs, and they are so obscure that it has taken so long for
them to come to the surface, and cvs as a whole is getting
more and more stable every release, which is wonderful.

> > I was wondering if rather than every release replacing one set
> > of bugs with another set of bugs, we could have a particular
> > version (maybe starting with 1.11.5), which will be continually
> > updated, with bug fixes only, even when version 1.14.17 has
> > just been released.
>
> In case you haven't noticed, the vast majority of the changes to CVS in
> the last few years have been bug fixes.

If that were the case, then there shouldn't be new problems being
introduced with each release.

Not sure about the last few years, but cvs 1.10 is a 700k
executable for me on Solaris.  cvs 1.11.5 is 2.3 meg.  Both
stripped.

The sort of problems I have seen personally, are:

1. Incorrect Makefile linking with some security library which
wasn't installed.  Switching to --disable-client --disable-server
got around that.  The security library was a presumed
enhancement.

2. --disable-client --disable-server stopped working.  But by
this stage the above Makefile had been fixed, so switching
off these options got around that (for a slightly bigger executable).
The code causing the problem has since been corrected, but it
was obviously introduced between 1.11 versions, ie a presumed
enhancement.  So one problem replaced by another problem, not
a move to stability, in fact, worse, because it required some
action to find the workaround to the workaround not working
around.

3. Procedure for compiling changed.  After having been
./configure for x years, I now needed to run noautomake, or else
I got some error.  Another "enhancement" that could have been
in 1.12 instead of being introduced between sub-versions of 1.11.

Another problem someone else was having with the Windows
executable of 1.11.1p1 or somesuch.  Something about userid
not being known.  I did a search and found the fix was to fall
back a version.  IIRC that was caused by the release distribution
having been compiled incorrectly.  Still a step backwards for
stability for the end-user.  I think a new release should have
been put out the next day.  If there were only bug fixes in the
cvs1.11.* stream, there should be no inhibition to putting out
an impromptu release.  No coordination is required, no time
for "settling in" of enhancements just submitted, which obscure
the pure bug fixes.

Then e.g. there is that bug which I saw you fix of another windows
user, ndbm or something.  It sounded like it only affected them
because they updated to the latest greatest version, as opposed to
the most stable version.  The result of another enhancement?

So are 90% of the end-user problems attributable to the fact
that an enhancement being made, or are they due to long
dormant bugs awakening?  What is the % breakdown?

Because at the moment, whenever I get a new drop of CVS,
my heart stops beating as I wonder whether it will even
compile on my system.  I basically expect to be hit with
some enhancement that is so fundamental it doesn't even
allow me to compile.  I currently have no expectation that
when I go from 1.11.3 to 1.11.4 I will go from strength to
strength, I instead have an expectation that I will be
replacing one set of bugs with an equal number of bugs.

I can understand that going from 1.11.5 to 1.12.0 I should
expect to get new bugs.  But going from 1.11.3 to 1.11.4
I don't expect to get any bugs that I don't already have.
My heart is in my mouth whenever I run the new version,
as I have no confidence that it is a step up in stability.

Every single release says "some serious bugs were
fixed, including data loss, we recommend an upgrade".
I was hoping for a release that said "Well, we haven't
found any bugs for a long time now, so we've decided
to add a swag of features".  Then I will stick with that
release that hasn't had any bugs found in it for a long
time now.

> I can't think of any major new
> features that have been added, just a few small ones.

If the small features aren't introducing a plethora of bugs,
all is fine.  So long as 10 bugs get swatted for every 1
bug introduced, that would be reasonable, as it means
we're on the track to stability.  At the moment I can't even
see the track.  This is just my personal experience.  Maybe
I'm the odd one out.  Maybe I'm the one who experiences
the 1 bug introduced for 10 swatted.

Normally I recommend people use branches to solve this
problem.  Normally I recommend people install CVS, and
set up branches, to solve this problem.  I patiently explain
the joys of using cvs update -j, to lift bug fixes from the
bug-fix branch and automatically apply them to the
development branch.  Normally I explain how CVS is the
best thing since sliced bread, branches and 3-way diffs are
one of the greatest advances in computer science.  It is
strange that CVS development itself never felt the need to
use its own technology on itself.

I would like to see a period of 1 year where there have been
ZERO bugs found on the latest version, on every platform.
When that stage is reached, it's time to declare it stable and
release a new set of enhancements and bugs.  Currently the
latest release isn't even lasting one day without a bug report,
nevermind a year.

Just a suggestion.  I really do love CVS, it's just I put myself
out on a limb by introducing it to a foreign company,
promising it will fix their source control problems, while
at the same time praying to the gods that it will even compile.
So a stable version that no-one has found a bug in for a
year, and advertised as such, would be wonderful.  Dare
people to find a bug.  xxx days with no bug reports.

BFN.  Paul.