New kernel patches review management


Nobuhiro Iwamatsu
 

Hi,

I considered using the gitlab wiki to switch the current patch review
management to another.

The gitlab wiki can be used as a regular git repository and can be
viewed from his browser by writing its contents in markdown.

e.g. git clone git@gitlab.com:cip-project/cip-kernel/linux-cip.wiki.git

It can be created using the API on the project wiki[0]. Since
namespaces are available, we can also create hierarchies such as
5.10.y/v5.10.77 [1].
The wiki page is first filled with the commit ID, then the CIP kernel
developer writes the name after the commit they plan to review.

The commit content of [1] is an example, so please let me know if you
have any opinions about the format and others.

Best regards,
Nobuhiro

[0]: https://gitlab.com/-/snippets/2200569
[1]: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/wikis/5.10.y/v5.10.77


Ulrich Hecht
 

On 11/11/2021 7:29 AM Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> wrote:
I considered using the gitlab wiki to switch the current patch review
management to another.

The gitlab wiki can be used as a regular git repository and can be
viewed from his browser by writing its contents in markdown.

e.g. git clone git@gitlab.com:cip-project/cip-kernel/linux-cip.wiki.git

It can be created using the API on the project wiki[0]. Since
namespaces are available, we can also create hierarchies such as
5.10.y/v5.10.77 [1].
The wiki page is first filled with the commit ID, then the CIP kernel
developer writes the name after the commit they plan to review.

The commit content of [1] is an example, so please let me know if you
have any opinions about the format and others.
It would be helpful if each line would also contain the commit title.
Other than that it looks good to me.

CU
Uli


Pavel Machek
 

Hi!

I considered using the gitlab wiki to switch the current patch review
management to another.

The gitlab wiki can be used as a regular git repository and can be
viewed from his browser by writing its contents in markdown.

e.g. git clone git@gitlab.com:cip-project/cip-kernel/linux-cip.wiki.git
This looks good.

It can be created using the API on the project wiki[0]. Since
namespaces are available, we can also create hierarchies such as
5.10.y/v5.10.77 [1].
The wiki page is first filled with the commit ID, then the CIP kernel
developer writes the name after the commit they plan to review.
I believe this is too simple. We should include patch titles, so that
it is easier to review whole series. I also believe we should include
related patches from 4.19/4.4, so that they are reviewed together with
corresponding 5.10 change.

I'm currently using this format, and scripts to generate it are
already in the repository. Could we use that for review management,
too?
v-- patch title
v-- stable tree version
v-- "o" means we are building it in some
configuration, " " means likely not relevant to us
v-- stable commit id, not quite reliable
v-- upstream commit id
|50d50ca00 88c42f : 5.10| perf bpf: Add missing free to bpf_event__print_bpf_prog_info()
|51444729b 8ac9df o: 5.10| llc: fix out-of-bound array index in llc_sk_dev_hash()
|df8fa74a0 8ac9df o: 4.19| llc: fix out-of-bound array index in llc_sk_dev_hash()
|bf70e4f7d 8ac9df o: 4.4| llc: fix out-of-bound array index in llc_sk_dev_hash()
|3dd3e81ad 9fec40 .: 5.10| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
|b5cb963e8 9fec40 .: 4.19| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
|21e4958e2 9fec40 .: 4.4| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
|2a126e22e c7c386 o: 5.10| arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions
|f9ee3718b c7c386 o: 4.19| arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions
|78570c445 b8b831 .: 5.10| bpf, sockmap: Remove unhash handler for BPF sockmap usage
|dbe525054 e0dc3b o: 5.10| bpf: sockmap, strparser, and tls are reusing qdisc_skb_cb and colliding
|c45dfa514 1c360c .: 5.10| gve: Fix off by one in gve_tx_timeout()
|3737feeca 10a6de o: 5.10| seq_file: fix passing wrong private data
|614a5f5c0 6dc254 .: 5.10| net/sched: sch_taprio: fix undefined behavior in ktime_mono_to_any
|25381c855 e140c7 .: 5.10| net: hns3: fix kernel crash when unload VF while it is being reset
|14ec321cf 688db0 .: 5.10| net: hns3: allow configure ETS bandwidth of all TCs
|379d4165f f64ab8 o: 5.10| net: stmmac: allow a tc-taprio base-time of zero
|3772974cc c7cd82 o: 5.10| vsock: prevent unnecessary refcnt inc for nonblocking connect
|69eb06075 c7cd82 o: 4.19| vsock: prevent unnecessary refcnt inc for nonblocking connect
|5a54ee129 c7cd82 o: 4.4| vsock: prevent unnecessary refcnt inc for nonblocking connect
|6ecbca5bf e5d5aa .: 5.10| net/smc: fix sk_refcnt underflow on linkdown and fallback
|38bf1ce3e 4ca110 o: 5.10| cxgb4: fix eeprom len when diagnostics not implemented
|41a958b00 4ca110 o: 4.19| cxgb4: fix eeprom len when diagnostics not implemented

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Nobuhiro Iwamatsu
 

