On 7/15/22 02:11, Giovanni Mascellani (@giomasce) wrote:
On Thu Jul 14 18:35:05 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 7/14/22 08:07, Giovanni Mascellani wrote: > From: Giovanni Mascellani <gmascellani@codeweavers.com> > > The notifications are not sent immediately, but pushed to a queue > and sent at the next DoWork() call. This seems to correspond to what > happens on Windows. > > Corresponding to upstream commit 9e53dbeebfdd8d0f23144b8b1aa895bca2727977. > > Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com> > --- > libs/faudio/src/FACT.c | 26 ++++++++++++++++++++++++++ > libs/faudio/src/FACT_internal.h | 1 + > 2 files changed, 27 insertions(+) > Can we please not do this? It's mean enough to distributions to bundle software, but it's worse when we're bundling local changes as well. Can we just wait for a new version to be released and then import that? _______________________________________________ wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.orgI specifically asked Alexandre and he said it's ok.
Yes, this petition is directed as much at Alexandre as at anyone else.
In general I agree we don't want to fork from upstream, but since that change was already accepted upstream it's not a fork. The next time we sync from upstream the change will be there anyway and we're back in the mainline. Adding this change now allows me to submit this PR now instead of waiting a month, and I can't see any drawbacks.
With this change, our bundled FAudio does not correspond to any version of FAudio upstream, release or not, which makes things difficult for distributions. If we want to update to unreleased versions, can we please at least update the whole tree to e3c444e4f819, rather than cherry-picking?