Differences

This shows you the differences between two versions of the page.

--- gsoc:2025-gsoc-kworkflow [2025/01/31 15:35]
davidbtadokoro [2025 GSoC - Kworkflow]
+++ gsoc:2025-gsoc-kworkflow [2025/03/06 16:02] (current)
davidbtadokoro [Interact with the kw/patch-hub community!]
@@ Line 1: / Line 1: @@
-======2025 GSoC - Kworkflow======
+====== Google Summer of Code 2025: kworkflow ======
 [[:gsoc:google-summer-code-2025|Go back to the main GSoC Linux Foundation page]]
@@ Line 10: / Line 10: @@
 Mentor: David Tadokoro <davidbtadokoro at gmail dot com>
-======Brief about kworkflow======
+====== Introduction to kworkflow ======
-Kworkflow, or just kw, is a tool that intends to simplify the kernel workflow by automating tasks such as:
+''Kworkflow'', or just ''kw'', is a system that includes many tools with the intent of simplifying Linux kernel workflows by automating tasks such as:
   - [[https://kworkflow.org/tutorials/buildlinux.html|Manage kernel build]];
   - [[https://kworkflow.org/tutorials/deploy-kernel.html|Manage installation/removal of Linux on a target machine (local, remote, or VMs)]];
   - [[https://kworkflow.org/tutorials/find-maintainers.html|Provide an easy way to collect basic information]];
   - [[https://kworkflow.org/tutorials/configm.html|Manage config files]];
-  - Support working on DRM subsystem (we can expand to other subsystems). Etc;
+  - Support working on the DRM subsystem (we can expand to other subsystems). Etc;
-By using kw we expect to speed up everyday tasks executed by kernel developers in their workflow, provide a unified development experience, and reduce the learning curve for newcomers. Finally, the project should be reasonably easy to contribute since it is written in Bash, has extensive test coverage, follows a code style rule, it is documented from the code level to the user level. Don't believe it? Check by yourself:
+''kw'' aims to speed up everyday tasks executed by Linux kernel developers in their workflows and provide a unified development experience similar to what ''git'' proposes in the context of version control. ''kw'' also helps reduce the learning curve for newcomers to the kernel ecosystem. Finally, the project should be reasonably easy to contribute since it is (almost) completely written in Bash, has extensive test coverage, follows a code style rule, and is documented from the code level to the user level. Don't believe it? Check by yourself:
   * https://kworkflow.org/index.html
-  * https://blog.kworkflow.org/
+  * https://blog.kworkflow.org
-======Pre-requisites (warm-up)======
+In GSoc 2025, we will focus on a sub-project of ''kw'' that once was a feature like any other but now has its own codebase, is written in Rust, and does not have the exact same development model. The sub-project is called ''patch-hub'' and aims to streamline the interaction of Linux kernel maintainers with patches sent through development mailing lists (if this seems alien to you, check [[https://www.kernel.org/doc/html/v4.14/process/2.Process.html#mailing-lists|this reference]]).
-** ( ( This section is mandatory for everybody ) ) **
+====== Warm Up ======
+Even though we will focus on a different aspect of Linux kernel development this year, it is imperative for candidates to be familiar with the main workflows of the whole process.
-The below link is a set of activities that you have to complete before applying for this project.
+The link below is a set of activities you must complete before applying for this project that will help you understand some fundamentals about kernel workflows. **Only the __Phase 1__ is mandatory**, although we encourage you to get to know ''kw'' more deeply by going through the other phases.
-https://github.com/kworkflow/kworkflow/discussions/476
+[[https://github.com/kworkflow/kworkflow/discussions/476|First time in the Linux kernel development and kworkflow? Then, start your journey here :)]]
-======Project Ideas======
+====== Project Idea: patch-hub v.1.0.0 ======
+==== Details ====
-We are open to discussing the final project proposal and encourage you to think about varied ways kw can be improved. Nevertheless, here is a list of project ideas that represent points of interest for the kw project:
+  * Project Size: 1 contributor full-size (350 hours)
+  * Level of Difficulty: Hard
+  * Helpful Experience: FLOSS development and Rust
-**TO BE UPDATED**
+==== Description ====
-=====Implement a Documentation Generator from Source====
+As mentioned before, in the GSoC 2025 edition, we intend to focus on a single project on the ''kw'' sub-project ''patch-hub''. Linux kernel development is done via electronic mail and mailing lists, so instead of submitting pull requests on GitHub through the web, contributions, reviews, and the like are done by sending emails to other developers and mailing lists.
-  * **Size**: 1 contributor medium (175 hours), Level of difficulty: Intermediate
+Software development based on email may seem a little confusing, especially if you have never heard of it, but the important point is that even though there are some arguments in favor of it, there are many inefficiencies and complexities that come with it.
-  * **Desired knowledge**: Bash, mechanisms like kernel-doc/javadoc
+''patch-hub'', following the ''kw'' spirit of simplifying workflows, aims to simplify the workflows of kernel developers when consuming from the development mailing lists. The tool is constructed as a Terminal UI (TUI), so it is a little less "roots" than a fully CLI system like the rest of ''kw'', but still no graphical interface 8-)
-  * **Description**: Although inconsistent throughout the project, we have a pattern for writing function documentation. In this sense, adding a system to generate documentation using source code similar to the kernel-doc and javadoc mechanisms seems viable. We have wanted to implement this for a long time, roughly since [[https://github.com/kworkflow/kworkflow/issues/289|this issue]].
+Below is a video of a simple demo of the tool. From listing the available development lists to consulting the flow of patchsets (a set of related patches, similar to a PR or an MR), their individual contents, and running actions on them, the tool aims to completely cover this part of kernel development.
-=====Deploy In-House Continuous Integration (CI) Pipeline=====
+[[https://drive.google.com/file/d/1VriafRyLQ5RmWC1z5UxKv9lpM7GU0iOt/view?usp=drive_link|patch-hub demo video]]
-  * **Size**: 2 contributors full-size (350 hours), Level of difficulty: Hard
+Don't forget to check out the [[https://github.com/kworkflow/patch-hub|patch-hub GitHub repo]].
-  * **Desired knowledge**: DevOps, CI
+==== Getting to Version 1 ====
-  * **Description**: Currently, kw uses GitHub actions for its CI pipeline. We plan to implement an in-house CI pipeline. For this task, there is much work to be done in terms of planning and deploying this infrastructure.
+As you can see in the demo video, ''patch-hub'' isn't in its initial stages, but there is a lot of work to be done. Currently, the latest released version is v0.1.4, and we are close to v0.2.0, which will be its beta.
-=====Expand and Refine ''kw patch-hub''=====
+With that being said, between the beta and v1.0.0, there are many tasks to be made, which we can highlight:
-  * **Size**: 1-2 contributors full-size (350 hours), Level of difficulty: Hard
+  * Redesign the architecture, as the technical debt is getting bigger
+  * Implement custom kernel build
+  * Implement inline review
+  * Make patchset reply with ''git send-email'' not teardown the UI
+  * Expand the unit test coverage, which is (being nice) small
+  * Enhance UI and UX
+  * And much more...
-  * **Desired knowledge**: Bash, mail-based free-software projects
+The idea is not to strictly get to v1.0.0 by the end of the program but to get as near as possible. At least, we need a solid and robust base that will streamline the rest of the work!
-  * **Description**: The [[https://kworkflow.org/man/features/kw-patch-hub.html|kw patch-hub]] is a significant point of interest in the project and is currently under heavy development. We now have a 'Minimum Viable Product' with performance issues, bugs, and a lack of core features. On this basis, there is much space for improvements and refinements.
+==== Interact with the kw/patch-hub community! ====
-====Don't forget to interact to with the kw Community====
+Interacting with ''kw'' and ''patch-hub'' as a system/tool and a free software project is critical to grasping the dynamics and technical challenges you will face in your GSoC. This means it's nice to use ''kw'' and ''patch-hub'' to understand its purposes and functionalities while also reporting bugs and suggesting enhancements (take a look at ''patch-hub'' [[https://github.com/kworkflow/patch-hub/issues|reported issues]]). Don't be afraid to open pull requests addressing them! We really encourage you to do it!
-Interacting with kw as a tool and as a free software project is critical to grasp which of the above projects best suits you or to bring other ideas to the table. This means it's nice to use kw to understand its purposes and functionalities while also reporting bugs and suggesting enhancements (take a look at kw [[https://github.com/kworkflow/kworkflow/issues|reported issues]]). Don't be afraid to open pull requests addressing them! We really encourage you to do it!
+===== As this edition focuses on patch-hub, we ask that you also focus the interaction on patch-hub. So, please open PRs, discuss issues, and the like on the [[https://github.com/kworkflow/patch-hub|patch-hub repo]]. =====
-======Making your Project Proposal======
-The pre-requisites section is mandatory for everyone; for this reason, your final project proposal should have one section per assignment with two or three paragraphs that describe your experience with each task. Additionally, in your application, you must add print screens that follow the below instructions:
+====== Making your Project Proposal ======
-__Contact David to get one specific ID__
+The **Warm Up** section is mandatory for everyone, so your final project proposal should have one section per assignment with two or three paragraphs describing your experience with each step of __Phase 1__. Additionally, in your application, you must add print screens that follow the below instructions:
-If you are really interested in this project, send a message to David and request one specific ID. You will need it for the next steps.
+==== Contact David to get one specific ID ====
-__QEMU Setup__
+If you are really interested in this project, email David and request one specific ID. You will need it for the next steps.
-For demonstrating your QEMU setup, you will need need to take a print screen of your entire desktop with QEMU running and with the following comment in your TTY:
+==== QEMU Setup ====
-  #kw 2024 GSoC <ID>
+To demonstrate your QEMU setup, you will need to take a print screen of your entire desktop with QEMU running and with the following comment in your TTY:
-__For your custom kernel installation__
+  #kw 2025 GSoC <ID>
-For showing that you were able to install a custom kernel in your VM system, add the following label in your kernel name suffix:
+==== Custom Linux kernel Installation ====
+To show that you were able to install a custom kernel in your VM system, add the following label in your kernel name suffix:
   Kernel-<YOUR_NAME>-<YOUR_ID>
-  (( Replace YOUR_NAME by your first name, and YOUR_ID ))
+  (( Replace YOUR_NAME with your first name and YOUR_ID ))
 Install it in your QEMU VM; in the TTY, run the following command:
@@ Line 92: / Line 103: @@
 Take a print screen of the entire screen.
+==== Writing your Proposal ====
 Finally, make sure that you have the following section in your application:
   - One or two paragraphs about you;
-  - A couple of sections that describe your interaction with kw;
+  - A couple of sections that describe your interaction with ''kw''/''patch-hub'';
-  - Highlight some of your contributions to kw;
+  - Highlight some of your contributions to ''kw''/''patch-hub'';
-  - A project proposal to be executed in the GSoC timeline. Please, make sure that you add three main milestones (it should match with the GSoC evaluation date) and a work breakdown.
+  - A project proposal to be executed in the GSoC timeline. Please add three main milestones (it should match with the GSoC evaluation date) and a work breakdown.
+P.S.: Feel free to share your draft before submitting the final version.
+==== IMPORTANT NOTE ====
+As mentioned a couple of times, we are deadset on the ''patch-hub'' v1.0.0 project, and given the small number of mentors, we, with a heavy heart, won't be accepting other lines of project even if it is in the context of ''kw''.
+This doesn't mean we have an inflexible view of how the ''patch-hub'' project will be. Much of GSoC involves heavy interaction of contributors and mentors to produce the best free software code possible!
-P.s.: Feel free to share your draft before submitting the final version.

Wiki

User Tools

Site Tools

Differences

Page Tools