[Deploying Sakai] [Building Sakai] Trunk: ui package proposal

[David Haines]

Seth,

	I'm not sure what the problem is here. You have to patch and build  
the project now anyway, you just have to patch and build everything at  
the same time (which I don't see as a fundamental advantage).  Is the  
issue mostly keeping track of what projects have been patched and  
built when they aren't done in a single mass build?

	I do think we are conflating a few different things under  
"independent release".  The new core services packages aren't really  
independent releases. There is no point in having to recompile stable  
code that hasn't changed for months. Repackaging code to create stable  
artifacts is a good idea. However that shouldn't be considered a  
separate release of that code.  Separate tools like Samigo should  
truly be an independent release.  Those are option and there is no  
reason that a release of an improved Sakai as a whole should depend on  
the state of the Samigo code.

	If you need to patch non-Samigo code to release Samigo that is a  
different problem and should be addressed as a bug.

- Dave


David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines at umich.edu



On Nov 9, 2009, at 5:40 PM, Seth Theriault wrote:

> Anthony Whyte wrote:
>
>> If we add velocity to the "ui" package for 2.7 the impact is
>> greater.  This is due principally to a short chain of
>> velocity-courier-presence dependencies that must be confronted.
>> Releasing velocity independently will require releasing both
>> the courier and presence independently.  People might not want
>> to do this for 2.7.0.  For myself, I think prepping these
>> projects for an independent release no big deal but others may
>> think it best to go slow.
>
> [Cross-posting to the production list]
>
> So that folks are aware, there are now several packages (kernel,
> edu-services, Samigo, etc.) with "independent release" status
> being readied for 2.7. While this approach offers some benefits,
> I fear there is the potential for increased work for deployers
> and more production-minded folks as a result.
>
> Why? Because for every package that attains "independent release"
> status, deployers who have local changes or patches or
> differences now MUST build and deploy their own versions of the
> affected package. As more and more "core services" packages are
> created, it is more and more likely that deployers will have to
> do this with as-yet-unknown effects.
>
> I'll give you a simple example with Samigo (which is going
> independent). Locally, Samigo is not known as "Tests & Quizzes",
> but rather, "Test & Quiz". This requires 3 patches, one of which
> is in the Help documentation. I now MUST build my own version of
> Samigo to apply this type of change.
>
> Perhaps we could slow the move to independent releases a bit in
> advance of the main 2.7.0 Sakai release and see what effect, if
> any, the new "independents" have on local deployment work.
>
> Seth
>
> _______________________________________________
> 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"
>
>

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