On Tue, Nov 21, 2023 at 06:36:10PM +0800, David Gow wrote: > The other question is how to handle outdated results when a new patch > revision is sent out. Personally, I think this is something we can > solve similarly to 'Reviewed-by', depending on the extent of the > changes and cost of the tests. I suspect for most automated tests, > this would mean never carrying the 'Tested-with' tag over, but if > testing it involved manually building and running kernels against 50 > different hardware setups, I could imagine it making sense to not > re-do this if a new revision just changed a doc typo. If a URL is used > here, it could contain version info, too. One thing with Reviewed-by that's a bit different to testing is that Reviewed-by is generally invalidated by doing a change to the specific patch that needs at least a commit --amend. > Personally, I'd like to require that all patches have a 'Tested-with' > field, even if there's not a corresponding 'V' MAINTAINERS entry, as > people should at least think of how something's tested, even if > there's not a formal 'test suite' for it. Though that seems a > longer-term goal A requirement feels like it'd be pretty painful for my workflow, or at least result in me adding the thing in hope of what I'm actually going to do rather than as a result of the testing - all my CI stuff (including what I do for outgoing patches) is keyed off the git commits being tested so updating the commits to reflect testing would have unfortunate side effects. > The questions I think we need to answer to get this in are: > 1. Do we want to split this up (and potentially land it > piece-by-piece), or is it more valuable to have a stricter, more > complete system from the get-go? I think splitting things makes sense.
Attachment:
signature.asc
Description: PGP signature
