Date
1 - 4 of 4
Coordinating stable reviews
|
Pavel Machek
Hi!
It is good to review "stable" patches soon, because such reviews are more useful for the stable community, and because when bug is spotted, it is easier to get patch dropped in the 5.10.X-rc phase than waiting for 5.10.X release and then having patch reverted in 5.10.X+1. Unfortunately, we don't have good system for coordinating reviews in -rc phase. There's a script (commit.py) that produces one-line-per-patch output suitable for review. One possibility would be to have shared place somewhere reviewers could tag "I'm working on these patches". I don't believe lts-commit-list.git repository is suitable for that; format suitable for review is different from what we have in lts-commit-list, and there is going to be multiple updates per day in busy periods. We don't really need commit messages for this. Actually, we don't really need to keep history, either. It would be good if system could be controlled from command line for easy scripting. Any ideas what kind of service could be used for this? Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany |
|
|
|
Pavel Machek
Hi!
We don't really need commit messages for this. Actually, we don'tI guess I should mention alternate possibilities. We could try to somehow "hash" the commits... Perhaps I'd review all the patches where upstream sha begins with 0-6. But patches in -stable often come in series that depend on each other, and it would be good if single person reviewed them. We could also split based on first character of subject, or on subsystem patch touches. I guess that would have other disadvantages like uneven distribution of work when big ammount of btrfs fixes hits the -stable. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany |
|
|
|
Ulrich Hecht
On 09/27/2021 12:09 PM Pavel Machek <pavel@...> wrote:gitlab comes to mind. IIUC, wiki pages are part of the project, but contained in a separate git repository. The output of commit.py is practically markdown already; just add a table header and some extra "|"'s, and you're good. There will be a history, but I think that can be safely ignored. CU Uli |
|
|
|
Nobuhiro Iwamatsu
Hi,
toggle quoted message
Show quoted text
-----Original Message-----It's different from the current system, but how about using patchwork? Somehow forward the patch posted to stable@... as -rc to cip-dev and review it at patchwork.kernel.org. It doesn't meet all requests because it can't be operated from the command line. Also, as Ulrich wrote, I think it's a good idea to use gitlab. I suggest a way to comment on the commit instead of using the gitlab wiki. for example, we can comment on the following URL (commit). We need to investigate, but I think it can be manipulated from the command line using Gitlab's API or libraries. https://gitlab.com/cip-project/cip-kernel/linux-cip/-/commit/d25b48d4d3ef1ce75ce5628a8a3ba60a2427090f There's a script (commit.py) that produces one-line-per-patch outputBest regards, Nobuhiro |
|
|