Re: [wmvs] Open Issues for 0.7.0

* Terje Bless wrote:
>>Identifying all these issues (as in, what needs to be done to put HEAD
>>into a state that could replace 0.6.7) is what I've understood your
>>action item to be so we can see how to resolve these issues, publish a
>>beta version to identify and fix remaining issues and then release a
>>stable 0.7.0.
>
>Then you should have made sure the action item was phrased as «Terje to find
>all bugs, fix them, and release 0.7.0 ASAP.» :-)

Well, you said that merging HEAD and 0.6.7 would result in a number of
issues in the relevant meeting which seemed to imply that you know about
the issues, there is not much about finding additional issues or fixing
them in that. The whole point is that we all know about these issues to
see how to get them fixed so that we can release a beta version which
would be the best way to find bugs that you (or anyone else) do not know
about yet.

>Fair enough if you think your time is better spent on writing the modules
>— and I think we're all very much looking forward to the day we can call m12n
>«finished» — but I sure could use a hand in getting 0.7.0 ready.

See above. In order to help you, one would need to know how, what is it
exactly that needs to get done and who takes care of that. My concern is
that if someone checks out HEAD and starts testing things and attempts
to fix issues, he'd run across many things that are already known but
not yet mentioned anywhere or things others are working on, things that
would be fixed by some other bug fix that is pending in some sandbox,
etc. Hence, working on the assumption that you know code and issues
best, the best approach to get 0.7.0 ready seemed to be to let you list
the issues that you know about that need to be dealt with. I for one
still do not know what needs to be done to make HEAD a replacement for
0.6.7.

>Any bug marked as a blocker for the 0.7.0 release can get dealt with one of
>two ways; it can be «CLOSED FIXED», or it can get retargetted for a later
>release. Either is equally valid, and the only reason I'm not turning you
>loose on that list is because you've made it clear your views on what is «in
>scope» for 0.7.0 is at one extreme of the scale (i.e. you'd most likely defer
>_everything_). I'm aiming for somewhere in the middle, but I'm explicitly
>asking for you (all of you) to help me tune where on the scale we should land.

I think targetting bugs without allocating resources for fixing the bug
(i.e., someone agrees that a particular issue needs to be resolved for a
specific release and accepts an action item to take care that it gets
resolved soon) is rather pointless. If we want to release often, we
can't commit to more than ten issues for a release and even ten is a
lot.

For #856 there are about 40 issues that apparently should be resolved
for the next release, that's clearly too much. Rather than planning to
resolve all or most issues for each release and asking why not, we
should have some justification why something should be resolved in the
next release. I think we should keep in mind that every bug fix or other
enhancements makes the service better and we should see how to make this
improvement available to our community as soon as possible. Here in
particular the templating code is valuable to those who seek to provide
a localized version of the Validator, why not release it ASAP?

Received on Saturday, 4 September 2004 18:17:33 UTC