[wine-devel] Wine staging 4.21 release

[Sveinar Søpler]

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
> __________________________
>