Le samedi 07 décembre 2019 à 00:48 -0800, Alan W. Irwin a écrit :
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.
Hello,
Yes it did. The whole point is that you assume patch numbers where it is in fact patch sets referred to with bug numbers. That's why they don't account for the total number of patches.
That is enough information for you to know that your assumptions are wrong and do a bit of research.
You could have found that yourself had you put more effort into looking at the wine-staging code than into thinking out an over-complicated pointless formula.
Could you let me know what the correct formula is for predicting the rebased patch number from report to report (which helps to evaluate the reliability of the staging patch number statistics that you present), and if that formula depends on information (my guess is it is the number of patches in staging that have just been deleted by thestaging maintainers because they judge those patches to not be worthwhile) that you currently do not include in your reports, could you include that important information in your following reports?
What makes you think that the information in the report is not reliable? Have you anything against the staging maintainers?
You're the only one that want to make a formula out of the reports. We don't have to provide you the formula you seek or provide the "important" (to you; What makes it important?) information that formula would need.
Your whole 'predicting to evaluate the reliability of the report' thing is nonsense. Predicting the future number of patch from report statistics is pointless as the number of patches is determined by specific issues and development and there is no way to predict what will be done next, and it certainly doesn't depend on the previous changes.
To me, you're just making ground for an argument in a convoluted way.
Regards.