The quarterly uPortal Open Source Support (OSS) Briefing is an opportunity to share the contributions performed on behalf of the OSS program, highlight Unicon's perspective on contributions, and share happenings in the community along with opportunities to engage further with Unicon.
Discussions for the Q1 2017 Support Briefing concerned maintenance development on uPortal, plans for further enhancement of the uPortal project, as well as soliciting and discussing feedback on OSS and uPortal community future priorities.
On Tuesday, April 11, 2017, the Unicon Open Source Support (OSS) Team held a briefing summarizing OSS activities for Q1 of 2017.
- Improving Processes
- OSS Mechanics
- Sustaining Engineering
- Community Spotlight
There were a number of process improvements surrounding pull requests in GitHub for uPortal. First off, a Contributing Guide was added to the uPortal project documentation. This page explains the Individual Contributor License Agreement (ICLA) and lists steps on how best to start contributing code to the uPortal project.
A new addition, the Change Request Template, was added to pull requests. This template is a checklist that is inserted in new pull request descriptions. By default, it lists common requirements. These include a signed ICLA, appropriate revisions to automated tests, conformance to WCAG 2.0 AA, etc. Since these details are in the description of pull requests, they can be edited at any time. For example, a pull request that simply updates documentation does not require test revisions, so that line item can be removed from the list.
There has also been a lot of effort on continuous integration around pull requests. uPortal 4 and master (proto-v5) are tested in Windows and Linux with Java 7 (uP4) and Java 8. Check out the slides for details (see link below). One of my favorite parts is the badge section that lists if uPortal implementations are passing the basic unit tests.
Our community update focused on uPortal 5 status and Open Apereo 2017.
Six uPortal 5 efforts were reviewed. First, the Gradle-based build is complete. Building uPortal 5 no longer relies on having Ant or Maven tools installed. Only Gradle is needed, AND it is included in the uPortal 5 repository. You basically just need the uPortal repo, GIT, and Java. Second, a lot of effort went into processing open pull requests -- some several months old. While not all of them were merged, the backlog of 40+ pull requests was reduced to under 10. Efforts still in progress for Q1 center on removing deprecated code and features. This is ongoing as we discover more code to remove. The following items are uPortal 5 efforts that were not addressed by the end of Q1:
- Decompose uPortal sources into tightly-scoped jars
- Move everything that does not go into vanilla uPortal to another repo
- Upgrade Spring Framework
Regarding Open Apereo 2017, we reminded those on the call that beside the great sessions, the uPortal attendees collaborate on the roadmap for the upcoming year. This follows the conference sessions, on Wednesday and Thursday. Plus, attending is a great way to meet other community members face to face.
We took some time to review the issue process for our OSS clients attending the briefing. In the past, there had been some confusion on the request level and resolution. We covered that ZenDesk is the tool to submit suggestions for Sustaining Engineering work. In addition, the differences between Support Assistance hours and Consulting Assistance hours were discussed. Support Assistance is unlimited in time, but it only covers basic questions about uPortal. If the team needs to look at logs, client code, or track down issues particular to a client environment, then Consulting Assistance hours are used. We also discussed ticket state, especially, "Solved." Tickets enter this state when at least one of the following occurs:
- The contact agrees that the engineer has provided a satisfactory resolution
- The contact understands there is no solution to the problem at hand and the problem is not a result of a defect
- The contact agrees the problem is due to a defect and the engineer has created a corresponding development issue in the project. The engineer has also provided a satisfactory work-around or determined no work-around is available
- The engineer has made multiple attempts to reach the contact who opened the case and the contact has not responded
The contact can reopen the case within a few days of it being marked as "Solved" if the issue is not actually resolved.
In our Sustaining Engineering (SE) section, we cover the work we have done using SE hours. When it comes to security, we fixed a issue with href having invalid destinations; and the Map Portlet was upgraded to use the patched Apache Commons Collections to address a security issue in that dependency. In addition to the process improvement in the first section of this briefing, style checkers were added. There were documentation improvements and additions, including JNDI details and enhancements to Soffit guides. There were also some upgraded portlets and removal of file-based PAGS and DLM configuration.
We included some updates that came from outside Unicon. There were fixes, dependency updates, and some very nice UI rework on the Email Portlet. It was exciting to see the community making a lot of contributions.
In Community Spotlight, we discuss in detail some effort by the uPortal community that is not from Unicon. For this briefing, Oakland University shared their ReactJS Portlet that will be part of their next major uPortal upgrade. It was great to see others spearheading technological advances in the uPortal ecosystem.