feature freeze, and release date (was: svn 1.0 in 2006 or now?)

[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: feature freeze, and release date (was: svn 1.0 in 2006 or now?)

[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?)

[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?)

[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

Re: feature freeze, and release date (was: svn 1.0 in 2006 or now?)

[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?)

[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?)

[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?)

[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