This is a real bug in our Jira setup that I have written about
before. I am not enough of a Jira expert to say if it can be fixed.
The problem is that:
1) Before a bug is fixed, we use Fix version(s) to say the version we
would _like_ to see it fixed in. Developers use this to schedule and
prioritize.
2) After a bug is fixed, we use Fix version(s) to say the version it
actually got fixed in. QA uses this to decide when and where to verify.
See the problem? What if a fix is targeted for trunk _and_ a point
release (branch)? It won't be fixed in both places simultaneously, so
there is a Schroedinger state where the bug is both fixed and not
fixed. :P
Right now, we have a point release in progress, 4.2.0.1, that is
intended to fix 'show-stopping' bugs in 4.2. If you feel you have
such a bug (and fix), you should propose that that fix be integrated
to 4.2.0.1 on laszlo-dev, arguing the risk/reward. We are not taking
_any_ risky fixes in 4.2.0.1.
Bottom line: All work is done in trunk which is slated to be released
as 4.2.1, so that's where _you_ the developer should mark it fixed.
If you propose and it gets accepted, I will integrate the fix for
4.2.0.1 and mark it so.
Thanks, and sorry for the confusion... I'm new to this 'branch
manager' stuff. I'm sure it could be handled better.
On 2009-01-08, at 23:27EST, Sarah Allen wrote:
Hey all,
Not sure what fix version to pick when marking bugs fixed. I just
fixed:
LPP-7186 videoview dose not appear when camera's 'show' is true at
initial
LPP-7585 videoview doesn't use declared width and height in this
specific case
and chose 4.2.0.1... is that right? should I always just pick the
first in the list?
Sarah
