> If we get to the wonderful position of having no crash bugs, we do not
> then land a whole slew of new features, however voted for they are. We
> keep the stability and work towards shipping.
What about after shipping? I'm not necessarily only talking pre-1.0
release here. Will votes matter AFTER 1.0? <grin>
> > 2. Isn't there something wrong with the process when crashers and
> > dataloss bugs aren't ALWAYS the first priority in development? Why
> No. For example, we left crashers in the old imglib for months because we
> were rewriting it.
Were developers only working on the old imglib for months (and
other crasher dataloss bugs) or were they also working on non-critical
feature enhancement requests and, therefore, NOT on the critical bugs?
(I suspect they had to have been - otherwise certain features would
never have made their way into the product.) Again, my question is
why? I know you have to have features but the point of my question
was about priorities. Why allow only critical fixes into the trunk as
a publicly perceived "deadline" is approaching? Whatever policy is in
place should be in place for all stages of development, not just the
stage that "makes you look good"... (Not to mention the fact that the
1.0 criteria are still, AFAIK, only vaguely defined.)
Jason.
