Greg Stein <gstein@lyra.org> writes:
> > it will be like:
> > - beta with the mentioned and
> > 0.17 issues fixed
>
> As I mentioned in my other note, it seems the dev group's feeling is that
> beta needs to be more solid than that.
>
> [ I can speak clearly for the CollabNet folks, but I'm only guessing on the
> feelings for people like Brane, Philip, Garrett, etc etc etc etc etc.
> (dang there are a lot of them :-) ]
I *can* speak for Philip :)
My interest in Subversion is making it do what I want, within the
limits acceptable to the other developers. At the moment I don't care
when 1.0 is released as it doesn't affect me. That attitude could
change, if the non-release of 1.0 were to block some feature I want,
or if some other force gave me an interest in having a 1.0 release.
Until then I don't have much interest. Selfish? Yes, but then I
don't develop Subversion for other people.
> > - no new features or architectureal
> > changes in the 1.0 branch
>
> As I said, we aren't doing that now, as far as we can avoid it. Small stuff
> still slips through, but it is usually done with a thought towards "is this
> destabilizing." The last big feature was Greg Hudson's ra_svn, but that
> didn't impact any existing code, so it was deemed "quite fine".
>
> > - 1.0 after 1-2 month beta
>
> That's the plan, yah. But where beta is effectively "no known bugs".
That goal may not be possible, or even important. I'm probably only
repeating stuff you already know, but here it is anyway.
Consider the difference between "known bugs" and "total bugs". Unless
an extreme amount of testing is carried out (far more than I believe
Subversion gets) then the known bugs will be a subset of the total
bugs. Even if we were to release with no known bugs it is probable
that the release will still contain bugs, and some of these bugs may
well become "known" after the release. Just because we managed to
release when the fluctuating number of known bugs was zero doesn't
automatically mean that the release has a higher quality (i.e. fewer
total bugs) than a release made earlier or later.
What is important is that the release works well enough, where well
enough includes both knowing that certain things work correctly, and
considering the impact of each known bug. It is possible to release
with a large number of known bugs, if those bugs are deemed to be
unimportant, and it is also possible for any one of the known bugs to
block the release.
If that's what you meant by "effectively", well then at least I've
explained it to the others :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 6 22:31:15 2003