You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by solo turn <so...@yahoo.com> on 2002/12/29 15:15:29 UTC
svn 1.0 in 2006 or now?
what are your plans for the 1.0?
my impression after checking the task list for the milestones before
1.0 two months ago and now is that continuing like this will end in
v1.0 in year 2006 or eternity ... as the list is growing, not
shrinking.
would the following be a reasonable proceeding?
- declare some bugs as show stoppers
(currently i would know one, issue 730, related
to issue 995)
- go beta with the fixes of issues:
668,1003,891,940
- postpone everything else after 1.0
for doing this, more flexibility is necessary:
- command line can be changed after 1.0
example:
svn import needs the syntax fix,
but it is pointless and completely unimportant,
you barely need the import (i used it 2-3 times
in a year now).
- throw out every feature not needed for 1.0
i.e. converting/importing/exporting/managing/certs
- build things are pointless for the stability
of a product (configure on darwin does not bla ...)
- big api changes (like in 1004) do NOT
mean they are important for 1.0.
--> the api will change anyway later on.
- bindings can never prevent svn beeing less ready
(swig, ...), they even could be a separate thing.
if you need somebody sufficiently unbiased to cvs, unbiased to coding
and coders, and one doing this normally for earning money, i would
volunteer to be kind of "release manager", i.e. the one suggesting to
postpone all the issues as pointless for 1.0 (this dos NOT mean
unimportant!).
for issues, where a patch is already available, i just would apply it
after 1.0, like issue 774,952.
i know too many people now NOT using svn, cause it is not "finished".
but this is just not true. it is already more useable than cvs, and
that is sufficient for most projects and use cases.
or is somebody from the collab-guys, or greg stein without a job
after 1.0 is released?
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Bob Gustafson <bo...@rcnChicago.com>.
David Summers wrote on Wed, 1 Jan 2003 01:58:07 -0600
>On Wed, 1 Jan 2003, Bob Gustafson wrote:
>
>> If the fields were labeled (xml tagged) within the repository, then old
>> fields still could exist (but be ignored by current processes) in newer
>> repositories. The current data structures may change, but no data would
>> drop on the floor. To access old data however, would require some special
>> purpose parse code, or perhaps as an alternative to writing code, the
>> dump/restore processes could be done in reverse on those repositories.
>
>Well, last weekend I got a preliminary "svnadmin --xml dump" both as C
>code changes to svnadmin and then as a perl script that eats the normal
>"svnadmin dump" output and spits out XML. :-) People said there was no
>use-case for it. Is this a possible use-case for it? I've not yet done
>the "svnadmin load".
>
Close, but... I think that the xml tags need to be 'in' the repository
rather than attached to fields as part of an output process. The idea is to
have old version data (ignored perhaps) and new version data side by side
within the repository. As the repository grows, those old fossilized bits
of data will remain (nothing drops to the floor), but they may become
increasingly difficult to get at.
An administrator (or paid outside consultant :-) may set up an audit -
usage counting or something on that old data. If it is not being used, then
perhaps a willful whack can be done. But, this set of decisions would be
done at the user level and the timing etc., would be completely independent
of the svn development decision stream.
Think of human DNA. There are lots of bits of unused data hanging around -
probably for millions of years. Things still work. (now if we could only
read those old 'tags'..)
BobG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Wed, 1 Jan 2003, Bob Gustafson wrote:
> If the fields were labeled (xml tagged) within the repository, then old
> fields still could exist (but be ignored by current processes) in newer
> repositories. The current data structures may change, but no data would
> drop on the floor. To access old data however, would require some special
> purpose parse code, or perhaps as an alternative to writing code, the
> dump/restore processes could be done in reverse on those repositories.
Well, last weekend I got a preliminary "svnadmin --xml dump" both as C
code changes to svnadmin and then as a perl script that eats the normal
"svnadmin dump" output and spits out XML. :-) People said there was no
use-case for it. Is this a possible use-case for it? I've not yet done
the "svnadmin load".
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Bob Gustafson <bo...@rcnChicago.com>.
Tom Lord wrote on 31 Dec 2002 20:19:26 -0800
>Because for non-trivial deployment, you should consider the logical
>structure of your repository an at _least_ a 10 year investment, and
>probably a few multiples of that. Screwing around with it every few
>years and propogating that screwing around through your development
>and support process is kind of wacky. I think it's not too different
>from library cataloging systems: you don't see too many major
>overhauls to dewey or library of congress classifications every 2.5
>years, for example (may be a U.S.-centric analogy - sorry).
>
How about relaxing the requirement of dump/restore across versions to a
limited delta between versions?. It 'should' be possible to dump/restore
between version 0.93 and 0.94 for example.
If the 'should' was changed to 'guaranteed', then folks could breath a bit
easier - with the knowledge that *at most*, they would only have to
dump/restore N times to bridge the gap between version 0.94 and 0.94 + N,
if they fell behind the bleeding edge for awhile.
If this guarantee was part of the development committment of svn, then
there would be no worry that svn would have to support some fossilized
design many (internet) years into the future. There would always be an
automated process (perhaps multistep) that could be applied to an old
repository to bring it up to the current design.
-------
Some thoughts
If the 'fields' of svn were fixed at each development stage, then if fields
were added, the content of those new fields would be blank for old
versioned data. If 'fields' of svn were deleted in going to a new version,
then data would drop on the floor during the repository upgrade process -
maybe not such a good idea.
If the fields were labeled (xml tagged) within the repository, then old
fields still could exist (but be ignored by current processes) in newer
repositories. The current data structures may change, but no data would
drop on the floor. To access old data however, would require some special
purpose parse code, or perhaps as an alternative to writing code, the
dump/restore processes could be done in reverse on those repositories.
Happy New Year (CST)
BobG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
It's not because it's New Year's Eve [Happy New Year btw !]
that people will be drunk enough to accept that suddenly ;)
I suppose you may be right that that was my highest hope. (And Happy
New Year (and cheers) to you et al. also.)
More seriously: I've 99.9% given up on convincing the core developers
to reconsider their design but the question and answer did (and does)
seem like a fairly unique opportunity to try to draw out some of the
implications of their decision for that .1% shot; a fairly vivid
abstraction->instance situation.
But changing the whole subversion design (which you are
trying to say implicitly, ain't you ? :) ) is just madness.
In my eyes, it would be honorable bravery and a superlatively good
engineering decision.
Assuming it does require such drastic design changes, why not
make it 2.0 and just have some scripts to transfer 1.0
repositories to 2.0 format ?
Because for non-trivial deployment, you should consider the logical
structure of your repository an at _least_ a 10 year investment, and
probably a few multiples of that. Screwing around with it every few
years and propogating that screwing around through your development
and support process is kind of wacky. I think it's not too different
from library cataloging systems: you don't see too many major
overhauls to dewey or library of congress classifications every 2.5
years, for example (may be a U.S.-centric analogy - sorry).
If it doesn't last forever, it doesn't mean it cannot be used
before something better is done.
You have to look at the costs of deployment, not just the "small
matter of hacking". This is a damn conservative area and rightfully
so.
5...4...3...2...
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
You might very well be able to add to that list of design concerns,
but I doubt you'll uncover anything that, at this point in history,
justifies at least planning in detail for those features and
incorporating that planning into any widely deployed release.
"_not_ at least planning", of course.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
> Supposing that while adding some post-1.0 feature you
> discover that a vast simplification or other fundamental
> change to the logical structure is desirable
Whatever the change, I suppose there will still be some kind of
isomorphic relationship between both formats, because there
will still be log messages, revision numbers, etc. Therefore,
it's just a matter of writing a tool capable of converting one
format into the other.
If the new format contains more info than the previous one,
those new fields will most likely stay blank if they cannot be
generated from the previous format.
Just as a "minor" point, you are engineering by faith only:
I _suppose_ there will [...] be [...] some kind of
isomrphic relationship [because of just a few underspecified
factors common to all formats]
[....]
If the new format contains more info [...] new fields will
_most likely_ remain blank [and, implicitly, this will not
impact users]
It seems to me that the sum of concerns of arch and svn (pre and post
1.0) cover roughly:
*) A CVS-like user interface
*) changeset management
*) distribution
*) process integration
*) long-lived archives
and that _none_of_those_topics_are_mysteries_. There's no good reason
to just "suppose" or wave topics away with "most likely".
You might very well be able to add to that list of design concerns,
but I doubt you'll uncover anything that, at this point in history,
justifies at least planning in detail for those features and
incorporating that planning into any widely deployed release.
I think I'll shut up now unless someone replies with something really
interesting.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Sebastien Cevey <se...@cine7.net>.
On Tue, Dec 31, 2002 at 06:50:34PM -0800, Tom Lord wrote:
> Supposing that while adding some post-1.0 feature you discover that
> a vast simplification or other fundamental change to the logical
> structure is desirable
Whatever the change, I suppose there will still be some kind of
isomorphic relationship between both formats, because there will still
be log messages, revision numbers, etc. Therefore, it's just a matter
of writing a tool capable of converting one format into the other.
If the new format contains more info than the previous one, those new
fields will most likely stay blank if they cannot be generated from
the previous format.
> At the same time, there's talk of post 1.0 consideration of features
> like changeset management, history-sensitive merging, and
> distribution. What analysis of the problem space gives you
> confidence that the interface can reasonably remain stable as those
> advanced features are added?
Indeed. But changing the whole subversion design (which you are
trying to say implicitly, ain't you ? :) ) is just madness. It has
been talked over and over on this list. It's not because it's New
Year's Eve [Happy New Year btw !] that people will be drunk enough to
accept that suddenly ;)
Assuming it does require such drastic design changes, why not make it
2.0 and just have some scripts to transfer 1.0 repositories to 2.0
format ? Current SVN is so close to be mature that it'd be completely
stupid to stop here and rethink the whole thing. If it doesn't last
forever, it doesn't mean it cannot be used before something better is
done.
I mean, CVS -> SVN can be done, and I think there exists such tools
for almost all SCM. So why couldn't it be done here ?
--
Sebastien Cevey <se...@cine7.net>
Cine7.Net - Milcis.Net
Jabber: theefer@charente.de - ICQ: 48895760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
>> Is dump/restore guaranteed to be cross version? i.e.,
>> current version to version 1.0 ? Dumping and restoring
>> from/to the same SVN version is not the issue.
That's kind of the point. If the repository changes db
schemas, or db backends, the dump/load format is invariant. It
exists to migrate from one version to another. We've already
had to make that transition a few times.
Well, how is that possible, really?
Sure, you can easily migrate across isomorphic (user invisible)
changes to the internal schema, but in the general case, how do you
migrate across user visible changes to the logical structure of a
repository?
Obviously within some subset range of logical structure changes you
can fill in default values and the like, but since the thread is about
early adoption: are you committing to not changing the logical
structure except in upward compatible ways, or are you saying that
revisions committed now are not promised to be "full citizens" after
future releases, or both?
Supposing that while adding some post-1.0 feature you discover that a
vast simplification or other fundamental change to the logical
structure is desirable (is that impossible? can you say with
certainty that it is unlikely given the post-1.0 features you're
considering?). Suppose that that logical structure change involves
recording information not captured by the 1.0 release. Doesn't that
mean that that history recorded by <= 1.0 releases is incompatible
with that of post 1.0 releases -- that any processes people have built
around the <= 1.0 data are threatened with obsolescence? (Or, if you
promise not to render their data obsolete wrt svn, that "advanced"
features may well be either precluded or certain to be implemented
awkwardly?)
Now if I understand the project priorities right, the answer is
something like "Our goal is to improve on CVS. Whether or not we do
that is orthogonal to the issues we raise." But now, at least for
long-lived projects, doesn't that answer point to a future where
revision control is either stalled at "slightly better than CVS" or
one characterized by "continuously shifting revision control
technology"?
Along these same lines, you've recently described 1.0 as a "stable
interface" -- a commitment of some sort. At the same time, there's
talk of post 1.0 consideration of features like changeset management,
history-sensitive merging, and distribution. What analysis of the
problem space gives you confidence that the interface can reasonably
remain stable as those advanced features are added? (I've seen some
quick and dirty suggestions for approaches to these features but
seemingly nothing sufficiently worked out that it justifies interface
commitments.)
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Ben Collins-Sussman <su...@collab.net>.
Bob Gustafson <bo...@rcnChicago.com> writes:
> Is dump/restore guaranteed to be cross version? i.e., current version to
> version 1.0 ? Dumping and restoring from/to the same SVN version is not
> the issue.
That's kind of the point. If the repository changes db schemas, or db
backends, the dump/load format is invariant. It exists to migrate
from one version to another. We've already had to make that
transition a few times.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Bob Gustafson <bo...@rcnChicago.com>.
Garrett Rooney wrote on Tue, 31 Dec 2002 15:52:44 -0500:
>On Tuesday, December 31, 2002, at 03:50 PM, Bob Gustafson wrote:
>
>> Maybe having a process (or a guarantee that a process would exist) to
>> roll
>> out a repository to storage in a suitable form and then roll it into a
>> future updated (modified API/Code/Etc) repository would be enough for
>> folks
>> to use SVN for more projects, even in its present form.
>
>uh, we have that. svnadmin dump/restore. it's been working for months.
>
>-garrett
Is dump/restore guaranteed to be cross version? i.e., current version to
version 1.0 ? Dumping and restoring from/to the same SVN version is not
the issue.
BobG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Tuesday, December 31, 2002, at 03:50 PM, Bob Gustafson wrote:
> Maybe having a process (or a guarantee that a process would exist) to
> roll
> out a repository to storage in a suitable form and then roll it into a
> future updated (modified API/Code/Etc) repository would be enough for
> folks
> to use SVN for more projects, even in its present form.
uh, we have that. svnadmin dump/restore. it's been working for months.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Bob Gustafson <bo...@rcnChicago.com>.
Maybe having a process (or a guarantee that a process would exist) to roll
out a repository to storage in a suitable form and then roll it into a
future updated (modified API/Code/Etc) repository would be enough for folks
to use SVN for more projects, even in its present form.
I don't know whether this would be more trouble than touching up the last
bits to go to 1.0 or not.
BobG
Perry E. Metzger wrote on 31 Dec 2002 10:57:46 -0500:
>Karl Fogel <kf...@newton.ch.collab.net> writes:
>> Julian Fitzell <ju...@beta4.com> writes:
>> > And if people are holding off until 1.0, waiting for a
>> > stable interface that they won't have to put a lot of effort into
>> > updating for each new version, then it would be misleading to release
>> > 1.0 now when we know there are significant changes that still need to
>> > be made to achieve the base set of features.
>>
>> Wow, yes, exactly -- I couldn't have said it better. Thanks for the
>> concise explanation.
>
>Some of us are waiting for an official release to use subversion in
>our projects even though we could easily accept major changes in the
>interfaces (though not incompatible changes in the repository format
>obviously). If 1.0 is more than a few months off, could a stable
>release named .8 or .9 or something be created, with a "we know it
>won't eat your code, just don't expect upgrades to be painless"
>provisio? That is to say, "this is not beta code, but don't expect the
>same sort of interface stability 1.0 would mean"...
>
>Of course, if 1.0 were to happen in two months none of this would matter.
>
>Perry
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Daniel Rall <dl...@collab.net>.
On 31 Dec 2002, Perry E. Metzger wrote:
> If 1.0 is more than a few months off, could a stable release named .8 or
> .9 or something be created, with a "we know it won't eat your code, just
> don't expect upgrades to be painless" provisio? That is to say, "this is
> not beta code, but don't expect the same sort of interface stability 1.0
> would mean"...
0.16 > 0.9
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by "Perry E. Metzger" <pe...@piermont.com>.
solo turn <so...@yahoo.com> writes:
> exactly what perry is saying is the point. current plans point to
> 0.17, 0.18, ..., 0.23. given you need 2 months for each 0.XX, this
> means 14 months to reach beta. this means productive mid 2004. and
> this is NOT august 2002, as originally planned.
Indeed. What the numbering scheme is I don't much care about, but it
would be nice to have an *official* release that is said to be stable
for real users soon. It can have provisos like "we'll be making major
changes in interfaces", and it an be numbered anything you like, but
it has to be labeled "stable (in the sense of bugs) release".
By the way, at the same time, it would be good to have a users mailing
list, separate from the developers mailing list, for people who are
purely users to ask questions about using the product...
Perry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by solo turn <so...@yahoo.com>.
exactly what perry is saying is the point. current plans point to
0.17, 0.18, ..., 0.23. given you need 2 months for each 0.XX, this
means 14 months to reach beta. this means productive mid 2004. and
this is NOT august 2002, as originally planned.
i suggested the following issues are critical:
730,668,1003,891,940
and i suggested to postpone issues:
1042,1044,1019,1034,1035,1036,1037,1046,1031,630,1015,1025,
510,639,1004,1008,913,1006,724,
495,992,837,699,919,990,933,787,869,971,977,751,774,957,951,
952,950,885,882,620,571,443,746,558,738,
838,749,773,852,959,850,650,667,997,854,986,752,991,777,
946,987,
these are not important for 1.0 cause:
1. they do not concern the stability
2. they are not specifications:
interfaces are specified prior to programming,
and NOBODY changes interfaces just like that.
3. internal "interfaces" are not interfaces
which count as interface to the outside world.
and please do NOT start a highly theoretical discussion about design,
goals, processes if the point is to postpone a bunch of issues, like
"fix python error in testcase 5345".
and please do NOT say "when we know there are significant changes
that still need to be made to achieve the base set of features."
without naming them or saying "issue XXX" would be such a thing and
don't think about saying that without reading the issue list.
i guarantee if you continue like this you will NEVER finish but you
will notice 0.17 would have been your 1.0 beta. and there is only one
valid reason for doing that: if your job depends on that.
svn has the major building blocks for productivity NOW:
1. easy upgrade in every now known case:
new client, new server, new db format (this is rare)
2. stable berkely db based server, no data loss
3. good architecture for even tackling the tom lord
issue list in future.
you just don't need to fix 2000 further issues and introduce 1567 new
bugs.
--- "Perry E. Metzger" <pe...@piermont.com> wrote:
>
> Karl Fogel <kf...@newton.ch.collab.net> writes:
> > Julian Fitzell <ju...@beta4.com> writes:
> > > And if people are holding off until 1.0, waiting for a
> > > stable interface that they won't have to put a lot of effort
> into
> > > updating for each new version, then it would be misleading to
> release
> > > 1.0 now when we know there are significant changes that still
> need to
> > > be made to achieve the base set of features.
> >
> > Wow, yes, exactly -- I couldn't have said it better. Thanks for
> the
> > concise explanation.
>
> Some of us are waiting for an official release to use subversion in
> our projects even though we could easily accept major changes in
> the
> interfaces (though not incompatible changes in the repository
> format
> obviously). If 1.0 is more than a few months off, could a stable
> release named .8 or .9 or something be created, with a "we know it
> won't eat your code, just don't expect upgrades to be painless"
> provisio? That is to say, "this is not beta code, but don't expect
> the
> same sort of interface stability 1.0 would mean"...
>
> Of course, if 1.0 were to happen in two months none of this would
> matter.
>
> Perry
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Julian Fitzell <ju...@beta4.com> writes:
> > And if people are holding off until 1.0, waiting for a
> > stable interface that they won't have to put a lot of effort into
> > updating for each new version, then it would be misleading to release
> > 1.0 now when we know there are significant changes that still need to
> > be made to achieve the base set of features.
>
> Wow, yes, exactly -- I couldn't have said it better. Thanks for the
> concise explanation.
Some of us are waiting for an official release to use subversion in
our projects even though we could easily accept major changes in the
interfaces (though not incompatible changes in the repository format
obviously). If 1.0 is more than a few months off, could a stable
release named .8 or .9 or something be created, with a "we know it
won't eat your code, just don't expect upgrades to be painless"
provisio? That is to say, "this is not beta code, but don't expect the
same sort of interface stability 1.0 would mean"...
Of course, if 1.0 were to happen in two months none of this would matter.
Perry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Julian Fitzell <ju...@beta4.com> writes:
> And if people are holding off until 1.0, waiting for a
> stable interface that they won't have to put a lot of effort into
> updating for each new version, then it would be misleading to release
> 1.0 now when we know there are significant changes that still need to
> be made to achieve the base set of features.
Wow, yes, exactly -- I couldn't have said it better. Thanks for the
concise explanation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Julian Fitzell <ju...@beta4.com>.
solo turn wrote:
> --- Karl Fogel <kf...@newton.ch.collab.net> wrote:
>
>>solo turn <so...@yahoo.com> writes:
>>
>>>what are your plans for the 1.0?
>>>
>>>my impression after checking the task list for the milestones
>>
>>before
>>
>>>1.0 two months ago and now is that continuing like this will end
>>
>>in
>>
>>>v1.0 in year 2006 or eternity ... as the list is growing, not
>>>shrinking.
>>
>>Periodically we do go over the whole bug list and push what we can
>>past 1.0.
>
> may i suggest to postpone the following issues past 1.0:
>
> 1042,1044,1019,1034,1035,1036,1037,1046,1031,630,1015,1025,
> 510,639,1004,1008,913,1006,724,
> 495,992,837,699,919,990,933,787,869,971,977,751,774,957,951,
> 952,950,885,882,620,571,443,746,558,738,
> 838,749,773,852,959,850,650,667,997,854,986,752,991,777,
> 946,987,
>
> and go beta if the remaining "critical" ones are done
> (730,668,1003,891,940)?
>
>
>>>i know too many people now NOT using svn, cause it is not
>>
>>"finished".
>>
>>>but this is just not true. it is already more useable than cvs,
>>
>>and
>>
>>>that is sufficient for most projects and use cases.
>>
>>Feature-wise, maybe, but not in terms of stability.
>
> there is two kinds of stability:
> - data is safe and accessible:
> i consider it as stable, as i never heard of
> somebody who lost a repository recently.
> and berkely db is definitely known as very
> reliable. so the data store is safe.
It's probably safe, but until 1.0 there may still be times when you have
to dump the db and reload it, etc. For a user to have to keep up with
this in point releases (which they would if we went to 1.0 before these
foreseeable changes are made) seems arduous.
> - the interfaces are stable
> you can just make it stable
> but svn 2.0 does NOT need to have
> the same interfaces, otherwise
no, but svn 1.1 should, and 1.2, etc. By releasing a 1.0, you make a
certain commitment to keeping a relatively stable API in the short term.
> it will end up as one of the unusable
> unix-dinosaurs where one wrong decision
> gets dragged along for years.
> don't have the illusion of doing
> it perfect for 1.0.
>
>
>>Remember that Linux had many users before 1.0, as people gradually
>>realized that it was getting stable and that Linus was just being
>>conservative.
>
> granted.
> but i still think svn has less crashes than linux. and the majorities
> of issues have nothing to do with crashes.
>
>
>>interfaces, we've missed the point. And it's not as if we're
>>suffering from a shortage of users or testers right now. Let's
>>worry
>>about bugs and features, not labels :-).
>
> this is the only point we disagree.
> labes are important. and features is not any more important for 1.0.
I have to agree with Karl here. I mean, you're saying subversion is
basically stable enough to use right now; so why not use it? The only
reason people need to wait for 1.0 is if they want a stable interface
since (as you point out) the reliability of the data seems to be pretty
good. And if people are holding off until 1.0, waiting for a stable
interface that they won't have to put a lot of effort into updating for
each new version, then it would be misleading to release 1.0 now when we
know there are significant changes that still need to be made to achieve
the base set of features.
Anyway, that's my 2 cents. Personally, I tinker with subversion but I'm
waiting for it to stablilize in terms of API, in terms of storage
format, in terms of config files, etc. before doing any kind of major
work with it. And while it would be fabulous if 1.0 came sooner, I'm
not waiting for the code to have the 1.0 /label/, I'm waiting for it to
have a /state/ with a 1.0 level of stability.
Julian
--
julian@beta4.com
Beta4 Productions (http://www.beta4.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by solo turn <so...@yahoo.com>.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> solo turn <so...@yahoo.com> writes:
> > what are your plans for the 1.0?
> >
> > my impression after checking the task list for the milestones
> before
> > 1.0 two months ago and now is that continuing like this will end
> in
> > v1.0 in year 2006 or eternity ... as the list is growing, not
> > shrinking.
>
> Periodically we do go over the whole bug list and push what we can
> past 1.0.
may i suggest to postpone the following issues past 1.0:
1042,1044,1019,1034,1035,1036,1037,1046,1031,630,1015,1025,
510,639,1004,1008,913,1006,724,
495,992,837,699,919,990,933,787,869,971,977,751,774,957,951,
952,950,885,882,620,571,443,746,558,738,
838,749,773,852,959,850,650,667,997,854,986,752,991,777,
946,987,
and go beta if the remaining "critical" ones are done
(730,668,1003,891,940)?
>
> > i know too many people now NOT using svn, cause it is not
> "finished".
> > but this is just not true. it is already more useable than cvs,
> and
> > that is sufficient for most projects and use cases.
>
> Feature-wise, maybe, but not in terms of stability.
there is two kinds of stability:
- data is safe and accessible:
i consider it as stable, as i never heard of
somebody who lost a repository recently.
and berkely db is definitely known as very
reliable. so the data store is safe.
- the interfaces are stable
you can just make it stable
but svn 2.0 does NOT need to have
the same interfaces, otherwise
it will end up as one of the unusable
unix-dinosaurs where one wrong decision
gets dragged along for years.
don't have the illusion of doing
it perfect for 1.0.
> Remember that Linux had many users before 1.0, as people gradually
> realized that it was getting stable and that Linus was just being
> conservative.
granted.
but i still think svn has less crashes than linux. and the majorities
of issues have nothing to do with crashes.
> interfaces, we've missed the point. And it's not as if we're
> suffering from a shortage of users or testers right now. Let's
> worry
> about bugs and features, not labels :-).
this is the only point we disagree.
labes are important. and features is not any more important for 1.0.
> > or is somebody from the collab-guys, or greg stein without a job
> > after 1.0 is released?
>
> No, don't worry, 1.0 has no effect on our jobs. (By the way, Greg
> Stein *is* one of the Collab guys.)
that's great!
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
solo turn <so...@yahoo.com> writes:
> what are your plans for the 1.0?
>
> my impression after checking the task list for the milestones before
> 1.0 two months ago and now is that continuing like this will end in
> v1.0 in year 2006 or eternity ... as the list is growing, not
> shrinking.
Periodically we do go over the whole bug list and push what we can
past 1.0.
> i know too many people now NOT using svn, cause it is not "finished".
> but this is just not true. it is already more useable than cvs, and
> that is sufficient for most projects and use cases.
Feature-wise, maybe, but not in terms of stability.
Remember that Linux had many users before 1.0, as people gradually
realized that it was getting stable and that Linus was just being
conservative. We're not going to be quite as conservative, perhaps,
but still pretty cautious, because when 1.0 comes out, it needs to be
as safe for your data as CVS.
The main purpose of calling it "1.0" is to say that these interfaces
are relatively stable. If we release 1.0 and then start changing
interfaces, we've missed the point. And it's not as if we're
suffering from a shortage of users or testers right now. Let's worry
about bugs and features, not labels :-).
> or is somebody from the collab-guys, or greg stein without a job
> after 1.0 is released?
No, don't worry, 1.0 has no effect on our jobs. (By the way, Greg
Stein *is* one of the Collab guys.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jan 03, 2003 at 09:28:41AM -0800, solo turn wrote:
> hmm ... karl .. the problem is that you are definitly
> not wrong ... BUT:
> - you seem to be in the same situation as jim blandy,
> brilliant and blind for mainstream users needs
> and expectations
> (add -R choking for existing files/dirs for example,
> ... every newcomer falls over that)
And that bug is why we aren't beta. And numerous others. What's your point?
> - there is "beta" (after the fix of the issues mentioned),
> then there is "1.0".
And we define beta as "no known bugs", and sometimes refine that as "any
bugs have very simple workarounds or the bugs don't really affect user
functionality."
> and karl is trying to avoid jim's beta experience ...
> but thats why "beta" is there, to FIND THESE BUGS.
Nah. We said that is what alpha is for.
Sorry, but as Ben said: we're a version control system. As a result, we've
defined the alpha/beta/final release criteria with a *lot* of conservatism.
We want to tell people, "this is rock solid. you can entrust your corporate
assets to it." When companies have *millions* of dollars at stake, it tends
to produce a very conservative behavior.
"But Open Source developers don't need that." Sure they do. They don't have
*money* at stake, but they certainly have personal time involved. And their
experiences with Subversion are *precisely* the mechanism whereby SVN earns
its "rock solid" description. Without the OSS community, SVN could never
reach such a label.
I believe most of the active developers tend to agree with this. We want a
solid reputation, and we're willing to give SVN the time it needs to reach
that. Taking over the world doesn't have to happen *tomorrow*. If it takes
another few months? Fine. The simple answer is that if SVN is rock solid,
then we *will* become the dominant OSS version control system. My confidence
level in that is huge, and it depends on taking a conservative approach.
I'll trade a few months for that guarantee of being known as the OSS
community's version control system.
>...
> not going beta is bad for everybody. new features can't be
> added (as we soon have 1.0 ... in 2004), mainstream users
We aren't adding (big) features now. Little ones are sneaking in, but we're
resisting, and I'm certainly telling the guys in Chicago to avoid adding
them (yes, this is one area where I get to exercise a bit of mgmt muscle).
Ben added the auto-versioning stuff, but that was on "his time" rather than
on CollabNet time. (but I'm not actually going to complain :-)
> needing a time schedule getting fed up (what are these
> svn guys doing, they say august, but maybe they forgot
> the year? is that the new opensource?).
August? Where'd that come from? We haven't set a release date. I've
generally been thinking something like March or April.
> i'm doing basically nothing but "release management" for
> the last 10 years ... and i know about arguments for and
> against a release ... and i also know when it is a good
> time to do a release. from a users point of view, not
> from a developers point of view.
Well, goody for you. We've got some experience, too.
>...
> and i want to mention one example of a not at all
> important (even if 4 developpers carefully thought
> about that) task:
> 1031 DEFECT P3 All issues@subversion NEW
> gcc3.3 compile warnings
>
> why the heck is a "upcoming gcc 3.3 compile warning"
> prevent subversion from going beta????
It was marked as bite-sized with the hope that others would take care of it
(and put in 0.19 to give them plenty of time). In fact, Matt Kraai did
exactly that with commit r4117. The reason it got left is that compiler
warnings can be indicative of real bugs. Karl just fixed a potential
NULL-deref yesterday, clued in by a compiler warning.
It was a choice we made, and I'm still alright with it. Note also that we'd
have another review of it when 0.19 came around. It could very well be that
we would have deferred it at that point, if it hadn't been fixed.
Cheers,
-g
--
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: svn 1.0 in 2006 or now?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Perry E. Metzger" <pe...@piermont.com> writes:
> As I said, I'm happy with something not called "1.0" but which is an
> official release that is considered free of major bugs. That might not
> be suitable for everyone, but it will be suitable for many of us and
> those bugs need to be nuked anyway.
>
> I certainly don't want to see something called a "release" with known
> bad bugs. On the other hand, I suspect parts of what are delaying 1.0
> are not bugs but features...
No need to "suspect" anything, Perry :-). The issues blocking 1.0 are
listed. Read the issue tracker, and you will see that it's mostly
bugs, not features. The last link on this page
http://subversion.tigris.org/project_tasks.html
is the one you want.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Branko Čibej <br...@xbc.nu> writes:
> > Regardless of the rest of this discussion, I think it is time to set a
> > definite date on 1.0. I believe we're far enough feature-wise, and quite
> > close to the required stability.
>
> With all due respect to you, Perry, and Solo Turn, I think you're
> wrong. We are not near the required stability. We have the features,
> but there are still just too many serious bugs -- we've got seg faults
> coming in with some regularity, for example.
That's actually part of what I'm getting at. The reason I need a
"release", even a pre-1.0 release, is to know that the code in
question is free of serious bugs. I do not need stability of
interface, but I do need freedom from bugs.
Given that, I can start to use Subversion in real projects, and I
think that's good for Subversion. More users means more developers,
more ideas, and frankly more experience on which to learn how people
interact with the software.
> We already have tons of people willing to start using Subversion right
> now, as it is, and more arriving every day. The only reason to call
> it "1.0" is to attract the mainstream users who want high reliability
> and no suprises -- and if we're honest with ourselves, we need to
> admit that Subversion is simply not ready for them yet.
As I said, I'm happy with something not called "1.0" but which is an
official release that is considered free of major bugs. That might not
be suitable for everyone, but it will be suitable for many of us and
those bugs need to be nuked anyway.
I certainly don't want to see something called a "release" with known
bad bugs. On the other hand, I suspect parts of what are delaying 1.0
are not bugs but features...
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Alexis Huxley <ah...@gmx.net>.
On Thu, Jan 02, 2003 at 02:27:11PM -0600, Karl Fogel wrote:
> With all due respect to you, Perry, and Solo Turn, I think you're
> ...
> than the day before. So if you know someone who is waiting till
> Subversion reaches 1.0, and your own testimony isn't enough to
> persuade them that it's ready now, then they're probably right -- they
> need to wait until 1.0, and we need to make sure that 1.0 means what
> ...
Here here! (Or is it hear hear!?)
> Believe me, I hunger for 1.0 as much as anyone. There will no doubt
Actually, I'm very happy with the speed of release number bumping;
and if it indicates anything about the future rate then that'll make
me even happier. I'm much more in favour of the Debian and *BSD
slow bumping than the RedHat bump-a-minute approach.
Keep up the good work! And thanks again for a great product, which
I am really enjoying using.
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 08, 2003 at 12:30:56AM +0100, Steinar Bang wrote:
> >>>>> Steinar Bang <sb...@dod.no>:
>
> >>>>> Karl Fogel <kf...@newton.ch.collab.net>:
> > [...]
> >> The kinds of users who depend mainly on the label -- "1.0",
> >> "stable", whatever -- to decide whether or not to try Subversion,
> >> are exactly the kinds who will be put off if they encounter a seg
> >> fault or an obvious bug.
>
> > Not neccessarily. I'm someone who's waiting for "1.0" to do the
> > switch from CVS. But once the switch is done I won't be going back
> > even if I encounter the odd seg fault or two.
Then feel free to switch now. We've been using it ourselves for practically
18 months. Once we called it "alpha", that meant it was ready for people to
start trying it out: all the day-to-day features are in and working.
> One thing that _would_ scare me away, is data corruption.
Hasn't happened yet.
Cheers,
-g
--
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: svn 1.0 in 2006 or now?
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Karl Fogel <kf...@newton.ch.collab.net>:
> [...]
>> The kinds of users who depend mainly on the label -- "1.0",
>> "stable", whatever -- to decide whether or not to try Subversion,
>> are exactly the kinds who will be put off if they encounter a seg
>> fault or an obvious bug.
> Not neccessarily. I'm someone who's waiting for "1.0" to do the
> switch from CVS. But once the switch is done I won't be going back
> even if I encounter the odd seg fault or two.
One thing that _would_ scare me away, is data corruption.
Happened to me with CVS in 1991, and I didn't try it again until 1995.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Karl Fogel <kf...@newton.ch.collab.net>:
[...]
> The kinds of users who depend mainly on the label -- "1.0",
> "stable", whatever -- to decide whether or not to try Subversion,
> are exactly the kinds who will be put off if they encounter a seg
> fault or an obvious bug.
Not neccessarily. I'm someone who's waiting for "1.0" to do the
switch from CVS. But once the switch is done I won't be going back
even if I encounter the odd seg fault or two.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Stein <gs...@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
Re: feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
solo turn <so...@yahoo.com> writes:
> 913: make import faster.
> reason: not used very often. works as it is.
> 510,511: xdelta reverse, svn patch
> reason: no bug, extension. potential danger of
> stability problems.
Yeah, 510 is questionable, though it's a pretty harsh interface change
and it would be nice to have it in 1.0 (913 is essentially a no-op
once 510 is done). As we get closer to Beta and 1.0, we should
reconsider those; possibly they will get moved.
I think you're right about 511; have moved that one Post-1.0, hope no
one minds.
Thanks solo,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by solo turn <so...@yahoo.com>.
--- Greg Stein <gs...@lyra.org> wrote:
> Well, the hope is that everybody wins. I might suggest that if you
> have
> strong feeling about deferring particular issues, then discuss them
> on this
> list. Rather than declaring the whole approach is wrong and that we
> simply
> need to accept your position and get a release out. Instead, pick
> off one or
> two of the issues that concern you the most. Maybe you can get
> people to
> agree with you that they should be post-1.0.
ok (even if i know you wanted to do this forever ;)) ).
913: make import faster.
reason: not used very often. works as it is.
510,511: xdelta reverse, svn patch
reason: no bug, extension. potential danger of
stability problems.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jan 03, 2003 at 12:45:12PM -0800, solo turn wrote:
>...
> yes ... it looks terribly like a circle ... you think you are right
> and i think you are jim-blandy-blind in this respect ... and at the
> end you win :)
Well, the hope is that everybody wins. I might suggest that if you have
strong feeling about deferring particular issues, then discuss them on this
list. Rather than declaring the whole approach is wrong and that we simply
need to accept your position and get a release out. Instead, pick off one or
two of the issues that concern you the most. Maybe you can get people to
agree with you that they should be post-1.0.
>...
> 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 :-) ]
> - 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".
> - target date 1.4.2002
I think it is more like "sometime in April or May", but we'll see when we
get closer.
> - if necessary, separate out the bindings
SVN needs cvs2svn in order to be successful, and that requires the bindings.
The Python bindings are actually quite solid, but for the build issues,
which I've been spending some time on.
Cheers,
-g
--
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: feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Sunday, January 5, 2003, at 06:09 PM, Ben Elliston wrote:
>>>>>> "Garrett" == Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> Garrett> we aren't wasting developer time having developers
> Garrett> prioritize bugs, we're putting it to good use, because only
> Garrett> the people who actually know the code and the project know
> Garrett> what needs to be done.
>
> OK, I agree, but surely user input has *some* value in deciding what
> is considered to be a "must fix" bug for any Subversion release?
certainly, but there's a big difference between saying 'i think this
bug is important', and saying again and again 'you guys are wrong, all
these bugs are not important, release 1.0 now now now!' the first
option gets listened to, the second simply irritates the people who are
actually doing useful work.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by Ben Elliston <bj...@redhat.com>.
>>>>> "Garrett" == Garrett Rooney <ro...@electricjellyfish.net> writes:
Garrett> we aren't wasting developer time having developers
Garrett> prioritize bugs, we're putting it to good use, because only
Garrett> the people who actually know the code and the project know
Garrett> what needs to be done.
OK, I agree, but surely user input has *some* value in deciding what
is considered to be a "must fix" bug for any Subversion release?
Cheers, Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
solo turn wrote:
>yes ... it looks terribly like a circle ... you think you are right
>and i think you are jim-blandy-blind in this respect ... and at the
>end you win :)
>
>may i help with what i know best? am i allowed to do release
>management here? then it does not take the time of 4 highly qualified
>developpers to do this dummy job. this is pure waste ...
>
>
frankly, no, you can't do release management here because you have yet
to contribute substantially to the project. this is a meritocracy, and
until you prove yourself i doubt anyone is going to listen to you
telling them what bugs to work on. if you want to get to the point
where people do listen to you, i suggest digging in and writing some
code, as that's the fastest way to change people's mind.
we aren't wasting developer time having developers prioritize bugs,
we're putting it to good use, because only the people who actually know
the code and the project know what needs to be done.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
feature freeze, and release date (was: svn 1.0 in 2006 or now?)
Posted by solo turn <so...@yahoo.com>.
-- "Ben Collins-Sussman" <su...@collab.net> wrote:
> I feel like this is going in circles. You seem to repeatedly point
> out all the harms that come from delaying labels. Our position is
> that much *more* harm will come by labelling things too early.
yes ... it looks terribly like a circle ... you think you are right
and i think you are jim-blandy-blind in this respect ... and at the
end you win :)
may i help with what i know best? am i allowed to do release
management here? then it does not take the time of 4 highly qualified
developpers to do this dummy job. this is pure waste ...
it will be like:
- beta with the mentioned and
0.17 issues fixed
- no new features or architectureal
changes in the 1.0 branch
- 1.0 after 1-2 month beta
- target date 1.4.2002
- if necessary, separate out the
bindings
fitz, its then me who gets the blame for too early, and its you as
developper for the good product. a fair distribution.
the other possibility is: we make a bet.
if you don't change your strategy and you have 1.0 earlier than mid
2004, i pay you a beer per month you are earlier. this holds even if
you know that there is a bet ;))
feel free to pay me a beer for every month you are late ....
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Ben Collins-Sussman <su...@collab.net>.
solo turn <so...@yahoo.com> writes:
> - you seem to be in the same situation as jim blandy,
> brilliant and blind for mainstream users needs
> and expectations
Karl's point is that we're trying to *avoid* what happened to Jim.
We're defining "blind to users' expectations" as "unaware of bugs that
will trip them up". You seem to define the same phrase as "unaware
that users desperately need the 1.0 label."
> (add -R choking for existing files/dirs for example,
> ... every newcomer falls over that)
Sorry, can you explain this? What issue is this?
> and karl is trying to avoid jim's beta experience ...
> but thats why "beta" is there, to FIND THESE BUGS.
> and it does NOT matter if there is a few bugs you
> know about.
Actually, no, we've defined "beta" as "no known bugs". This is a
conservative release management strategy, and we need to be
conservative, because we're a version control system.
> not going beta is bad for everybody. new features can't be
> added (as we soon have 1.0 ... in 2004), mainstream users
> needing a time schedule getting fed up (what are these
> svn guys doing, they say august, but maybe they forgot
> the year? is that the new opensource?).
I feel like this is going in circles. You seem to repeatedly point
out all the harms that come from delaying labels. Our position is
that much *more* harm will come by labelling things too early.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by solo turn <so...@yahoo.com>.
hmm ... karl .. the problem is that you are definitly
not wrong ... BUT:
- you seem to be in the same situation as jim blandy,
brilliant and blind for mainstream users needs
and expectations
(add -R choking for existing files/dirs for example,
... every newcomer falls over that)
- there is "beta" (after the fix of the issues mentioned),
then there is "1.0".
and karl is trying to avoid jim's beta experience ...
but thats why "beta" is there, to FIND THESE BUGS.
and it does NOT matter if there is a few bugs you
know about.
not going beta is bad for everybody. new features can't be
added (as we soon have 1.0 ... in 2004), mainstream users
needing a time schedule getting fed up (what are these
svn guys doing, they say august, but maybe they forgot
the year? is that the new opensource?).
i'm doing basically nothing but "release management" for
the last 10 years ... and i know about arguments for and
against a release ... and i also know when it is a good
time to do a release. from a users point of view, not
from a developers point of view.
some of the decision points for "release now" are:
- new features, new development branches (like
caching, ...)
- new architecture ("rewrite client")
- new base software (new berkely db version)
- seg faults coming IN (they were not there
before)
and i want to mention one example of a not at all
important (even if 4 developpers carefully thought
about that) task:
1031 DEFECT P3 All issues@subversion NEW
gcc3.3 compile warnings
why the heck is a "upcoming gcc 3.3 compile warning"
prevent subversion from going beta????
and the others mentioned are not quite as obvious,
but the same category.
and i like brankos idea of the 1st of april,
nobody will blame you :))))
solo.
ps1:
we are using subversion with new users all the time,
one by one and are pretty sure what they need, and what
they want. and our users are microsoft point and click
users ... hardly any cvs/unix involved.
ps2:
for issue 689: i did not mention it, as it is where
it belongs: the next thing to be done.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> Branko Čibej <br...@xbc.nu> writes:
> > Regardless of the rest of this discussion, I think it is time to
> set a
> > definite date on 1.0. I believe we're far enough feature-wise,
> and quite
> > close to the required stability.
>
> With all due respect to you, Perry, and Solo Turn, I think you're
> wrong. We are not near the required stability. We have the
> features,
> but there are still just too many serious bugs -- we've got seg
> faults
> coming in with some regularity, for example.
>
> I think a lot of us may have become so accustomed to the bugs that
> we've forgotten what it's like to experience them for the first
> time.
>
> Jim Blandy tells a good story about a similar situation:
>
> When he was in charge of turning GNU Emacs 18.59 into Emacs 19, he
> was
> naturally always using the latest development Emacs to edit itself.
> It had plenty of bugs, but since he had to get work done and
> couldn't
> fix them all at once, he just learned to avoid certain things.
> Don't
> type this key sequence, don't move the mouse this particular way,
> don't switch buffers in the following circumstances, etc, etc.
> These
> little coping mechanisms became reflexive to him; pretty soon, he
> wasn't conscious of them at all. He became very different from a
> regular user.
>
> When he finally released a Beta, the testers encountered all these
> problems immediately, and started reporting tons of obvious bugs.
> Jim
> was embarrassed. He'd "known" about them, but the workarounds had
> become second nature, so he thought he had a useable editor when he
> didn't quite.
>
> We already have tons of people willing to start using Subversion
> right
> now, as it is, and more arriving every day. The only reason to
> call
> it "1.0" is to attract the mainstream users who want high
> reliability
> and no suprises -- and if we're honest with ourselves, we need to
> admit that Subversion is simply not ready for them yet.
>
> The kinds of users who depend mainly on the label -- "1.0",
> "stable",
> whatever -- to decide whether or not to try Subversion, are exactly
> the kinds who will be put off if they encounter a seg fault or an
> obvious bug. Since the only purpose of the label is to tell those
> kinds of users "Yes, we're past all that stuff now", Subversion
> will
> look very bad if it's not true. The damage to faith is
> instantaneous
> and severe, and won't be recovered from quickly. The user will go
> away for a year or so, and overall we'll get a much slower adoption
> than we could otherwise have had.
>
> On a semi-related note:
>
> The arrangement of issues in the Subversion issue tracker is far
> from
> random. It results from Ben Collins-Sussman, Greg Stein, Mike
> Pilato,
> and me all sitting around a whiteboard and considering *every
> single*
> issue that was then categorized as pre-1.0. Our explicit goal was
> to
> move as many of them as possible to post-1.0. That means the ones
> we
> left in pre-1.0 are there because at least four developers thought
> they were serious enough to need fixing -- four developers who
> badly
> wanted to minimize the number of pre-1.0 issues.
>
> So for what it's worth, my sense that Subversion's bug set is too
> large and too serious for 1.0 is not derived from some vague,
> hand-wavy feeling. It comes from having evaluated and discussed
> *every single* bug, many of them more than once. If you haven't
> done
> so, you really should try reading over all those bugs, and see if
> you
> still feel we're near 1.0 afterwards.
>
> Solo Turn, I notice that you didn't even mention issue #689 in your
> proposed breakedown, neither for pre-1.0 nor post-1.0. Yet it's
> perhaps the most serious issue in the tracker right now, one of the
> few where I would unhesitatingly veto a 1.0 release if it remained
> unresolved. Scanning the summary list and getting a general
> impression of stability can be deceptive...
>
> Believe me, I hunger for 1.0 as much as anyone. There will no
> doubt
> be more issue triage sessions, and maybe we can move some more
> things
> past 1.0. But we have to remember what the label is for:
> reassurance.
> Calling Subversion "1.0" doesn't affect its actual stability one
> bit.
> Subversion won't be any more "finished" the day after we release
> 1.0
> than the day before. So if you know someone who is waiting till
> Subversion reaches 1.0, and your own testimony isn't enough to
> persuade them that it's ready now, then they're probably right --
> they
> need to wait until 1.0, and we need to make sure that 1.0 means
> what
> they expect it to mean.
>
> -Karl
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Regardless of the rest of this discussion, I think it is time to set a
> definite date on 1.0. I believe we're far enough feature-wise, and quite
> close to the required stability.
With all due respect to you, Perry, and Solo Turn, I think you're
wrong. We are not near the required stability. We have the features,
but there are still just too many serious bugs -- we've got seg faults
coming in with some regularity, for example.
I think a lot of us may have become so accustomed to the bugs that
we've forgotten what it's like to experience them for the first time.
Jim Blandy tells a good story about a similar situation:
When he was in charge of turning GNU Emacs 18.59 into Emacs 19, he was
naturally always using the latest development Emacs to edit itself.
It had plenty of bugs, but since he had to get work done and couldn't
fix them all at once, he just learned to avoid certain things. Don't
type this key sequence, don't move the mouse this particular way,
don't switch buffers in the following circumstances, etc, etc. These
little coping mechanisms became reflexive to him; pretty soon, he
wasn't conscious of them at all. He became very different from a
regular user.
When he finally released a Beta, the testers encountered all these
problems immediately, and started reporting tons of obvious bugs. Jim
was embarrassed. He'd "known" about them, but the workarounds had
become second nature, so he thought he had a useable editor when he
didn't quite.
We already have tons of people willing to start using Subversion right
now, as it is, and more arriving every day. The only reason to call
it "1.0" is to attract the mainstream users who want high reliability
and no suprises -- and if we're honest with ourselves, we need to
admit that Subversion is simply not ready for them yet.
The kinds of users who depend mainly on the label -- "1.0", "stable",
whatever -- to decide whether or not to try Subversion, are exactly
the kinds who will be put off if they encounter a seg fault or an
obvious bug. Since the only purpose of the label is to tell those
kinds of users "Yes, we're past all that stuff now", Subversion will
look very bad if it's not true. The damage to faith is instantaneous
and severe, and won't be recovered from quickly. The user will go
away for a year or so, and overall we'll get a much slower adoption
than we could otherwise have had.
On a semi-related note:
The arrangement of issues in the Subversion issue tracker is far from
random. It results from Ben Collins-Sussman, Greg Stein, Mike Pilato,
and me all sitting around a whiteboard and considering *every single*
issue that was then categorized as pre-1.0. Our explicit goal was to
move as many of them as possible to post-1.0. That means the ones we
left in pre-1.0 are there because at least four developers thought
they were serious enough to need fixing -- four developers who badly
wanted to minimize the number of pre-1.0 issues.
So for what it's worth, my sense that Subversion's bug set is too
large and too serious for 1.0 is not derived from some vague,
hand-wavy feeling. It comes from having evaluated and discussed
*every single* bug, many of them more than once. If you haven't done
so, you really should try reading over all those bugs, and see if you
still feel we're near 1.0 afterwards.
Solo Turn, I notice that you didn't even mention issue #689 in your
proposed breakedown, neither for pre-1.0 nor post-1.0. Yet it's
perhaps the most serious issue in the tracker right now, one of the
few where I would unhesitatingly veto a 1.0 release if it remained
unresolved. Scanning the summary list and getting a general
impression of stability can be deceptive...
Believe me, I hunger for 1.0 as much as anyone. There will no doubt
be more issue triage sessions, and maybe we can move some more things
past 1.0. But we have to remember what the label is for: reassurance.
Calling Subversion "1.0" doesn't affect its actual stability one bit.
Subversion won't be any more "finished" the day after we release 1.0
than the day before. So if you know someone who is waiting till
Subversion reaches 1.0, and your own testimony isn't enough to
persuade them that it's ready now, then they're probably right -- they
need to wait until 1.0, and we need to make sure that 1.0 means what
they expect it to mean.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Branko Čibej <br...@xbc.nu>.
Regardless of the rest of this discussion, I think it is time to set a
definite date on 1.0. I believe we're far enough feature-wise, and quite
close to the required stability. Therefore I'd suggest we set a date
now, then make another review of the open issues and keep only those
that can reasonably be fixed by that date. At the same time, declare a
freeze for new features -- say, a month from now -- and concentrate on
expanding the test suite.
Wouldn't you agree that April 1 is an auspicious date for a 1.0 release? :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org