Just interested is anyone in the community planning on working on any
of the any of the unassigned below? My vote on whether to hold up
a release or not based on them might be affected by if there was any
chance someone might be fixing them. Otherwise I probably would lean
toward getting the release out with known bugs documented, it of
course depends on the bug. For me there are currently no issues (other
than legal) which I would hold up the release for. For me the last
release blocker is DERBY-1686 which is fixed in trunk and should go
to 10.2 in the merge tommorow.
For me 1782 would not be a blocker as the documentation has been updated
to describe the current behavior
and the specific behavior seems somewhat open to interpretation (but I
am no expert in this area).
Also I would tend not to hold up a release for minor bugs in new
behavior, that is what release notes are for. My assumption is that
even more bugs will be uncovered once the new behavior is exercised,
better to release, get feedback and get another point release out there
soon. Unfortunately my feel from the beta process is that we are not
getting a lot of usage.
1806 and 1777 are interesting as they are from the beta usage, and seem
to be regressions. I haven't followed closely, it seemed like 1806 was
going to be hard to do anything about without some more info on a repro.
Looks like 1777 also still has problems with the repro.
Note that anyone in the community could help with regressions, it
does not take expertise with the code - a big help could just be
narrowing down to what change in 10.2 caused the bug (assuming a
reproducible case). Anyone good at writing scripts that would
automatically do a binary search on a SVN client, build, and test to
narrow down to a specific change when a caused a test to fail?
Rick Hillegas wrote:
Thanks, Dan. This is great feedback. I am glad that you feel 10.2 is so
close to generating a release candidate. Based on feedback from you and
Mike, I have downgraded the urgency of some issues. The following 6
urgent issues remain:
Regressions:
1806
1777
New behavior that violates our governing standards:
1782
Untested new behavior:
1522
Failure in new behavior:
1589
About to be closed:
1765
I'm happy to hear arguments about why some or all of these issues should
be downgraded to the point that they don't block 10.2.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Thanks to everyone for your help in whittling down the list of urgent
issues. Now we're down to 6 unclaimed ones. That's good news although
still not good enough to cut a release candidate.
I didn't realise that you view urgent issues as blockers for a release,
I was working on the assumption that a bug had to be marked as critical
or blocker for it to block a release.
Looking at the list of urgent issues that are not blocker or critical
(in fact there are no blocker/critical 10.2 issues) in my view some, if
not all, would not block a release, e.g. DERBY-1746 need to test with
10.1.3 for upgrade, why is it important to be testing with 10.1.3 as
opposed to 10.1.2, probably equally likely a user will have either
release.
It is your choice as the release manager, but once all legal hurdles
have been resolved (or Mustang releases as GA :-) I would hope we as a
community could issue a release as soon as possible, and not wait for it
to be perfect. E.g. DERBY-1664, created one day after the initial code
"freeze" target, since then not much interest from anyone, seems a
little late and unrealistic to make it a blocker for a 10.2 release.
Dan.
