Re: Two weeks to feature freeze

On Tue, 24 Jun 2003, Robert Treat wrote:

> On Mon, 2003-06-23 at 21:36, The Hermit Hacker wrote:
> > On Mon, 23 Jun 2003, Robert Treat wrote:
> >
> > > > The target-date-based approach we've taken in the last couple of
> > > > releases seems much more productive.
> > > >
> > >
> > > productive on a small scale; for sure. productive for large scale
> > > features...  well, that's why it's being discussed.
> >
> > 'K, but if we extend the dev cycle in order to get 'foo' in, how is that
> > better then having 'foo' continue to be developed thru the release and
> > committed in the next cycle?
> >
>
> I think it makes it easier to code 'foo' since you're not coding against
> (quite as much of) a moving target.

I *soooooo* disagree with this one ... the only way that postgresql is
going to stop being a moving target so that someone can code 'foo' is if
everyone else goes to sleep until that happens ...

> It could also help people plan better since they would know that foo is
> coming in the next release.

'K, that helps the end users, but that doesn't do anything for the person
developing 'foo' ...

> i'm sure everyone who doesn't want foo would agree with that position.
> The counter though is those folks who did want foo but now have to wait
> 4-6 months for the next release since foo took a month longer to develop
> than was initially planned.

Ya, but, based on past experience (hell, this release has been a good
example) ... you delay the release because developer of 'foo' figures "oh,
it will be ready in another month", and then something comes up that
causes that "commitment" not to happen, so we delay it "yet another
month"?  And I'm not saying that the second delay was due to
mis-estimating the time needed ... suddenly getting really busy on a
contract, a day job, a death in the family, etc ... you cannot predict
what could cause a delay, or how long such a delay would take ...

> the whole discussion is based on how do we get big projects done when no
> one is motivated to work on 'foo' until there faced with a deadline;
> this idea puts the pressure on 'foo' developers from the get go. i'm not
> saying this a guaranteed way to solve that problem but i think it is a
> possible solution. i'm sure there will be big projects most people don't
> care about (win32) and big projects most people would like (replication)
> so the amount of like or dislike of the idea would be relative in
> practice, the key question is would this actually motivate folks more to
> get big projects finished faster? since there are only a handful of
> folks who fall into that category they can decide for themselves, and if
> it wouldn't motivate them, then the question can be asked again, what
> would?

First, we already seen that such a 'pressure' doesn't matter, especially
if when push comes to shove, they know we'll postpone to accommodate them
...

Second ... I don't believe the problem *is* the release cycles ... I think
the problem that needs a solution is how to "open up" these large projects
so that the deadline(s) don't fall on ones person's shoulders to get done
.. how do we encourage/promote "work groups" for the large projects?