Monthly Archives: March 2017

New Sakai Project Management Committee (PMC) Members

I am pleased to announce four new members elected to the Sakai Project Management Committee (PMC). Here are the new members and the nomination statements for each:

Wilma Hodges, Longsight
Wilma has been a long-time community supporter and Apereo Fellow. She leads the documentation effort, participates in the Apereo FARM effort, leads the Sakai Virtual Conference, and participates in the Sakai Marketing effort and other community activities.

Dede Hourican, Marist
A long term community member, Dede has most recently directed focus on quality assurance with participation in the Sakai QA committee bringing a team of Marist student employees to bear on the process and teaches them about open source software and global communities and building future sakaigers.

Diego del Blanco, Unicon
Diego has been very active in the Sakai community for some time now and Apereo Fellow. He has been a regular attendee of the weekly calls, made significant contributions to Sakai 11 and put in some large features for 12.

Shawn Foster, Western
Shawn is highly active on community calls, provides code contributions, and is tightly connected with the very important usability and accessibility efforts within the Sakai community.

PMC membership is reflective of significant contributions to the community and a dedication to the shared goals of the Sakai community.

In terms of what PMC membership “means”, the PMC members are already active members in the various groups in the Sakai/Apereo community (QA, Core Team, Marketing, FARM, Accessibility, Teaching and Learning, etc.). Most of the decisions about Sakai are made in those groups without any need for the PMC to take a vote or render an opinion because we believe that those closest to the actual work should make decisions regarding the work whenever possible.

The PMC[1] gets involved when there is a significant or broader issue or a decision needs to be made regarding Sakai’s direction or resource expenditure by Apereo[2] on behalf of Sakai [3]. The PMC does all of its work in full view of the community on a public list[4] except for votes on new PMC members.

Please join me in thanking these new PMC members for their past, present, and future contributions to Sakai and welcoming them as the newest members of the Sakai PMC[5].

Should ICLAs be Required of Every Contributor?

Update: Title changed from “Committer” to “Contributor” based on a suggestion from Andrew Petro (see comments)

In Apereo/Sakai there is discussion of whether or not we need to doggedly require Individual Contributor License Agreements (ICLAs) from every person who sends in a simple github PR. It is generally agreed that if someone will be making significant contributions we need an ICLA – but many (myself included) feel that an ICLA is not necessary for a simple submitted patch. The issue is that this leaves a grey area and soe folks stay a bit conservative on this.

Andrew Petro did some research on this and here are his notes. I keep them here for my own reference.

Here is the thread where we discussed this:
https://groups.google.com/a/apereo.org/forum/#!topic/licensing-discuss/c1puG3RKZcA

Since this post, CLAs have come up a few times on Apache legal-discuss@, including in July when I brought up Apereo’s desire for a canonical position.

In February 2017, “it is considered good practice to collect individual CLAs even if the contributors are not committers. Strictly speaking this is unnecessary”. That is, Committers and Projects via their PMCs may require CLAs of Contributors rather than just only of Committers, and it may be a good practice for them to do this under some circumstances, but Apache does not strictly require this. Also, this post again confirmed that while it is a good practice for Committers to secure Corporate Contributor License Agreements of their employers, this is a judgment call on the part of the Contributor.

In December 2016, “our IP provenance relies on both our license, our ICLA/CCLAs, and the fact that we have written policies that define who can be a committer and how PMCs can make releases. It’s usually good if a code author (or someone who could otherwise legally sign an ICLA in terms of granting us the right licensing rights to that code) actually submits the work to some Apache project before we put it in a release.” That is, it’s sufficient that an ICLA-signatory Committer actually merges the code into the canonical codebase.

In August 2016, “To avoid the risk associated with clever or large contributions, most PMCs request a formal ICLA to be filed.” Which is to say that some do not, and that therefore Apache does not require that projects do so; individual PMCs get to locally decide when to go beyond requiring ICLAs of Committers to require it of a Contributor in the context of a given Contribution.

