It is well-known that two git commits within a single repo can be independent from each other, by changing separate files to each other, or changing separate parts of the same file(s). Conversely when a commit changes a line, it is "dependent" on not only the commit which last changed that line, but also any commits which were responsible for providing the surrounding lines of context, because without those previous versions of the line and its context, the commit's diff would not cleanly apply. As with most dependency relationships, these form a directed acyclic graph. Sometimes it is useful to understand the nature of parts of this graph; for example when porting a commit "A" between git branches via git cherry-pick, it can be useful to programmatically determine in advance the minimum number of other dependent commits which would also need to be cherry-picked to provide the context for commit "A" to cleanly apply.

Using traditional hardware development tools, apply a Non-uniform Choppy Transformation to a block of ligneous substance. The end result should be a 3D rendering of the Geeko glyph.

GNU Guile-2.2 will be based on brand new backend, CPS(continuation passing style) as the most significant IR, and a RegisterVM. These are the prerequisite for the final AOT compiler. The old Guile-Lua is old for compatible with the brand new RegisterVM, moreover, it uses LL(1) which is painful for hacking. I've rewritten the parser with LALR and all the intermediate part before transfer it to Tree-IL which is another iR before CPS. Besides, I'm trying to add type-inferencing and partial-evaluation for Lua specific optimizing. Although there's partial-evaluator in Guile backend, it's a generic one for all the front-end languages.

Currently whenever there is a test, we need to find or build environment on our own machine or borrow some one else's machine temparorily. I hope we can collect all testing machines in our local team and build a sharable testing environment. Every one can reserve and use the machine, add machine, check machine info to find proper one (hardware and software) for test, share vm images, share other testing related resources, etc.

Learn ceph architecture and try to deploy a ceph cluster.

The virtualization team's automated testing has a long history. It was born in the old Novell Integration Test framework. The virtualization lab ran an instance of this framework for many years. Over time, those who knew the framework left the company, taking their knowledge and leaving little documentation behind. As our testing needs increased, we found the old framework insufficient, but saw little value in improving it given the available open source CI frameworks. Before burying ourselves in SLE12 development, we took some time to move our automated tests under control of a Jenkins instance running in our lab. Tests were configured to run when new packages landed in our SLE12 devel project, ensuring our queued SLE12 submissions were continuously tested. But more is needed.

I just learned about xenctx, which is used to help debug Xen issues. I am wondering if it would be easily ported to KVM. If not, perhaps at least creating the equivalent for KVM may be useful for handling problems with KVM guests.

Each of the core dump upload servers in Europe and USA could be improved if the shell scripts were combined so that the same tasks can be performed on each site, e.g. downloading of all packages needed for crash usage with a specified core dump by allowing for configurable (or even automated) selection of locations to obtain data packages from.

Working on a way to add exceptions using javascript (jquery), php, json, and mysql to modify the generated calendar used to manage who is on after hours.