Hi Ulrich,

The commit content of [1] is an example, so please let me know if you
have any opinions about the format and others.
It would be helpful if each line would also contain the commit title.
I agree.

Other than that it looks good to me.
Thanks!

Best regards,
Nobuhiro

________________________________________
差出人: Ulrich Hecht <uli@fpond.eu>
送信日時: 2021年11月11日 18:04
宛先: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT); pavel@denx.de
CC: jan.kiszka@siemens.com; masami.ichikawa@cybertrust.co.jp
件名: Re: [cip-dev] New kernel patches review management


On 11/11/2021 7:29 AM Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> wrote:
I considered using the gitlab wiki to switch the current patch review
management to another.

The gitlab wiki can be used as a regular git repository and can be
viewed from his browser by writing its contents in markdown.

e.g. git clone git@gitlab.com:cip-project/cip-kernel/linux-cip.wiki.git

It can be created using the API on the project wiki[0]. Since
namespaces are available, we can also create hierarchies such as
5.10.y/v5.10.77 [1].
The wiki page is first filled with the commit ID, then the CIP kernel
developer writes the name after the commit they plan to review.

The commit content of [1] is an example, so please let me know if you
have any opinions about the format and others.
It would be helpful if each line would also contain the commit title.
Other than that it looks good to me.

CU
Uli


Nobuhiro Iwamatsu
 

Hi Pavel,

It can be created using the API on the project wiki[0]. Since
namespaces are available, we can also create hierarchies such as
5.10.y/v5.10.77 [1].
The wiki page is first filled with the commit ID, then the CIP kernel
developer writes the name after the commit they plan to review.
I believe this is too simple. We should include patch titles, so that
it is easier to review whole series. I also believe we should include
related patches from 4.19/4.4, so that they are reviewed together with
corresponding 5.10 change.
Agree. I have a question.
What are the triggers for creating pages for management?
Perhaps I think each LTS version and RC release will be the trigger. And a page will be created for each trigger.
And we will mainly review the list created on 5.10.y. We will also review patches that are only included in 4.4.y and 4.19.y.
Is this understanding correct?


I'm currently using this format, and scripts to generate it are
already in the repository. Could we use that for review management,
too?
                            v-- patch title
                      v-- stable tree version
                   v-- "o" means we are building it in some
                       configuration, " " means likely not relevant to us
            v-- stable commit id, not quite reliable
  v-- upstream commit id
 |50d50ca00 88c42f  : 5.10| perf bpf: Add missing free to bpf_event__print_bpf_prog_info()
 |51444729b 8ac9df o: 5.10| llc: fix out-of-bound array index in llc_sk_dev_hash()
 |df8fa74a0 8ac9df o: 4.19| llc: fix out-of-bound array index in llc_sk_dev_hash()
 |bf70e4f7d 8ac9df o: 4.4| llc: fix out-of-bound array index in llc_sk_dev_hash()
 |3dd3e81ad 9fec40 .: 5.10| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
 |b5cb963e8 9fec40 .: 4.19| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
 |21e4958e2 9fec40 .: 4.4| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
 |2a126e22e c7c386 o: 5.10| arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions
 |f9ee3718b c7c386 o: 4.19| arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions
 |78570c445 b8b831 .: 5.10| bpf, sockmap: Remove unhash handler for BPF sockmap usage
 |dbe525054 e0dc3b o: 5.10| bpf: sockmap, strparser, and tls are reusing qdisc_skb_cb and colliding
 |c45dfa514 1c360c .: 5.10| gve: Fix off by one in gve_tx_timeout()
 |3737feeca 10a6de o: 5.10| seq_file: fix passing wrong private data
 |614a5f5c0 6dc254 .: 5.10| net/sched: sch_taprio: fix undefined behavior in ktime_mono_to_any
 |25381c855 e140c7 .: 5.10| net: hns3: fix kernel crash when unload VF while it is being reset
 |14ec321cf 688db0 .: 5.10| net: hns3: allow configure ETS bandwidth of all TCs
 |379d4165f f64ab8 o: 5.10| net: stmmac: allow a tc-taprio base-time of zero
 |3772974cc c7cd82 o: 5.10| vsock: prevent unnecessary refcnt inc for nonblocking connect
 |69eb06075 c7cd82 o: 4.19| vsock: prevent unnecessary refcnt inc for nonblocking connect
 |5a54ee129 c7cd82 o: 4.4| vsock: prevent unnecessary refcnt inc for nonblocking connect
 |6ecbca5bf e5d5aa .: 5.10| net/smc: fix sk_refcnt underflow on linkdown and fallback
 |38bf1ce3e 4ca110 o: 5.10| cxgb4: fix eeprom len when diagnostics not implemented
 |41a958b00 4ca110 o: 4.19| cxgb4: fix eeprom len when diagnostics not implemented
