[Deploying Sakai] [sakai-nakamura] Call for feedback on Upgrade Bundle technical requirements/design

John Norman john at caret.cam.ac.uk
Sat Sep 10 08:43:38 PDT 2011


OK, I'm going to stop here. I am not challenging the desirability of a data upgrade service and I am certainly not challenging "...we need a process where all changes like this and more serious ones can be captured, documented and migration code written". When I looked at the specification work, I got the impression of a two people for 3 months sort of project and I wasn't sure that would be the biggest priority for that level of investment right now, given the resource available and the other things that need to get done. Thus the call for triage, to do the minimum for now so we can get other things done. I am not qualified to do the specification - that needs to come from the development team. Priority setting from the team leads and project manager.

I'll leave it there.

John

On 10 Sep 2011, at 15:54, Eli Cochran wrote:

> John,
> I agree that we should do this in stages. Could you elaborate a bit on which use cases you feel are "basic" and which you think are "nice to haves". I'm sure that would help Chris some up with a plan that properly scopes the project.
> 
> I know that upgrading is very critical to the pilot institutions. The way that OAE stores data makes it very easy to introduce seemingly minor changes to the data that result in user facing errors and problems. For example, a very small change to the UI to turn-off permissions on categories in personal profiles never surfaced for our users because it required a tiny data migration. Luckily we caught it in QA. (I'm not grumbling, we went to production before 1.0 so that's life.) Now that we are at 1.0 and a number of institutions are in production, we need a process where all changes like this and more serious ones can be captured, documented and migration code written. 
> 
> Thanks,
> Eli 
> 
> On Sep 10, 2011, at 1:26 AM, John Norman wrote:
> 
>> I'd like to see the problem structured a bit more into stages. It seems to me that there are some basic things that are needed immediately, but others that are potentially nice to have and apply to scenarios that we don't yet experience. Manual upgrades are a pain, but I am not sure how much return on investment this work would produce compared to other priorities.
>> 
>> J
>> 
>> On 6 Sep 2011, at 19:01, Eli Cochran wrote:
>> 
>>> Adding the OAE Pilot Support Group and the front-end devs to this thread. 
>>> 
>>> This was one of the high priorities for the pilot support group. 
>>> 
>>> - Eli 
>>> 
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Chris Tweney <chris at media.berkeley.edu>
>>>> Date: September 2, 2011 2:52:11 PM PDT
>>>> To: Nakamura List <sakai-kernel at googlegroups.com>
>>>> Subject: [sakai-nakamura] Call for feedback on Upgrade Bundle technical requirements/design
>>>> Reply-To: sakai-kernel at googlegroups.com
>>>> 
>>>> Nakamurians,
>>>> 
>>>> In the spirit of open community and participation and all those good things, I want to solicit input on requirements for an Upgrade Bundle. This is the long-awaited tool that will provide a uniform, reliable, decoupled framework for tweaking data structures from one release to the next.
>>>> 
>>>> I've put down a sketchy technical requirements/design at [1].
>>>> 
>>>> Please have a look and offer your feedback on list!
>>>> 
>>>> Thanks,
>>>> 
>>>> -chris
>>>> 
>>>> [1] https://confluence.sakaiproject.org/display/KERNDOC/KERN-2147+Upgrade+bundle
>>>> 
>>>> -- 
>>>> Chris Tweney, Senior Software Developer
>>>> Educational Technology Services
>>>> University of California, Berkeley
>>>> chris at media.berkeley.edu
>>>> 
>>>> -- 
>>>> You received this message because you are subscribed to the Google Groups "Sakai Nakamura" group.
>>>> To post to this group, send email to sakai-kernel at googlegroups.com.
>>>> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com.
>>>> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en.
>>>> 
>>> 
>>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>>> 
>>> Eli Cochran
>>> project manager, CalCentral project
>>> Educational Technology Services, U.C. Berkeley
>>> 
>>> "Software is hard" - Donald Knuth 
>>> 
>>> _______________________________________________
>>> production mailing list
>>> production at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/production
>>> 
>>> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
>> John Norman
>> Director - CARET
>> University of Cambridge
>> john at caret.cam.ac.uk
>> +44-1223-765367
>> 
> 
> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
> 
> Eli Cochran
> User Interaction Developer &
> Manager of User Experience Design
> Educational Technology Services, UC Berkeley
> 
> "The opportunity lost by increasing the amount of blank space is gained back with enhanced attention to what remains."
>     - John Maeda
> 
> 
> 

John Norman
Director - CARET
University of Cambridge
john at caret.cam.ac.uk
+44-1223-765367

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20110910/d66577c9/attachment.html 


More information about the production mailing list