For development purpose, it is very useful to have an infrastructure that can spot regressions based on commit base. Currently, our existing infrastructure runs mainly SPEC benchmark and is cumbersome from perspective of any further development. I would like to build a replacement that will combine buildbot framework with a custom web project (based on Django framework). The web project will be used both for submitting reports coming from a buildbot slave and for UI which will serve plots and data. If you want to inspire a bit more, please visit Chrome Performance Dashboard or Mozilla telemetry. I hope I can make a simple extendable project that is going to eventually replace existing implementation.

Squeezeboxserver

Elasto is a cloud storage client project that has been developed across a number of SUSE Hack Weeks.<br /> It currently supports Amazon S3 and Microsoft Azure REST storage protocols, and includes a POSIX like file API.<br />

open-sTeam is a platform for cooperative work and cooperative learning developed at the university of paderborn in germany. the platform is being used at http://societyserver.org/ and is being developed further.

<p> The user space interface of evdev is pretty generic. All hardware abstraction is done in the kernel driver, device properties are mapped to a set of generic properties. The properties can be queried thru a generic interface only very few parameters are set from user space. In user space the evdev API is used by Xorg's evdev driver and libinput.

Apache Maven is a build tool used by many Java projects, which is incompatible with OBS in that it tries to download binary dependencies from the Internet. Several people have in the past years tried to somehow bootstrap Maven and failed. My new proposed approach is a Maven, patched to obtain packages from a filesystem location, and packages with .jar based -bootstrap.spec variant plus source-based build for properly modeling dependencies in OBS. Unlike the SUSE Manager team's work I am trying to rebuild those .jars from sources. Where necessary I am patching dependency versions to the latest sources/jars packaged.

I'd like to learn how to use Robot Framework for doing Acceptance Tests of a cli application: Machinery.

Goal #1

<p>PXE boot is a quick and easy way to install any SUSE/openSUSE product on a machine. It doesn't require any boot media and today virtually any system is capable of booting using PXE. </p> <p>The architecture team maintains a tftp server with boot loaders, boot loader configurations and installation images for a variety of architectures and products. Currently in the Nuernberg office this PXE boot service is only available in the network of the architecture team. Since tftp is unicast, the server should be reachable from anywhere in the internal network. What is missing is the information about the address of the tftp server and the image to boot from this server.

Paul McKenney's blog article inspired me to try apply his approach to kernel's memory allocation flags (gfp_flags) and how their combinations affect the decisions and actions taken during page allocation. Recent upstream development around these flags leads me to believe that the complexity is too high for me to reason about them and change the code without unintended changes in semantics. So it might be worth to let the computer do the hard work. If it works out, the approach should allow to verify that changing the code doesn't result in corner cases where some flag combinations don't work as intended. Then we can attempt to e.g. reduce the number of flags and perform other cleanups without fear of breaking everything.