[wine-devel] Wine staging 4.21 release

[Olivier F. R. Dierick]

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.
-- 
        Olivier F. R. Dierick
        o.dierick at piezo-forte.be