I think you are overcomplicating something that does not need to be.
The "Report" is somewhat trunkated. So are you kinda saying you would want a more detailed report on what patches and things that are changed? And that the report posted does not meet a proper standard? Probably a fair request, but i don't know what the real benefit would be unless you miss some important patchset that gets removed and breaks something the staging devs are not aware of - which do happen from time to time.
I guess the "best" way for you personally if you really want to get into stuff like that is to pay attention to the commit messages on GIT. None of us live in a perfect world, and i do not think it is overly easy (or informative for everyone) to make the report too detailed.
Sveinar
On 07.12.2019 09:48, Alan W. Irwin wrote:
On 2019-12-05 14:03+0100 Olivier F. R. Dierick wrote:
Le mercredi 04 décembre 2019 à 14:56 -0800, Alan W. Irwin a écrit :
On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small
[...]
Could you explain how these patch numbers in your report are related with each other?
Hello,
The numbers between brackets are winehq.org bugzilla bug numbers.
Hi Olivier:
Thanks for trying to be helpful, but your answer did not respond to the question which was about how to account for the total number of patches in each category mentioned in these reports.
To explain further, my curiosity about this question was stimulated by these staging "accounting" numbers from recent reports:
Version rebased upstreamed added updated predicted predicted-rebased T U A u P D
4.17 855 5 9 7 n/a n/a 4.18 850 1 1 3 855 5 4.19 840 8 1 1 843 3 4.20 832 8 1 3 833 1 4.21 833 0 6 2 838 5
I assume the "T" column is the total number of patches in staging, i.e., the report is only sent out when the rebasing work is completed, but could someone confirm that? I also assume U reduces the total number in staging by that number, A increases the total number in staging by that number, and u leaves the total number in staging unchanged. And I have used
P = T' - U - A
to calculate the predicted number of patches from one report to the next
and
D = P - T
to calculate the discrepancy between predicted and actual values where T' is taken from the previous report and T, U and A are taken from the current report.
In every case D is positive (P always greater than T) so I hypothesize there is another kind of patch category not currently mentioned in the report that explains this discrepancy (e.g., patches which the staging developers have removed from staging). Could someone please describe the true reason why D is always positive?
Furthermore, my view is it would be helpful if patch categories (deletions from staging or whatever) that are currently not mentioned in these reports should be mentioned in future reports.
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________