[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Community input for Alpha

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-06-12 03:46:40 CEST

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
Received on Wed Jun 12 03:45:25 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.