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

Re: First 1.7.0 prerelease: June 1

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 18 May 2011 08:52:16 -0400

On Wed, May 18, 2011 at 07:43, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, May 18, 2011 at 7:25 AM, Greg Stein <gstein_at_gmail.com> wrote:
>
>> If solving these were easy, then I believe they would have been done
>> by now. We're down to the hard issues, and people don't have a high
>> degree of confidence in planning when they would be done.
>
> We are not the only software project in the world working on hard
> problems or that finds it difficult to provide estimates.  It sucks,
> but part of being a professional is doing the best you can.

Do you think that you can plan around *volunteers*? Or for those
employed to work on svn, how much time they will have available? And
has each of these employees specified their available time, what
they're working on, and how long it will take them? Has all of this
been collected across all of these volunteers into a workable plan?
... Nope.

My point was that I don't see anybody doing this. If you'd like to
start collecting such a plan and hitting up each person to assemble
it, then please... by all means. I just don't see it happening from
the people here doing the coding.

>  We have
> single-digit issues.  We ought to be able to provide a date on when we
> think the release will be ready and then push each other to meet that
> deadline.

Only if we knew everybody's time commitments. I don't know mine; I
have no hard schedule. Do you have the schedules for the Collab.Net
employees? That would solve part of the problem.

> I also have a feeling that people think there are other items not
> captured in the tracker.  That may be true, and I am saying you need
> to push each other to unlock that information and get it captured in
> the tracker.

Yes. People are not confident that we've capture everything in the
issue tracker. Go ahead and apply "push" as you deem appropriate.
We've been talking about it here, but we certainly haven't pushed each
other so far.

>> I'm also not seeing anybody here standing up and whipping us into
>> coming up with a date. People seem pretty content with "we're working
>> on it as best we can."
>
> Consider yourself whipped :)

Doesn't work on me :-)

> Seriously though, who or what are you expecting?  A lot of people have

Turn that around: what are YOU expecting. Hyrum said we would start
cutting releases on June 1. What else would you like?

> probably just given up or are numb from the 2+ year release cycle we
> are on.  It is not just about declaring a date, hitting it and
> releasing the software.  It is also acknowledging there is an
> ecosystem downstream that uses the software and has to make their own
> schedules around it.

I think we're all aware of this. I also think that we're working on
getting the last bits wrapped up. Maybe it isn't the form that you
would like?

>  I would like to be able to do a Subclipse
> release concurrent with 1.7.  I need to be able to budget time to make
> the adjustments needed for 1.7 and handle my own release process.  We
> use Subversion in our enterprise products and need to be able to plan
> releases around making Subversion 1.7 available in those products,
>
> Give the community a date.  If it doesn't look like you can hit the
> date, then update the community with the new date and move on.  It
> seems like the shame in possibly missing a date is being given too
> much weight.  The community still wants and needs those dates.

June 1, we'll start some early releases. So far, there isn't anything
further to say, with confidence. If you have ideas on how to make
statements with greater confidence, then please do so. I don't think
it will be coming out of this room.

Cheers,
-g
Received on 2011-05-18 14:52:45 CEST

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.