[Building Sakai] 2.7 update

David Horwitz david.horwitz at uct.ac.za
Tue Sep 29 08:53:30 PDT 2009


Hi Chuck

> This is fine as long as the only thing that is happening is source
> moves and artifact renaming.   I would suggest *not* changing package
> names or API signatures for the moved code until after 2.7 - this way,
> if patches need to move backwards or forwards, the only thing that
> changes is where the patch goes in the source tree (at least for 2.7).
>
> Lets not make API changes simply to make package names "prettier".
>

That is exactly what I propose.


As 2 the gradebook change I had 2 aims in mind:
1) Rationalize the our dependencies (as we did with k1) to enable the
tool releases and at the same time keep Sakai fairly modular.
2) Prevent the forking of code and effort in the community maintaining 2
sets of code.

1) Is where my self interest lies. However examining the code shows that
simply isolating the gradebook service won't suffice because that gets
us stuck in another set of dependencies. So modified proposal:

*2) Create edu-service package (was Separate Gradebook Service from tool)
*Create a package of common teaching service (open to name suggestions
for it). The list of services to include:
a) gradebook service
b) coursemanagement service
c) sections service

D


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090929/c4234853/attachment.html 


More information about the sakai-dev mailing list