The release candidates were created at sensible places in the git log, after some of the major technical components were successfully upgraded (Python 2.7 -> 3.5, Django 1.11 -> 2.2, Mongodb 3.2 -> 3.6, Ruby 2.5.7, Nodejs 8 -> 12). The community did manage to detect and address issues efficiently. Members from the community tried the three release candidates and made sure that the installation process went smoothly. Issues were raised and listed in the CRI-171 Juniper epic. The Open edX community stepped up to the task of resolving the detected issues. There was a strong determination for producing a stable, reliable release. Community pull requests were swiftly reviewed and merged in time for the Juniper release. In many cases (static asset compilation, honor/audit course modes), edX employees went above and beyond to help fix complex issues that caused backward incompatibility, providing precious information and manpower to produce a fix. The Juniper release was scheduled for May 21st. It was finalized only on June 9th, with a 3 weeks delay. Still, I think this is a success, considering that most of the technical work was ready in time for the deadline. Installation was tested in various ways (custom installers), which uncovered more issues.
| The discovery of technical issues was an haphazard process, with every member of the working group trying to install the new release and discussing issues as they were discovered. It was a random easter egg hunt, and not a systematic search-and-destroy process. Assigning the issues to the Juniper epic was a convoluted process that should be streamlined. It’s weird that non-edX users can create issues, but not edit their descriptions or assign them to the CRI-171 epic. Since the release was made, pull request reviews are back to the old normal and pull requests take many weeks to be reviewed and merged. (see mine for instance) I might be wrong, but in my understanding the community did not manage to do sufficient testing of the new release from the perspective of product design. That means that some features may be broken without us even knowing about it. One of the items that delayed the release was the Mongodb upgrade. We should clarify how and why some members were aware of the upgrade, but not others; why the upgrade was not mentioned before in the Juniper notes; why the installation playbooks were installing an outdated version of Mongodb. It’s not all clear to me what other tasks needed to be performed between juniper.rc3 and juniper.1: I know that translations needed to be updated, and a Django security patch had to be applied. There is probably room for improvement to make sure that future minor upgrades (juniper.2, juniper.3, etc.) can be produced quickly and with minimal effort. The Juniper release is a major technical improvement over Ironwood, but there are some regressions during the installation process. In particular, LMS database migrations take much longer (note to self: add a more precise metric here) in Juniper than in Ironwood. This is (probably) caused by the fact that we did not find the time to squash the database migrations in time for the release. Also, running webpack takes much longer and uses more memory, causing some servers to crash. The elephant in the room: even after the release, the community as a whole has no idea what’s in Juniper, in terms of product features. We grope around, looking for new pages and visual cues for new features (see this blog post by IBL for instance) but to be honest we are still very much clueless. I am very much concerned that this issue will happen again with Koa, as the community still has zero insight in the features added to Open edX, nor in the EdX roadmap. Despite the fact that this is the tenth Open edX release, there still isn’t a clear upgrade path from the previous release for users of the native installation scripts. This is completely unsustainable. The officially recommended installation method must have a clear upgrade path. As of today, there still has not been any official announcement about the release by edX (see edX blog). This makes it much harder for the community to defend the Open edX brand and product. I wasn’t sure when the next face-to-face meeting would be, or how best to reach people. Significant changes landed on juniper.master shortly after .1, it would have been better to sync up with those changes instead. People weren’t sure how to properly test. No continuous integration of installation meant that problems could fester for months before manual testing uncovered them.
|