Directions for the second phase

For the second phase of the discipline, our group decided to keep contributing for the Kernel Workflow. After a first phase of a tense process dealing with the Linux Kernel, we found that going on this direction would be coold to learn but not a good idea if we actually wanted to deploy.

When it comes to choosing open-source projects to contribute, we can list many famous ones like Debian, Kernel, KW, Python’s matplotlib, and etc. But considering the learning flow we had on the previous months, it was a good choice to keep contributing to KW, and possibily to understand more about how it works. Also, this was a good opportunity to be part of such a big project used by so many people. Linux is extensively used and contributing to is certainly life and career enhancing.

Choosing a new issue to contribute is never something easy to do. It’s like picking the best potato out of a huge bag of potatos that all of them seems good, but when you peel them, err… it’s not exactly like that. In other words, at a first glance, reading the issue may seem doable, but once you go deep on the code and the dependencing most of the times you realize there is a lot more to be done and understood.

Myself, I went over many issues and like this, seemed cool to be done, but the dependencies were huge (starting understanding issue#150 and use it as reference, as well as manipulating many files in order to enhance the test coverage). We also look up a bit at issues 120 and 468.

We ended up going for the issue 1049 and 1051.

About the previous isssue we were doing - Improving kw maintainers test coverage

The kworkflow maintainers currently lack tests for several critical corner cases where the feature is expected to fail. Introducing these tests would significantly enhance the test coverage, ensuring that the feature behaves as expected and reducing the likelihood of unintended changes in the future.

We’ve opened a pull request addressing this issue directly here.

The concept itself is straightforward, but achieving acceptance on the first attempt can be challenging. We received suggestions from Rodrigo Siqueira and identified additional changes that could be made, particularly regarding an old and neglected test script.

Update: This contribution has been accepted, and the commit in the upstream project can be viewed here.

handle-trailer a new issue

Managing Trailer Lines with KW

Both issues #1049 and #1051 address similar concerns regarding the manipulation of trailer lines in commits and patches. We’re aiming to introduce a new feature to streamline these tasks, making them easier and quicker.

What is git-interpret-trailer

As mentioned on the official git documentation here.

In Git, a “trailer” is a specific kind of line found at the end of a commit message. Trailers are typically used to provide additional metadata about a commit, such as the author, reviewer, or references to related issues or tickets. They follow a standard format, making it easy to parse and process this metadata automatically.

The format of a trailer line is usually:

$ Key: value

There are some common type of trailers:

• Signed-off-by: Indicates who has reviewed and approved the changes in the commit. Commonly used in projects that follow the Developer Certificate of Origin (DCO).
• Co-authored-by: Indicates additional authors who contributed to the commit.
• Reviewed-by: Specifies who reviewed the changes.
• Fixes: References an issue that the commit fixes.

The goal of the issue is to attack the following: Often a kernel developer has to perform some operations over commit or patch trailer lines. Adding tags such as ‘Reviewed-by’ or ‘Acked-by’ is a common task and sometimes it might be required to do this over multiple commits or patches. Also another common one is the ‘Fixes’ tag, that must follow a specific format.

This feature helps on these cases. It uses ‘git rebase’, ‘git commit –amend’ and ‘git interpret-trailers’ as its backend in order to make these tasks quicker to complete.

The current state

Currently, we are still deliberating on the implementation approach. Should we create a new feature, such as kw handle-trailer, or integrate this functionality into an existing KW feature?

We’ve opted for the first option and have opened a pull request that can be read here.

One of the addressed dicussions are about the name chosen for the issue fixing. Some suggestions we received include:

• kw annotate
• kw amend
• kw tag
• kw signature

It’s too early to determine whether this PR will be accepted. This can be left for the future and you can keep up with the discussions updated on the Pull-Request