Resent to wine-devel.
2018-05-26 11:33 GMT+02:00 Kai Krakow kai@kaishome.de:
Hello!
First words: Thanks to you and many other people here for a really fantastic job of bringing thinks forward in wine-vanilla. I think (and can confirm personally) that Wine made huge steps forward in the past months, and I attribute that mostly to the efforts that have gone into reviving the staging project and getting patches into mainline. For me, a lot of games have seen vast improvements without using the staging patchsets. I only cherry-pick a few patches from staging (like nvcuda/nvapi) to get things work. I don't use the patchset workflow but instead rely on the all-patches-rebased branch from wine-staging to do that, rebasing my own cherry-picks. And I've seen lots of improvements here, too, for wine-staging: Rebase conflicts have gone down a lot. And especially this is a huge time saver... Time for putting efforts into other parts of development.
So great thanks to all people involved, even when some decisions may cause some rumblings here and there, I can imagine the bigger plan of this with a great result.
But I think it makes sense to not blindly accept everything and add _valuable_ discussion.
Personally, I liked the old wine staging patchset site a lot: It was straight forward to use and had an easy to follow review workflow. So I also fear if and how the move to bugzilla could work out in the end. But looking at bugzilla, that place seems to do its job well. What's missing tho is linking patchset status (in the winehq site) to bugzilla entries. I hope that will be added.
2018-05-26 1:23 GMT+02:00 Alistair Leslie-Hughes leslie_alistair@hotmail.com:
Since any patches submitted for being included in wine-staging will be fixing a bug in wine. It has been decided that we'll use bugzilla for submission. This way anyone can follow the follow the status of patch, discussion of what/why things changed and when it's finally upstream.
I think this is somewhat a great move. I was always completely missed descriptions of the purpose of patches. Almost all git commit descriptions are simple one-liners, without describing the underlying purpose or motivation of the patch. In the long run it could make following interesting patches (and even finding them) much more easy.
We are trying to avoid the situation of "What was that patch trying to fix", or
"I see what it's doing but what application can I use to verify".
Great that improvements are planned here.
Once the bug it created and the patch(s) attached, email myself or Zebediah
I'd prefer something that resembles the original wine-staging patch review system a little more.
asking for staging consideration. Please don't just CC me on a bug and assume we know what you want.
This is very important.
Thanks and regards, Kai