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

[Ray Davis]

My apologies to Anthony and others for being unavailable these last 
couple of votes. My internet access is extremely scattershot at present, 
and will likely remain so through late May.

On the more general issue, I'd tend to agree that new pre-release 
functionality that's known to be buggy should be activated in a 
(publicly accessible) branch until it's ready for general prime time. My 
hope would be that the slightly greater pain of maintaining the branch 
would be some incentive for the dependent institutions to fix the new 
functionality and move it back into the trunk.

On the *most* general issue, I think I've already expressed my view: So 
long as Sakai remains dependent on volunteer labor from developers 
employed at individual institutions, it's wisest for it to reign in its 
ambitions as much as possible. Over and over again, we've been 
blindsided when talented energetic people, with the best will in the 
world and with the blessing of their employers, get something 
"finished," and then get pulled into something else leaving the area 
without maintainers. I've been on both sides of this problem many times 
already in Sakai's history, and I don't see a way around it given the 
current project structure. Our institutions have the resources to 
provide excellent work in short bursts, but not the resources to support 
that work indefinitely when it's less of a local priority. (Which is 
where a lot of Michael Korcuska's recent Development Process proposal 
comes in, and why it's so important to rely on non-Sakai-specific open 
source projects whenever we can.)

Best,
Ray

On 4/20/2009 3:22 PM, Noah Botimer wrote:
> 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
>>>