"Joshua D. Drake" <jd@commandprompt.com> writes:
> This is my take as well. This is very real, very scary things that are
> being worked on. HS should only ship after a very, very long non change
> cycle (meaning no significant bugs (or refactoring) found in HS patch
> for X period of time)... say after a full 8.5 dev cycle. I do not want
> to commit this patch and then have to yank it out 3 months from now.
In general I'm for planning large features with the potential to break
existing functionality going in the beginning of cycles. I don't think that's
the same as "no changes" though. The reason we make changes is because they're
believed to be for the better.
The point in my mind is to get more people playing with the new feature in
contexts that *aren't* expected by the developers. Developers are notoriously
bad at testing their work no matter how diligent they are they just don't
think of things they didn't anticipate when they're coding. (Which is only
logical -- surely they would have just written it right the first time if they
anticipated the problems...)
> Lastly, the last time a developer told me two weeks it was 3 months.
> Unless we get a written development plan that describes specifically
> what, when, why and how long I am severely suspect that Heikki or Simon
> have a clue on an actual deliverable time line (no offense guys).
Well, Simon's been pretty impressively bang-on with his estimates for his
*development* projects going back at least to async-commit.
The *review* process, however, is inherently hard to estimate though. I doubt
anyone will give Tom better than even odds on his side bet, even if that's our
best estimate.
Simon has been refactoring and recoding based on Heikki's suggestions as fast
as he's been proposing them though. It seems the question isn't how fast Simon
will get the work done so much as how many items we'll want to change before
committing it.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning
