Community input for Alpha

[Greg Stein <gs...@lyra.org>]

Hey all,

As I'm sure you're all aware, "us CollabNet guys" have been setting the
milestones for a long time now. Mostly, I'd like to think that is for
several reasons:

  1) we're more structured, due to this being an actual job for us
  2) the milestones have seemed fine, so nobody has fussed
  3) we set 'em, you hate 'em, but you suffer it silently :-)
  4) we put in the most time, so you let us steer
  5) we've garnered the respect to assume a higher leadership role
  6) etc


Whatever the reason, and it will be quite varied, we are fast approaching an
Alpha release, and I think that impacts the entire community. As a result,
I'd like a little more active input from people on what will comprise the
Alpha release. This is your project, too, and if we are going to put a big
old label on the front of the code, I would much prefer that it happens with
the broad consent of the community.

So. What do I mean by Alpha?

  "All major features, necessary to accomplishing the tasks you would expect
   Subversion to accomplish, have been completed enough to be functional for
   the majority of use cases."

The converse point of view is that:

  * edge cases for features may not be implemented
  * bugs exist, but do not hamper the primary use cases
  * some minor features may not be implemented (e.g. ~/.subversion/options)

The Alpha release is intended for actual use scenarios.

One more point of contrast is "what would a Beta be?" We're currently
defining Beta as:

  "We don't know of any bugs that prevent the use of Subversion. As far as
   we're concerned it is at a release quality level, but we want to be
   conservative and get some shakedown first. [especially as a high
   confidence level is required for a version control system]"


I am hoping that we at least have basic agreement on the terminology and
approach. Otherwise, we've got quite a bit more discussion to do first :-)

[ a bit more background, then I'll get into my plea for the community ]

Just now, I rejiggered our issue database to shift all the "bite-sized"
milestone issues to "real" milestones. All the bite-sized issues are now
noted as such using IZ's "keywords" facility. I've set up a canned query
called "bite-sized" which you can use, you can simply hit the link off the
"Tasks" page on the web site, or just query it yourselves. But the big (and
somewhat scary) effect is to show just how many issues fall into the Beta
milestone and then the 1.0 milestone.

Second, I enabled "voting" for the issues. Each person will get three votes
for the issues that they feel are important. When you visit an issue, there
is now a link for voting for that issue.

Lastly, the issues currently listed as "Alpha" do not seem to be things that
would prevent an Alpha, by the above definition, so we are thinking of
moving these to the Beta milestone. This would actually mean that our Alpha
release would occur after the "pre-alpha" issues have been addressed.


What I'm currently seeking from the community is three things:

1) Agreement on the above definitions for alpha, beta, and the implied
   release-quality strategy.

2) Agreement on shifting the current Alpha bugs to beta, the current
   pre-alpha bugs to Alpha, and releasing Alpha when they are fixed.

3) Spend your three votes on items which you believe should be fixed by an
   Alpha release. These can be on any issue, even those currently slated for
   fix-by-(pre)Alpha (to ensure we don't *un*schedule them). Based on the
   voting, we'll review and possibly rejigger what goes into Alpha.


Of course, item (3) is about the *work* that needs to be completed for
Alpha. PLEASE remember that we'll be scheduling only what we think that we
(the CollabNet boys) can accomplish in a reasonable timeframe. If your
favorite issues don't get scheduled for Alpha, then you can still do the
work yourself (or lobby others here to do it). Scheduling is more about
who-does-what than a definitive statement about what is in, or what is
excluded.

Note that there isn't a real cutoff for end-of-voting, as we'll be reviewing
periodically. In particular, I'm in Chicago again next week, and we'll be
taking a hard look at what/when Alpha might be (and yes, we'll post here).
An initial guess is in about two, maybe three, weeks.


So again... Alpha is coming. We all are responsible for Subversion, and we
all have our name attached to it. Pride of ownership also means taking pride
in the quality. Speak your mind... please.

Cheers,
-g

/me gets on his asbestos hip-waders, in preparation for wading through the
  tides of flaming muck...  :-)

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Community input for Alpha

[Josef Wolf <jw...@raven.inka.de>]

On Tue, Jun 11, 2002 at 06:46:40PM -0700, Greg Stein wrote:

> So. What do I mean by Alpha?
>   "All major features, necessary to accomplishing the tasks you would expect
>    Subversion to accomplish, have been completed enough to be functional for
>    the majority of use cases."

I would add:
    "All features which would need a change in user interface have
    been completed at least on the user interface."

This is because people would get very upset if you change the user
interface after 1.0 release. You need not to implement the feature
right now (you can implement it at release 3.0 for example). But you
should adopt the user interface so that it would stay the same if the
feature will be implemented in release 3.0 or so.

In this context I would like to discuss such a beast: a change which I
would like to see in some $BIGNUMBER release and which is likely to
change the behavior of the user interface in a way which would make
people upset. (But this is not the right time/place to discuss this)

> The Alpha release is intended for actual use scenarios.

Yes. Therefore all known big issues (which destroy the repo or the wc)
should be turned at least into little issues (destroy in a way so you
can recover somehow)

Example:
Yesterday I played with "svn update -r XYZ" from the original svn
repository to find out which commit broke the bug which at last was
fixed in r2160. Originally I was on r2157 (which was the newest at
that time). From that I "svn up -r 2024" (I assumed this release did
not contain the bug). This crashed and left my WC in a state which I
could not recover from. I checked out the newest rev again and
"svn up -r 2093" (because of the switch in repos format). Crash
again. Unpack latest tarball and "svn up -r 2130". Crash again.
Check out newest and "svn up -r 2135". Crash again. At last I could
identify r2131 to introduce the bug.

I think "svn up -r XYZ" _is_ an "actual use scenario". Please dont
misunderstand me: crashing is OK in pre-alpha. But if you announce
Alpha, _more_ people will come to take a look. If they experience such
crashes, they will run away and shout out loudly. And those people will
advocate: "It's crashing all the time. You dont really want to use it"

Therefore it is better to delay alpha as long as crashing issues are
open.

BTW: It loks to me that most of the crashes I expirienced yesterday
     were caused because of files were added/removed/moved/copied. I
     want to investigate this in the near feature. But I think
     you will be out with Alpha before I finish with this ;-))

> One more point of contrast is "what would a Beta be?" We're currently
> defining Beta as:
>   "We don't know of any bugs that prevent the use of Subversion. As far as
>    we're concerned it is at a release quality level, but we want to be
>    conservative and get some shakedown first. [especially as a high
>    confidence level is required for a version control system]"

ACK.

> 2) Agreement on shifting the current Alpha bugs to beta, the current
>    pre-alpha bugs to Alpha, and releasing Alpha when they are fixed.

I dont think it is good strategy to shift crashing issues (and there
are a lot of them) into beta just to get out alpha earlier. The more
stability you get in alpha the more people will give svn a try and
people will have more confidence into svn. This has to do with
psychology and is IMHO _very_ important for a project like svn because
svn can only be successful when people entrust it their sources!

For a project like svn "alpha" should be (internally) considered as
"beta" IMHO.

Once you have a discredit of "crashing often" it is very hard to
convince people of the opposite. So I vote to delay Alpha as long as
there are known "crashing" issues. Please dont hurry to get alpha
out.

> Note that there isn't a real cutoff for end-of-voting, as we'll be reviewing
> periodically. In particular, I'm in Chicago again next week, and we'll be
> taking a hard look at what/when Alpha might be (and yes, we'll post here).
> An initial guess is in about two, maybe three, weeks.

Two/three weeks to vote or to get Alpha out? IMHO this is too short
for Alpha.

> So again... Alpha is coming. We all are responsible for Subversion, and we
> all have our name attached to it. Pride of ownership also means taking pride
> in the quality. Speak your mind... please.
         
s/quality/quality+stability/

PS: OK, now it's your turn to flame on me ;-)

-- 
-- Josef Wolf -- jw@raven.inka.de --

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org