Feb 242018

Opensource.com looks at the availability of open educational resources (OERs), where to find them, and what the advantages of OERs are. Math and computer science professor David Usinski is a strong advocate for OERs and was interviewed for the article. “The ability to customize the curriculum is one of David’s favorite benefits of OER. ‘The intangible aspect is that OER has allowed me to reinvent my curriculum and take ownership of the content. With a textbook, I am locked into the chapter-by-chapter approach by one or two authors,’ he says. Because of OER ‘I am no longer hindered or confined by published materials and now have the flexibility to create the curriculum that truly addresses the course outcomes.’ By freely sharing the content he creates, other instructors can also benefit.
SUNY math professor makes the case for free and open educational resources (Opensource.com)
Source: LWN.Net

Feb 242018

Jordan Petridis has been kicking ass by overhauling
librsvg’s continous integration (CI) pipeline. Take a look at this

Continuous integration pipeline

On every push, we run the Test stage. This is a quick compilation
on a Fedora container that runs “make check” and ensures that the
test suite passes.

We have a Lint stage which can be run manually. This runs cargo
to get Rust lints (check the style of Rust idioms), and cargo
to check indentation and code style and such.

We have a Distro_test stage which I think will be scheduled
weekly, using Gitlab’s Schedules feature, to check that the tests
pass on three major Linux distros. Recently we had trouble with
different rendering due to differences in Freetype versions, which
broke the tests (ahem, likely because I hadn’t updated my
Freetype in a while and distros were already using a newer one
); these
distro tests are intended to catch that.

Finally, we have a Rustc_test stage. The various crates that
librsvg depends on have different minimum versions for the Rust
compiler. These tests are intended to show when updating a dependency
changes the minimum Rust version on which librsvg would compile. We
don’t have a policy yet for “how far from $newest” we should always
work on, and it would be good to get input from distros on this. I
think these Rust tests will be scheduled weekly as well.

Jordan has been experimenting with the pipeline’s stages and the
distro-specific idiosyncrasies for each build. This pipeline depends
on some custom-built container images that already have
librsvg’s dependencies installed. These images are built weekly in
gitlab.com, so every week gitlab.gnome.org gets fresh images for
librsvg’s CI pipelines. Once image registries are enabled in
gitlab.gnome.org, we should be able to regenerate the container
images locally without depending on an external service.

With the pre-built images, and caching of Rust artifacts, Jordan was
able to reduce the time for the “test on every commit” builds from
around 20 minutes, to little under 4 minutes in the current
iteration. This will get even faster if the builds start using ccache
and parallel builds from GNU make.

Currently we have a problem in that tests are failing on 32-bit
, and haven’t had a chance to investigate the root
cause. Hopefully we can add 32-bit jobs to the CI pipeline to catch
this breakage as soon as possible.

Having all these container images built for the CI infrastructure also
means that it will be easy for people to set up a development
for librsvg, even though we have better instructions
thanks to Jordan. I haven’t investigated setting up a
Flatpak-based environment; this would be nice to have as well.

Federico Mena-Quintero: Librsvg's continuous integration pipeline
Source: Planet Gnome