Yes, I had that idea too.

Best regards,
Nobuhiro
________________________________________
差出人: Pavel Machek
送信: 2021 11 月 18 日 (木曜日) 3:09
宛先: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Cc: pavel@denx.de; cip-dev@lists.cip-project.org; uli@fpond.eu; jan.kiszka@siemens.com; masami.ichikawa@cybertrust.co.jp
件名: Re: New kernel patches review management


Hi!

I considered using the gitlab wiki to switch the current patch review
management to another.

The gitlab wiki can be used as a regular git repository and can be
viewed from his browser by writing its contents in markdown.

   e.g. git clone git@gitlab.com:cip-project/cip-kernel/linux-cip.wiki.git
This looks good.

It can be created using the API on the project wiki[0]. Since
namespaces are available, we can also create hierarchies such as
5.10.y/v5.10.77 [1].
The wiki page is first filled with the commit ID, then the CIP kernel
developer writes the name after the commit they plan to review.
I believe this is too simple. We should include patch titles, so that
it is easier to review whole series. I also believe we should include
related patches from 4.19/4.4, so that they are reviewed together with
corresponding 5.10 change.

I'm currently using this format, and scripts to generate it are
already in the repository. Could we use that for review management,
too?
                            v-- patch title
                      v-- stable tree version
                   v-- "o" means we are building it in some
                       configuration, " " means likely not relevant to us
            v-- stable commit id, not quite reliable
  v-- upstream commit id
 |50d50ca00 88c42f  : 5.10| perf bpf: Add missing free to bpf_event__print_bpf_prog_info()
 |51444729b 8ac9df o: 5.10| llc: fix out-of-bound array index in llc_sk_dev_hash()
 |df8fa74a0 8ac9df o: 4.19| llc: fix out-of-bound array index in llc_sk_dev_hash()
 |bf70e4f7d 8ac9df o: 4.4| llc: fix out-of-bound array index in llc_sk_dev_hash()
 |3dd3e81ad 9fec40 .: 5.10| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
 |b5cb963e8 9fec40 .: 4.19| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
 |21e4958e2 9fec40 .: 4.4| nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
 |2a126e22e c7c386 o: 5.10| arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions
 |f9ee3718b c7c386 o: 4.19| arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions
 |78570c445 b8b831 .: 5.10| bpf, sockmap: Remove unhash handler for BPF sockmap usage
 |dbe525054 e0dc3b o: 5.10| bpf: sockmap, strparser, and tls are reusing qdisc_skb_cb and colliding
 |c45dfa514 1c360c .: 5.10| gve: Fix off by one in gve_tx_timeout()
 |3737feeca 10a6de o: 5.10| seq_file: fix passing wrong private data
 |614a5f5c0 6dc254 .: 5.10| net/sched: sch_taprio: fix undefined behavior in ktime_mono_to_any
 |25381c855 e140c7 .: 5.10| net: hns3: fix kernel crash when unload VF while it is being reset
 |14ec321cf 688db0 .: 5.10| net: hns3: allow configure ETS bandwidth of all TCs
 |379d4165f f64ab8 o: 5.10| net: stmmac: allow a tc-taprio base-time of zero
 |3772974cc c7cd82 o: 5.10| vsock: prevent unnecessary refcnt inc for nonblocking connect
 |69eb06075 c7cd82 o: 4.19| vsock: prevent unnecessary refcnt inc for nonblocking connect
 |5a54ee129 c7cd82 o: 4.4| vsock: prevent unnecessary refcnt inc for nonblocking connect
 |6ecbca5bf e5d5aa .: 5.10| net/smc: fix sk_refcnt underflow on linkdown and fallback
 |38bf1ce3e 4ca110 o: 5.10| cxgb4: fix eeprom len when diagnostics not implemented
 |41a958b00 4ca110 o: 4.19| cxgb4: fix eeprom len when diagnostics not implemented

Best regards,
                                                                Pavel
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany