During Hack Week 7 I worked on an archive of Qt-based libraries. The goal was to easily make all available Qt libraries accessible to developers. Think CPAN for Qt. So I hacked on a web site and a command line client. There was a little bit of progress on the project since then, but with the upcoming KDE Frameworks 5 there will be quite a number of additional libraries available for Qt developers. This should be well represented in Inqlude as well. The coverage of Inqlude is also still not complete, and the tooling needs some improvement as well, especially regarding integration with distributions.

Use machine learning and natural language processing techniques to analyze the changes made in a project, and classify them in: * Small / unimportant fix

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.

Automate the process described here: - https://github.com/aspiers/git-deps/#use-case-2-splitting-a-patch-series

This is about porting the old KDE 3 based KDirstat to the latest Qt 5. KDirStat didn't use that much KDE infrastructure to begin with, and KDE seems to be more and more a moving target. Project repo and web site with more details:

Bisection is a well known method of localizing which commit caused a regression in a code repository. git-bisect is a particularly used tool for this problem in git repositories. However it is often the case that the failure is probabilistic in nature - either because we don't have a reliable reproducer of the failure and thus not reproducing a problem on a particular commit does not mean the problem is not still present there, or because of inherent variability of e.g. performance regressions. Bisection for such failures is problematic as it takes only one false result for the bisection to end up in an unrelated part of code history. So in these cases we usually have to heavily extend runtime of a reproducer or do multiple test runs or multiple bisection runs to minimize a chance of error. The aim of the project is to implement stochastic bisection for git. I.e., a method that will count with the fact that test results at each point of code history have some error rate and provide points in code history to test to find commit in code history that is with high probability introducing the regression in the smallest possible number of tests. Then we can use this method for bisection of performance problems in our performance testing grid Marvin.

Project Description

Most developers are comfortable with the workflows of git hosting services like gitlab and github, including their CI/CD capabilities. This project aims to experiment with new downstream package development and maintenance workflows based on upstream git repositories cloned at gitlab.suse.de. I'll be using the libvirt package for these experiments since it typically contains a healthy mixture of downstream-only patches along with upstream cherry picks.

Project Description

Create a set of container images for serving a mock git server and mock git clients in a Kubernetes cluster that can be used as building blocks for an interactive git playground.

Project Description

The goals: