You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 23, 2024. It is now read-only.
It's likely we don't need all the data we now store in the database and it's contents can be largely simplified. This needs to be properly discussed and agreed upon.
For the start:
patchtest table looks like a residue of previous functionality where new patches from Patchwork were cross-checked with the DB content. With sending the emails (and eventually setting checks / tags in Patchwork), we shouldn't need it.
testrun contains all test runs, while only baseline tests are really checked. We can use baseline_tests instead, or only store required information in baseline table (and update rows after new successful runs)
we shouldn't need full history of all tested patches (table patch), combination of last patch info stored with patchwork data and pendingpatches table should be enough to function. With the emails and checks / tags mentioned in the first point, it's useless to keep them
There might be something I'm missing why the above ideas won't work, and other things I haven't mentioned. Let's brainstorm about them and create a new, simpler DB schema and contents.
The text was updated successfully, but these errors were encountered:
possibly get rid of patchsource and include needed info with patches directly (need to double check if the table is needed anywhere else and modify it too)
It's likely we don't need all the data we now store in the database and it's contents can be largely simplified. This needs to be properly discussed and agreed upon.
For the start:
patchtest
table looks like a residue of previous functionality where new patches from Patchwork were cross-checked with the DB content. With sending the emails (and eventually setting checks / tags in Patchwork), we shouldn't need it.testrun
contains all test runs, while only baseline tests are really checked. We can usebaseline_tests
instead, or only store required information inbaseline
table (and update rows after new successful runs)we shouldn't need full history of all tested patches (table
patch
), combination of last patch info stored with patchwork data andpendingpatches
table should be enough to function. With the emails and checks / tags mentioned in the first point, it's useless to keep themThere might be something I'm missing why the above ideas won't work, and other things I haven't mentioned. Let's brainstorm about them and create a new, simpler DB schema and contents.
The text was updated successfully, but these errors were encountered: