Jen,
One thing that can help is when the fix-for version is set to the
upcoming version. Then when I'm releasing that version I can update the
metadata when the issue is deferred. The same act that updates the
issue to reflect the reality that it wasn't fixed for that version can
include updating the issue to reflect that it therefore affects that
version.
This approach works well when there are few unresolved issues.
It would be really healthy to cull the list of known issues down to a
reasonable number. By fixing them. I think that's becoming more and
more feasible as we see the developer community experience a
revitalization (the Denver JA-SIG conference was beautiful in this
regard). While I really don't mean to harp on Unicon's Cooperative
Support program over and over on this list, I do hope that from a
uPortal developer community perspective having miore bandwidth to go
after the niggling little issues and cut a swath through them, resolve
many of them, is a boon the program can bring to the community in the
near future.
uPortal is a strong project of which I'm a fan. One pathology we've
had, however, is many small issues that don't get addressed in a
reasonable timeframe. I see part of "platform maturity" as endeavoring
to fix that.
[
Are we expected to go through open JIRA tickets every time a JIRA
release is added?
]
"Expected" is too strong, but it would be nice if you did. In general
any issue needs a requestor who owns the aspect of wanting it to be
fixed. That requestor needs to articulate why we should care about this
issue, and either fix it or find someone to nag to fix it. If the
requestor could take some ownership over keeping the issue metadata
up-to-date, that would be awesome, and would distribute the workload.
"Darn, I see Andrew released a release but my issue's fix didn't make
that release. I guess I've gotta update it to reflect that it's *still*
not fixed. And while I'm at it I can update it with the latest
understanding of the issue, and I can ping my developer resource about
could he please fix that in time for the next release..."
Andrew
Jennifer Bourey wrote:
OK, done.
Just out of curiosity, how are these affects-version attributes
maintained? Are we expected to go through open JIRA tickets every
time a JIRA release is added? I believe this ticket was created
before RC2 was released.
- Jen
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
