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: | ||