This project is about advancing the tool you're currently browsing. It got started back in Hack Week 9 to retire all the weird tools we've used in the past to track ideas. As you can see it has gone far but is still far from done. There are lots of features missing and bugs to be fixed on github. Get going!

The idea would be to setup an internal tmate.io server to make instant command line collaboration easier.

Futexes are complex enough that make it a good candidate for applying fuzzy testing techniques to the various inputs and operations that can be performed. Instead of re-writing any testing infrastructure, make use of the trinity system call fuzzing tool. While trinity does apply fuzzing to futexes, it does so with very limited knowledge, using only generic callbacks to the different steps involved. As such the main goal is extending testing coverage and making it more ad-hoc.

Cause the original [BLUG website](beijinglug.org) is too old and lack of security, so we plan to fully rework for this website. It will following such steps:

The FlightGear is a free and open source flight simulator. To introduce what FlightGear offers, there is a official getstart manual for beginner. The getstart manual written in English, so I try to translate it into Chinese, and add support for CJK character.

Our beloved competitor developed and use project-wide message bus called Fedora Infrastructure Message Bus. This project was already adapted, or is being adapted, also by Debian community. During Lucky Thirteen I want to get deeply familiar with the concept and implementation, deploy test scenario and write plugins for OBS and openQA to talk to each other.

The title of this project is inspired from the must-see video John Hughes - Testing the Hard Stuff and Staying Sane

The afl fuzzer is an interesting tool that uses compile time instrumentation and genetic algorithms to automatically produce test cases that will trigger different code paths in binary... http://lcamtuf.coredump.cx/afl/

git rebase is a very useful construct in source control management, as it allows you to re-apply your changes atop a different branch of the same repository. While this concept transitions perfectly to container management (updating a container could be as easy as a docker rebase), and the Docker client is inspired by the git semantics, Docker has no such feature (in fact, Solomon Hykes used rebase and merge as examples of things "that we don't want"). Currently, zypper-docker works by applying an updated layer on top of an existing image. While this does work quite well, it separates the process of updating the base image and updating all of your derivative images (you need to re-download new packages for each derivative image). So, this project will be working on implementing something like git rebase for Docker images. There are several issues with this, mainly involving the fact that we are rebasing binaries and not source code, so merge conflicts will probably be quite messy. But it should be possible to implement some form of simple rebase method (which will essentially fall back to docker build in the worst case, which is what you were going to run anyway). By maximising the reuse of the existing image layers, it should be possible to reduce build times quite significantly.

As detailed previously on devel and opensuse-factory the KDE team didn't have access to their bugs and could not actively subscribe. This is changed now by introduction of opensuse-kde-bugs@opensuse.org mailinglist.