I have started contacting people who have copyrights in the main SVN. The usual case for this is when code was promoted from the contrib SVN to the main SVN and we did not change the copyright to be the Sakai Foundation.
All contributors to the Sakai Foundation code base (i.e. those with commit to the SVN) have effectively pre-agreed to allow the Sakai Foundation to have a license to those contributions. Contributors can retain their own copy with whatever license they like.
We expect that all contributions developed by Sakai committers will be committed with the Sakai Foundation copyright rather than their own. We have been somewhat lax in this and now it is time to clean this up.
Most open source communities are very strict about keeping individual names out of the source code as a form of attribution. Once something has been contributed to the commons – that contribution is no longer owned by an individual – it is owned by the commons.
This quote is from the SVN hackers guide:
“We have a tradition of not marking files with the names of individual authors (i.e., we don’t put lines like “Author: foo” or “@author foo” in a special position at the top of a source file). This is to discourage territoriality
Chuck’s Nespresso Receipe – Cafe au Lait
This is how I prepare Cafe au Lait in my Nespresso machine. But before the I describe the recipe – I should describe the requirements and expected user experience:
– There must be creme and sugar
– It must be hot – not warm
– It must make the minimum number of dishes dirty
– The crema must be perfect – undisturbed
The process:
– Take your small coffee-house style cup – put in two tablespoons of milk or cream
– Microwave the milk for 10 seconds (heats it up – so it does not cool the expresso)
– Add sugar to the warm milk – mix with a spoon to dissolve the sugar – having the milk warm makes dissolving easier
– Use Nespresso machine to put the espresso into the milk/sugar mixture
Enjoy
Compiling the kernel
Maybe you want to be the first on your block to make a patch for the new kernel. So you need to check out, modify, and compile the new kernel. You may even want to test your changes in Tomcat :)
When Ian wakes up, he might tell me that I am completely wrong – but this worked:
cd ~/dev/sakai-trunk
svn co https://source.sakaiproject.org/svn/kernel/trunk kernel
I check this out into the same directory as sakai – not inside of the sakai directory – so ls looks like this
charles-severances-macbook-air:sakai-trunk csev$ pwd
/Users/csev/dev/sakai-trunk
charles-severances-macbook-air:sakai-trunk csev$ ls -ld kernel sakai
drwxr-xr-x 23 csev staff 782 Jul 30 14:39 kernel
drwxr-xr-x 73 csev staff 2482 Jul 30 15:21 sakai
Then I go into the kernel directory and type this:
mvn -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/csev/dev/sakai-trunk/apache-tomcat-5.5.23/ clean install sakai:deploy
This is the same thing I type to compile sakai.
It compiles kernel – puts it into my maven repo and then puts it right into my Tomcat!
Voila!
My K1 Experience
I am back up with K1 – it was not so hard – My instructions are a little different than Ian’s because I use vi and no debugger. A key here is that you don’t have to switch to how Ian does his tomcat stuff – just for K1 – I did my normal process (different than Ian’s) and it all still came up fine – so whatever your process is – it should work as well.
I include my steps
Whacked the repo (per Ian)
rm -rf ~/.m2/repository/org/sakaiproject
Whacked my tomcat
rm -rf ~/dev/sakai-trunk/apache-tomcat-5.5.23/
Unzipped a new fresh tomcat 5.5.23
cd ~/dev/sakai-trunk/
curl -O http://source.sakaiproject.org/mirrors/ibiblio/maven/tomcat/zips/apache-tomcat-5.5.23.zip
unzip -q apache-tomcat-5.5.23.zip
chmod +x apache-tomcat-5.5.23/bin/*.sh
Clean check out
svn co https://source.sakaiproject.org/svn/sakai/trunk/ sakai
Full compile attempt – Failed with the following message
[INFO] Failed to resolve artifact.
GroupId: org.sakaiproject
ArtifactId: master
Version: SNAPSHOT
Reason: Unable to download the artifact from any repository
org.sakaiproject:master:pom:SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Do the master thing – as per Ian:
cd sakai/master/
mvn install
— BUILD Successful
Full compile:
mvn -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/csev/dev/sakai-trunk/apache-tomcat-5.5.23/ clean install sakai:deploy
Started tomcat – navigate to http://localhost:8080/
Viola – Sakai is back with K1
Now – I am wondering where site code went… Hmmm. I was busily working on SAK-13482 and was ready to check in – when I realized the world had just changed out from under me – that will wait until Ina gets back.
NICE WORK IAN!
Kernel 1 – In the house
Our trunk is now reorganized to define a kernel – this will be a few days of angst – the contrib folks will need to react – Ian has provided a nice XSLT to get the pom.xml files fixed with minimal pain.
This will also make the 2-5-x branch management a little more dicey for 2-5-3, etc.
Progress is needed and this is a great time to take this plunge – when we have 2.5.2 in hand – and the 2-5-x branch is in pretty good shape – and we have some time before the 2.6 code freeze.
Folks not working on the deep bits of Sakai – might want to avoid doing an update for a few days – if you are working in the new Kernel area – you pretty much need to update and help figure out the new way.
Here is Ian’s note.
Again – thanks for the fine work, Ian!
Sakai K1 Kernel Commit Policies
The Sakai K1 Kernel will be in our svn pretty soon! This is a great milestone for Sakai – it moves us toward a much more manageable source tree given the kinds of resources we have available in the community.
For me this is a welcome move back toward a “do-ocracy” – at least for this very technical bit of the code. Do-ocracy and dem-ocracy have their places – and in particular for Sakai – with a large,complex user interface that end-users touch daily – it is important to not be a pure do-ocracy. But for the deepest bits of our code – the kernel – pretty much Apache Rules need to apply here with no grey area.
Ian recently posted the following vote to the dev list – lots of folks want comfortable grey areas like we have had in the past out of necessity. As folk might expect from me – I prefer grey only when there is a reason for grey.
Here is Ian’s question:
Going forwards I would like to adopt a more Apache like policy to kernel modifications in K1… namely
1. non kernel committers have to submit patches to Jira for review
2. commits < 10 lines that dont change functionality can be committed by kernel comitters
3. all commits > 10 line that change functionality have to be submitted as patches to Jira for review, review is light weight and commit is relatively fast afterwards.
If some one wants a branch, thats fine, but the above practice still stands, they need to create a patch and submit that patch to jira.
Please vote.
Ian
Here is my answer – pretty much grey-less as you might expect :)
New Feature in SimpleLTI for Sakai – Note to Self
Add feature so that properties of the form
common.toolid.launch=String
Act as if they came from the LTI Proxy Tool Registration file with
“final” set to true. If these are set in the sakai.properties *and*
in the tool registation, the sakai.properties – wins.
For example:
sakai.simplelti.launch=http://simplelti.appspot.com/launch
sakai.simplelti.password=secret
When the IMS SimpleLTI tool is multiply registered, each common tool id
can do this separately.
Interesting Article about Dimensions of Hyena Cooperation
The following article is about hyenas – but it does show that things are never so simple in a collective organization.
http://news.msu.edu/story/5606/
Here are some excerpts:
“In a paper recently published in the journal Animal Behaviour, Smith, a student in MSU
Reacting to Michael Feldstein’s Blog Post about BlackBoard
Michael Feldstein had this excellent Blog post:
http://mfeldstein.com/connecting-blackboard-to-sakai-and-moodle/
It followed up this excellent blog post by Michael Korcuska:
http://sakaiblog.korcuska.net/2008/07/16/blackboard-sakai-connector/
I just had to comment in Michael F’s blog – could not resist… Here is my comment…
Apple iPhone (Original) Geotagging photos with iPhone 2.0 Software
This is what I know so far:
When you upgrade your original iPhone to the 2.0 software – you can do geotagging of photos.
When I pull the photos into iPhoto – and do CMD-I I see GPS coordinates. These are as right as they can be using triangulation/Wifi tricks – but they are at least *close*.
It seems that FLickr does not see the meta data yet – flick does not even know that the photo came from an iPhone.
But I am sure this will all work out.
I wish I knew a site that I could upload a photo and have it dump all the metadata.
Given that I don’t have 3G in Lansing where I live and that Geotagging was my most important feature – it means that I don’t have to rush right out to get the new iPhone – I will still get one eventually – I will just let the craziness die down a bit.