This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
gsoc:2021-gsoc-kernel-workflows [2021/01/27 06:09] lukas.bulwahn |
gsoc:2021-gsoc-kernel-workflows [2021/01/27 06:41] (current) lukas.bulwahn |
||
---|---|---|---|
Line 4: | Line 4: | ||
Collect ideas for GSoC student projects on Improving Kernel Workflows here. | Collect ideas for GSoC student projects on Improving Kernel Workflows here. | ||
+ | ===== MAINTAINERS and correct integration tree information ===== | ||
In previous work on MAINTAINERS and process conformance, Pia Eichinger [1] has investigated: are patches integrated by the maintainers defined by the responsibilities in MAINTAINERS? | In previous work on MAINTAINERS and process conformance, Pia Eichinger [1] has investigated: are patches integrated by the maintainers defined by the responsibilities in MAINTAINERS? | ||
Line 15: | Line 16: | ||
The factors and metric to determine what is best is of course the challenging task of identifying a suitable heuristics that is: | The factors and metric to determine what is best is of course the challenging task of identifying a suitable heuristics that is: | ||
- | 1. good enough to be used to create a change to MAINTAINERS that is accepted by the community, and | + | |
- | 2. simple enough to be implemented with reasonable effort. | + | - good enough to be used to create a change to MAINTAINERS that is accepted by the community, and |
+ | - simple enough to be implemented with reasonable effort. | ||
Background: | Background: | ||
Line 24: | Line 26: | ||
Ideally the references in the MAINTAINERS sections are: | Ideally the references in the MAINTAINERS sections are: | ||
- | - complete, i.e, all integration trees used for recent kernel releases are mentioned in MAINTAINERS. | + | * complete, i.e, all integration trees used for recent kernel releases are mentioned in MAINTAINERS. |
- | - sound, i.e., the majority of the commits are integrated through the trees referenced in the MAINTAINERS sections a patch belongs to. | + | * sound, i.e., the majority of the commits are integrated through the trees referenced in the MAINTAINERS sections a patch belongs to. |
- | - precise, i.e., for each MAINTAINERS section, the majority of the commits that belong to a section are integrated through the tree referenced in that section. | + | * precise, i.e., for each MAINTAINERS section, the majority of the commits that belong to a section are integrated through the tree referenced in that section. |
Goal: | Goal: | ||
Line 39: | Line 41: | ||
In this project, we can make use of: | In this project, we can make use of: | ||
- | - gitdm [git://git.lwn.net/gitdm.git]: gitdm includes some scripts to parse MAINTAINERS and obtain the integration tree patch of a commit. | + | * gitdm at ''git:/ /git.lwn.net/gitdm.git'': gitdm includes some scripts to parse MAINTAINERS and obtain the integration tree patch of a commit. |
and/or | and/or | ||
- | - pasta [https://github.com/lfd/PaStA]: Similarly to gitdm, pasta provides functionality to parse MAINTAINERS and some functionalities on extracting information on commits. | + | * [[https://github.com/lfd/PaStA|pasta]]: Similarly to gitdm, pasta provides functionality to parse MAINTAINERS and some functionalities on extracting information on commits. |
Potential project phases: | Potential project phases: | ||
- | - In the first phase (PoC phase), we could probably just create a setup that combines or extends the functionality in gitdm and/or in pasta. | + | - In the first phase (PoC phase), we could probably just create a setup that combines or extends the functionality in gitdm and/or in pasta. |
- | + | - In the second phase (MAINTAINERS patch creation phase), we send out some patches and collect feedback from maintainers. | |
- | - In the second phase (MAINTAINERS patch creation phase), we send out some patches and collect feedback from maintainers. | + | - In a third phase, with a better understanding of the individual pieces in gitdm and/or in pasta, we could then create a cleaner design that also refactors gitdm and pasta to share the same implementation when essentially the same basic functionality is used within the various analyses. |
- | + | ||
- | - In a third phase, with a better understanding of the individual pieces in gitdm and/or in pasta, we could then create a cleaner design that also refactors gitdm and pasta to share the same implementation when essentially the same basic functionality is used within the | + | |
- | various analyses. | + | |
+ | Mentor contact: Lukas Bulwahn; lukas.bulwahn-at-gmail.com | ||
References: | References: |