[sakai2-tcc] VOTE on release of Sakai 2.6.3 and Sakai 2.7.1

[Steve Swinsburg]

Unfortunately I need to change my vote to a -1. 

This issue has popped up:
http://jira.sakaiproject.org/browse/KNL-564

which relates to this one:
http://jira.sakaiproject.org/browse/KNL-380

In essence, UserDirectoryService.searchUsers never used to respect a couple of the parameters given to it, namely the first and last restrictions. Now it does and this has gone back to the 1.1.x and 1.0.x branches. However, some manipulation of these values occurs inside the logic before it's turned into a DB query:

(first - 1), (last - first + 1)

which turns it into an offset and a limit respectively.

Thus, given the values of 0 and 99 we get a limit of -1 and offset of 100. The -1 is invalid and throws a stacktrace. My suggested fix is to validate the values so that they cannot be incorrect.

Because I needed to code around this limitation (first and last being ignored), Profile2 supplies the values of 0 and 99 respectively. It wasn't broken before but now it is. 

If we go ahead with the release then searching for connections will be broken and will present a stacktrace in the logs. This is caught by Profile2 though but it means searching is incomplete.

A couple of solutions:
1. Fix it only in the kernel so that the values are validated and adjusted if incorrect (if first <= 1, first = 1), etc, then it is fixed for everyone.
2. Fix it only in Profile2 so that the value is 1 instead of 0.
3. Fix it in both.

1 will require a new kernel release for both 1.0.x and 1.1.x and for it to be adjusted in the master of both 2.6.3 and 2.7.1
2 will require a new profile2 release for the 1.3.x branch and for it be adjusted in the master of 2.7.1
3 will require both.

I propose that I fix this in Profile2 and push a new release that 2.7.1 can bind to. This can be adjusted in the master and then the release of both 2.6.3 and 2.7.1 goes ahead. However, users that are running an older version of profile2 will notice this bug since the fix has gone back to the kernel for 2.6.x. So ideally it should be fixed in the kernel as well, however that need not hold up the release.

All up this will take less time to fix than I spent writing this email. 

Thoughts?

cheers,
Steve




On 19/08/2010, at 10:58 PM, Seth Theriault wrote:

> Anthony Whyte wrote:
> 
>> Stephen has addressed SAK-14202.  I move that the TCC chair 
>> schedule a vote on the question of releasing sakai-2.6.3 and 
>> sakai-2.7.1.
> 
> The motion is seconded (by your chair) and is now OPEN for 
> voting. The vote will remain open until 23:59 UTC on Monday, 
> August 23, 2010.
> 
> As a reminder, this is a public, on-list vote with a "+1" 
> signifying "approval to release."
> 
> Per our governance documents, a -1 vote must be accompanied by 
> a detailed explanation. A single -1 vote based on a material 
> objection will block action. However, -1 blocking votes can be 
> overridden by a 2/3 majority roll call vote of active TCC 
> members.
> 
> Assuming TCC approval, the generation of release artifacts,
> etc. will begin on Tuesday morning.
> 
> Seth
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100820/6dea6942/attachment.html