[WG: Sakai QA] [Building Sakai]KNL-155/SAK-16036/SAK-800:Resources archive filehandling issues

Noah Botimer botimer at umich.edu
Mon Apr 20 15:22:27 PDT 2009


Anthony,

Thank you for working through this. I know this has been a touchy  
thread and I certainly appreciate your attention to it. I think this  
is a practical interim solution.

Looking forward, I would personally advocate for this feature to be  
reverted unless we have a commitment to finishing it and a timeline.  
Otherwise, to me, it's a great, unfinished feature. Moving it outside  
of 2.6.x, finishing it up, and evaluating it as a new piece of  
functionality seems appropriate.

I agree that this issue does offer us an opportunity to consider  
communication and testing of features, especially those in the  
kernel, where there is some sense of higher walls than in other  
areas. Handling of properties/configuration is also well worth some  
discussion.

Thanks,
-Noah

On Apr 20, 2009, at 5:30 PM, Anthony Whyte wrote:

> I've polled the K1 committers with binding votes (Ian Boston,  
> Stephan Marquard, David Horwitz, Beth Kirschner, Seth Theriault,  
> Ray Davis and myself) and the majority opinion (with two dissents  
> and one did not vote) is to leave in place the property setting I  
> implemented in order to hide the archive compress/decompress option  
> that is added to a hashmap in the kernel (K1) before being passed  
> to the resources tool as options in an action dropdown list.
>
> Yet there exists a good deal of discomfort about this approach  
> amongst those in the Community who have voiced their opinions on  
> the list.  I think it important to take account of this advice.  So  
> I am going to comment out the property "fix" in kernel /content and  
> remove the property added to /config *.sakai.properties.  While I  
> think the property wrapper a workable temporary solution to a  
> challenge we have regarding 2.6.0 the lack of overall Community  
> consensus renders the fix less than ideal in my mind.  In addition,  
> I received suggestions that the property be left undocumented in  
> order to further mask the option of enabling the zip compress/ 
> decompress feature.  I think this is a bad idea.  When people start  
> talking about hiding properties implemented to hide code  
> (experimental or challenged) then it's time to jettison the overall  
> idea (and implementation) and opt for a different approach.
>
> Commenting out this code is a temporary solution (as was wrapping  
> it in a property).  It is not a replacement for either fixing it or  
> removing it and relocating it to a branch where the issues  
> associated with it can be addressed.   Sophisticated users can hack  
> the code themselves although it means they will have to modify both  
> the kernel and Sakai to enable the functionality.
>
> It's been an interesting thread and I hope we discuss at least some  
> of the issues raised on list or at Boston.  Several themes come to  
> mind:  patch/merge management, tracking and support of committed  
> features; and sakai.properties strategies.
>
> Cheers,
>
> Anth
>
>
> On Apr 20, 2009, at 12:44 PM, Adams, David wrote:
>
>> The problem with properties like these is that they never quite  
>> tend to
>> go away, or if they do disappear from the code, they hang out in the
>> production properties file where no one wants to make a change that
>> isn't well understood.  The stealth tools list is a little  
>> different, in
>> that it can be used to hide tools that may be production-ready, but
>> aren't something we want users to be able to add themselves.
>>
>> Back to the point: IMO, properties that toggle features should be  
>> clear
>> and specific in their naming and those names should stay stable  
>> across
>> versions of Sakai. Further, the right way to deploy "experimental"
>> features (in other words, not well-tested) is to deploy a different
>> build of the tool with those features. "Experimental" code should  
>> not be
>> in the release. If it's too difficult to back this one out before  
>> 2.6.0
>> final, then I think there should be a plan for either completing or
>> removing the relevant code for 2.6.1. Leaving in something half- 
>> complete
>> is just begging for trouble and confusion later.
>>
>> David Adams
>>
>>


More information about the sakai-qa mailing list