Re: Two weeks to feature freeze

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 could also help developers stay
focused on particular projects since they are the "hot potato" for a
given release. It could also help people plan better since they would
know that foo is coming in the next release.

> If it takes foo 6 months to develop, I'd rather have the release happen
> after 4 months as per normal (or close to it) and have 'foo' brought in
> part way into dev cycle 2 ... at least then, if 'foo' ends up taking 7
> months, we aren't delaying even further ...
>

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.

> Its not like our dev cycles have 'idle periods' where nothing is happening
> and we're waiting for a feature to come along ... there is *alot* of
> changes going on that affect alot of ppl that don't really care about
> feature 'foo' coming along ...
>

this doesn't really change anything for those folks, since the only
rational is "every 6 months we do a release." ie. there are *alot* of
changes going on that affect alot of ppl that don't really care about
waiting n more months...

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?

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL