Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT-2.1 life cycle

> 
> Also as a customer, and non-contributing extender (except for an
> occasional bug patch), my overall concern is  in seeing as many bugs
> squashed as possible.  The effort for bug resolution in 2.1 was a great
> step in the right direction and much appreciated.  But I want to make
> sure that bugs that were "deferred" to 3.0 (i.e. chosen not to fix in
> 2.1) do actually get addressed in 3.0 (or a 2.1.x update) and not
> deferred again.  I would love for the contributors to fight off the
> subconscious urge to give preference to adding features at the expense
> of fixing existing problems. =20
> 

Agreed.

At the last conf. call Doug resumed the general feeling:
"The zarro bug policy was a good thing" 8-)
And we will continue this for 3.0

When PRs were deferred the owner usually gave reasons:
- Missing framework
- To much work with impact(side effects)
- lack of time/resources
- no fixes or owner working on this PR.

The only annoying thing was since there was no builds prior
to the 2.1 RC? the number of PRs seem to raise instead of going down
on each RC candidate 8-(, making the build available earlier may help
in the future.

> That being said, back to the exact question.  We're in favor of whatever
> version (2.1.x or 3.0) is best for a focus on bug fixes.  Our preference
> is for a version in which the existing features work flawlessly first
> rather than added new features.  A 2.1.x would be ideal since it would
> conceivably come quicker than a 3.0 version. But a 3.0 would be
> acceptable if the bugs deferred to it did get fixed and not deferred
> again.
> 

It does not loog good for 2.1.1, more +0 then firm +1.
Lets do the final tally Monday.



Back to the top