In August 2016, on this very topic, “I don’t see that there’s a ‘canonical position’ that can exist.” and “Stating my understanding of the Apache policy – Apache requires ICLAs of its committers, uses ICLAs or a software license (https://www.apache.org/licenses/software-grant.txt) for exceptional contributions from contributors and generally relies on clause 5 of theApache License 2.0 for other contributions from contributors.”

There have been opportunities for someone to argue that ICLAs are required of all Contributors, and that position has not been argued on legal-discuss@.

I think it’s also looking likely that this is as canonical a position as one can get from Apache on this matter.

Silex Bridge to Old-Style PHP Sessions ($_SESSION)

I am exploring the Silex framework. I am trying to gently evolve a very nice app from “old school PHP” to “new school PHP”. I have chosen Silex (atop Symfony) as my first framework to try. I like Silex so far because it helps me without lecturing me. I cannot rewrite my whole app overnight – I need to evolve to a Silex App, one feature at a time.

This code uses the Symfony PhpBridgeSessionStorage – and it makes me very happy.


<?php

// http://localhost:8888/silex/hello/bob

use Symfony\Component\HttpFoundation\Session\Session;
use Symfony\Component\HttpFoundation\Session\Storage\PhpBridgeSessionStorage;

require_once "vendor/autoload.php";

session_start();
$session = new Session(new PhpBridgeSessionStorage());
$session->start();
$app = new Silex\Application();
$app['session'] = $session;

$app->get('/hello/{name}', function ($name) use ($app) {
    echo("<pre>\n");
    // New Session
    if ( $app['session']->has('y') ) {
        $app['session']->set('y', $app['session']->get('y')+1);
    } else {
        $app['session']->set('y', 20);
    }
    print_r($app['session']->all());

    // Read and write old session
    if ( isset($_SESSION['x'])) {
        $_SESSION['x']++;
    } else {
        $_SESSION['x'] = 42;
    }
    print_r($_SESSION);

    echo("</pre>\n");
    return "<p>Hello $name</p>\n";
});

$app->run();

Sakai Release History (From Matt Jones)

As the Sakai community discuss the timing for the release of Sakai 12, Matt Jones of LongSight went back into history and summarized Sakai release activity for the past 5 years to help inform our plans for the Sakai 12 schedule.

I would add to the information that Matt shares below that Sakai 2.9 and Sakai 11 made a lot of forward progress with new/revised UI/UX features and Sakai 2.8, 10, and 12 put a lot of effort into performance, reliability, and scalability and contained less new UI/UX.

I am recording Matt’s notes it here so I don’t lose them. He did a lot of work to get these details. It also shows how much community effort (and Matt Jones work) work goes into Sakai releases.

From Matt Jones:

I looked at all of the past releases, some takeaways from below

  • The branch to release for the previous two releases (10 and 11) was about the same, 5 months. 10 cut earlier and was released earlier than 11.
  • Even though no release has done branch to (actual) release faster than 5 months, we have planned 2 months for 12
  • The time from .0 to .1 for 11 was 1 month, but for previous releases previously was longer, about 3 months (which is our ideal)
  • The longest time from branch to release was 2.9, almost 13 months
    Sakai 2.8 actually had a Q1 release with Q4 branch. 2.9 was on track for the same but delayed significantly (And ended up with a Q4 release)

Historically there looks to be about a 1-2 month delay from plan to release
Sakai release history 2.8 – 12

Sakai 12
Branch cut: Earliest possible seems 2017-03-22
Release planned: 2017-05-19
Actual release: ???

Sakai 11
Branch cut: 2016-02-17
Release planned: 2016-06-24
Actual released: 2016-07-23
.1 release 2016-08-13

Sakai 10
Branch cut: 2014-01-30
Release planned: 2014-04-30
Actual release: 2014-06-27
.1 release 2014-08-21

Sakai 2.9
Branch cut: 2011-10-17
Release planned: 2012-06-15 (This may have been planned for earlier)
Actual release: 2012-11-09
.1 release 2013-02-07

Sakai 2.8
Branch cut: 2010-09-25
Release planned: 2011-03-01
Actual release: 2011-04-18
.1 release 2011-10-12