[cle-release-team] Decision: managing blockers on 2.9 release

[Matthew Jones]

I agree on ones like that one, and the biggest thing that left it as a
blocker (IMO) was that nobody tested and provided the Oracle conversion to
clean up old templates. I don't have access (or strong desire) to test on
anything Oracle related. I'm actually actively working on converting some
clients from Oracle to MySQL. The other issue you mentioned on the ticket
I'm betting would be easily remedied, but without a conversion that allows
people to apply the unique constraint as part of the conversion we couldn't
leave that in that, as annoying as it is.

And it doesn't entirely meet the criteria for blocker as it generally isn't
a severe problem. The query returns the last modified template and it's
possible to clean up old templates. (Even if there is no delete button on
the UI either)

Anyway, perhaps some criteria should be attached to the blocker, do
developers actually care enough to fix this that someone *is* going to fix
it before the next release? ("Issue will most likely get resolved for the
release"). I can say I'm annoyed with it but not enough to prioritize it
over something else, and I could live with it existing, since it's been
broken since 2.8.

I think the bigger question about tickets marked as blockers was this one
though  https://jira.sakaiproject.org/browse/KNL-797 We downgraded this
from blocker because it was code that had existed in Sakai 1.x, and while
some fixes were proposed, there were some disagreements about the fixes and
nobody stepped up to test them or offer anything better. This doesn't seem
like it should be something blocking the release of 2.9.0, as big a deal as
it is. Though if it got successfully fixed it would be awesome for sure.
I'm skeptical if any sort of exception handling (and rollback) logic will
fix this though, it really feels like it needs to be a UPDATE on the
database rather than a DELETE/INSERT.

On Fri, Aug 17, 2012 at 9:48 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> My only concern is that some existing blockers might get downgraded since
> they aren't new regressions. There are some serious ones in there. The one
> that springs to mind is the Email Template Service issue. Many tools depend
> on it and its pretty hosed. We run the risk of issues like these getting
> 'lost' and then never worked on.
>
> A better approach might be to review the requirements for each level (like
> you've done below) then go through the current issues and if they aren't in
> the correct level then change them. If a blocker is a blocker, then it
> should stay a blocker IMO.
>
> cheers,
> Steve
>
>
> On 18/08/2012, at 5:02 AM, Matthew Jones <matthew at longsight.com> wrote:
>
> I agree, we really don't have great sense from the past on what we want
> the priorities to mean. When issues are created they're assigned the
> priority "Major" and increased by the reporter or someone afterward. Here's
> what the workflow says:
>
>  Blocker - Release will not be completed until issue is resolved. An
> example would be a severe problem that bridges multiple tools, or prevents
> core functionality in one tool.
>  Critical - Issue will most likely be resolved for release.
>  Major - Issue should be resolved for release.
>  Minor - Issue may be resolved for release.
>  Trivial - Issues that might be resolved before a release.
>
> It feels like a Blocker would be as you say "A new issue both a regression
> from previous releases and a easily reproduced severe problem that
> bridges multiple tools, or prevents core functionality in one tool. "
> Critical would for issues that have existed in past releases that may
> prevent a secondary functionality in one tool. Or for difficult to
> reproduce, randomly occurring severe problems.
> Major would be more for any general problem that doesn't prevent
> functionality but results in a less than ideal user experience
> Minor/Trivial could be defined similarly.
>
> I believe the definition of "should be resolved/may be resolved/most
> likely resolved" is completely misleading. ;)
>
> This would also allow us downgrade some
> incorrectly categorized criticals back to major so we know what developers
> really needs focus on and what things to look out for.
>
> On Fri, Aug 17, 2012 at 2:45 PM, Neal Caidin <
> nealcaidin at sakaifoundation.org> wrote:
>
>> Hi All,
>>
>> At the last CLE meeting, which I know a lot of you were unable to attend,
>> we discussed getting 2.9 into GA (general availability)  aka Production
>> release, or whatever you like to call it. As part of the process to get the
>> release out we propose that we keep as Blockers only new regressions, with
>> the rationale that if a blocker is in production for 2.8.2 then we can
>> probably live with it as a blocker for 2.9.0 (which means, in effect, that
>> it won't really be considered a blocker for the 2.9.0 release).
>>
>> Does anybody have any objections to this approach? If so, please voice
>> your concerns over email, or at latest by attending next Thursday's CLE
>> meeting.
>>
>> Thanks,
>> Neal
>>
>>
>>
>>
>>
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20120817/1cfba50d/attachment-0006.html