Hi,
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.
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".
Once the bug it created and the patch(s) attached, email myself or Zebediah
asking for staging consideration. Please don't just CC me on a bug and assume
we know what you want.
Regards
Alistair.
Alistair Leslie-Hughes leslie_alistair@hotmail.com wrote:
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.
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".
Once the bug it created and the patch(s) attached, email myself or Zebediah asking for staging consideration. Please don't just CC me on a bug and assume we know what you want.
Do you realize that you've essentially killed the project?
On 26/05/18 15:39, Dmitry Timoshkov wrote:
Alistair Leslie-Hughes leslie_alistair@hotmail.com wrote:
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.
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".
Once the bug it created and the patch(s) attached, email myself or Zebediah asking for staging consideration. Please don't just CC me on a bug and assume we know what you want.
Do you realize that you've essentially killed the project?
No, we haven't killed the project. Just because you haven't different views on how wine-staging should be controlled and run, Doesn't mean we have killed the project.
Bugzilla already has a large number of patches that people have submitted for applications, so for most people the workflow won't change.
I have strong beliefs that wine-staging is for testing patches and then moving them on, once they are ready. Since taking on wine-staging we have reduced the number of patches by 200+, and out of that about ~75% have been accepted upstream. And in doing this, both project have prospered.
Coming from a developer, who has ~20 patches per release cycle, it strange that you have the opinion that *only you* can move *your patches* out of staging. Does that mean you have stopped the project moving forward? No, because whether you like it not, people are going to do it!
Alistair.
Alistair Leslie-Hughes leslie_alistair@hotmail.com wrote:
Do you realize that you've essentially killed the project?
No, we haven't killed the project. Just because you haven't different views on how wine-staging should be controlled and run, Doesn't mean we have killed the project.
Bugzilla already has a large number of patches that people have submitted for applications, so for most people the workflow won't change.
I have strong beliefs that wine-staging is for testing patches and then moving them on, once they are ready. Since taking on wine-staging we have reduced the number of patches by 200+, and out of that about ~75% have been accepted upstream. And in doing this, both project have prospered.
Please clarify some things then since you've voluteered to become new wine-staging maintainer: 1. what's your vision as a maintainer for the future of wine-staging besides an obvious attempt to perform a "total clearance" of existing patches? 2. what kind of development is going on or is planned in the staging tree after Sebastian's and Michael's departure? 3. what's the role of wine-staging.com in the project?
Coming from a developer, who has ~20 patches per release cycle, it strange that you have the opinion that *only you* can move *your patches* out of staging. Does that mean you have stopped the project moving forward? No, because whether you like it not, people are going to do it!
It's sad, but you clearly don't understand the things I tried to explain to you so many times already.
Please clarify some things then since you've voluteered to become new
wine-staging maintainer:
- what's your vision as a maintainer for the future of wine-staging
besides an obvious attempt to perform a "total clearance" of existing patches?
A "Total clearance" of wine-staging patches is impossible, however evaluating which patch actually fix a bug and can be moved on is.
I see wine-staging taking on patches which might be a quick fix to a user issue, e.g. a return S_OK, whereas upstream will only accept a complete implement. Also taking on a patchset, example d3d11-Deferred_Context (was has been in staging before my time), which in it current form works but wont be accepted upstream as is.
Some developers have had bad experiences trying to get patches accepted into wine and I get that. wine-staging isn't as strict to what is acceptable or not. Having the ability to get a patch tested with a large user base, so feedback can be received is what some developers need. Especially on patches which might cause regressions, MFStartup patch for example. Even your windowscodecs patches are an example of this process.
Wine-staging is also here to helping developers getting patches accepted into wine, either on there own back or by someone else.
Some patches, like nvcuda, might never move out of staging, however this patchset generally doesn't cause an issue for a rebase.
- what kind of development is going on or is planned in the staging tree
after Sebastian's and Michael's departure?
Short term, we will remove more of the burden of 900 patches that wine-staging contains. Some patchset cause a large amount of time to be consumed when anything in that area changes. Trying to minimum the rebase time would allow use to focus new and exciting patches.
Long term would be to have a flow of patches in and out of staging from users and ourselves.
- what's the role of wine-staging.com in the project?
The website, as we have just had it transferred to us, this is still being discussed.
It's sad, but you clearly don't understand the things I tried to explain to you so many times already.
I understand but see things differently. How about seeing it from my side, Anytime windowscodecs, for example, is changed, there is large chance I have to rebase 1 or more patches I shouldn't have to. Taking time away from developing other patches. You could then send me the update patches but in the mean time I have to disable 4 patchset while I wait.
Alistair.
Alistair Leslie-Hughes leslie_alistair@hotmail.com wrote:
It's sad, but you clearly don't understand the things I tried to explain to you so many times already.
I understand but see things differently. How about seeing it from my side, Anytime windowscodecs, for example, is changed, there is large chance I have to rebase 1 or more patches I shouldn't have to. Taking time away from developing other patches.
That's a routine job of any maintainer.
You could then send me the update patches but in the mean time I have to disable 4 patchset while I wait.
If rebasing some patches is really a problem for you then there's always an option to sign off.
On 26/05/18 19:11, Dmitry Timoshkov wrote:
That's a routine job of any maintainer.
You could then send me the update patches but in the mean time I have to disable 4 patchset while I wait.
If rebasing some patches is really a problem for you then there's always an option to sign off.
Rebasing patches isn't the issue. Its the fact these patches should already be upstreamed and are wasting time that could be used for other things.
Alistair.
Alistair Leslie-Hughes leslie_alistair@hotmail.com wrote:
That's a routine job of any maintainer.
You could then send me the update patches but in the mean time I have to disable 4 patchset while I wait.
If rebasing some patches is really a problem for you then there's always an option to sign off.
Rebasing patches isn't the issue. Its the fact these patches should already be upstreamed and are wasting time that could be used for other things.
My patches are very small fraction of the staging tree. I'd suggest to either stop complaining that rebasing patches takes your precious time, or simply stop pretending to be a maintainer. Other option is to simply disable the patches and forget about them.
On Sat, 26 May 2018 08:27:05 +0000 Alistair Leslie-Hughes leslie_alistair@hotmail.com wrote:
- what's the role of wine-staging.com in the project?
The website, as we have just had it transferred to us, this is still being discussed.
From the perspective of user support: the continued existence of a separate website is probably the biggest reason we still have users who see staging as a separate, competing project rather than an official branch of Wine. My preference would be to have wine-staging.com redirect to https://wiki.winehq.org/Wine-Staging.
It would also be helpful if staging releases were announced on the main page, just like stable and development, instead of merely sending a notice to wine-devel.
On 26 May 2018 at 11:34, Dmitry Timoshkov dmitry@baikal.ru wrote:
Please clarify some things then since you've voluteered to become new wine-staging maintainer:
- what's your vision as a maintainer for the future of wine-staging
besides an obvious attempt to perform a "total clearance" of existing patches? 2. what kind of development is going on or is planned in the staging tree after Sebastian's and Michael's departure? 3. what's the role of wine-staging.com in the project?
Since Alistair was so kind to describe how he sees Staging and its role in the large Wine project, perhaps it's only fair to ask the same of you. Concretely:
- Do you see Staging as part of the larger Wine project, or as a fork competing with it? - In case you think Staging should be part of the Wine project, do you think it's important for patches to flow upstream? If not, why not? - If patches should flow upstream, what process would you propose to ensure that happens?
Henri Verbeet hverbeet@gmail.com wrote:
Since Alistair was so kind to describe how he sees Staging and its role in the large Wine project, perhaps it's only fair to ask the same of you. Concretely:
- Do you see Staging as part of the larger Wine project, or as a
fork competing with it?
Let's be sincere on this: wine-staging now is dead regardless of the new maintainership attempts.
- In case you think Staging should be part of the Wine project, do
you think it's important for patches to flow upstream? If not, why not?
It's been always a declaration without obvious results.
- If patches should flow upstream, what process would you propose to
ensure that happens?
I have no idea about the way of managing patches that the new maintainers will follow, but obviously there were the reasons why the wine-staging project has been created and why so many (even trivial) patches have been collected there for some years. It will take some time to re-establish trust again, I'd suggest to calm down and see how it goes instead of trying to heat up on the rough edges again, especially from the new maintainers side.
Henri Verbeet hverbeet@gmail.com wrote:
- If patches should flow upstream, what process would you propose to
ensure that happens?
Speaking of the process I think that it would be fair to ask that the patches get reviewed *before* one (me if we're talking about my work) will send them to wine-devel for inclusion. That would certainly save quite a bit of time/effort/motivation on both sides. Personally I'd like to see the list of most wanted patches, it's unreasonable to expect a pile of them to go at once.
On 27/05/18 03:31, Dmitry Timoshkov wrote:
Henri Verbeet hverbeet@gmail.com wrote:
- If patches should flow upstream, what process would you propose to
ensure that happens?
Speaking of the process I think that it would be fair to ask that the patches get reviewed *before* one (me if we're talking about my work) will send them to wine-devel for inclusion. That would certainly save quite a bit of time/effort/motivation on both sides. Personally I'd like to see the list of most wanted patches, it's unreasonable to expect a pile of them to go at once.
Cool, Here is small list of patches of your that I would like to see upstreamed. I don't claim that they are popular or will be used widely but they are simple. At no point would I expect anyone to submit a pile.
- advapi32-WinBuiltinAnyPackageSid/* Since this was to correct an installer issue we can assume that others will also be affected. The change in the a test make it easier to extend them in the future.
- windowscodecs-GIF_Encoder/000[124] - These are the GetEncoder support for the various formats. These 3 patches by themselves wont correct any bug but shouldn't cause a regression either. I have a test patch in the works for the Encoder patches, which I'll commit to staging once it passes on the test bot. Feel free to submitted it as well if/when you send the other patches. I'm happy to write some test cases, if that means you will upstream more of you patches over time.
The most popular patch is ntdll-LdrRegisterDllNotification, as Battle.Net user cannot run games without it. The implementation is correct and easily verified by a simple custom test. However, the tests included failed on everything but Windows XP. We are still working though adjusting the tests so that every time MS changes a dll dependency, the tests don't start failing again.
The next one would be d3d11-Deferred_Context. (Hint hint) ;)
Alistair.
Le samedi 26 mai 2018 à 13:39 +0800, Dmitry Timoshkov a écrit :
Do you realize that you've essentially killed the project?
I find this offensive.
I did not ask about dev.wine-staging.com to allow you to make personal attacks against other people.
On 2018-05-26 01:23, Alistair Leslie-Hughes wrote:
Hi, (...)
First of all, thanks for taking all your work in doing this and for communicating clearly :)
Once the bug it created and the patch(s) attached, email myself or Zebediah
Imo this is the achilles' heel in the new proposed process, since it makes the process pretty opaque and moves conversations to private. Maybe a feature could be added to bugzilla so a patch or bug could be marked as proposed for staging and then have different status like accepted, rejected, needs work, or something similar I can imagine a few similar ways to improve this part of the process (not necessarily centered on staging itself, but maybe on patch status).
For example, I have proposed yesterday the inclusion of patches from bugs 44089 and 45127 to Zebediah on irc. Other wine developers where there and there was some great feedback from everyone, but that's somehow lost it doesn't reflect in bugzilla or other public records. With a personal email a similar thing would have happened maybe one gets good or bad feedback but that won't necessarily reflect in bugzilla.
Again, thanks a lot both to you and Zebediah for your work on wine-staging.
Regards
Pablo
On 26/05/18 21:00, Pablo Martin wrote:
Imo this is the achilles' heel in the new proposed process, since it makes the process pretty opaque and moves conversations to private. Maybe a feature could be added to bugzilla so a patch or bug could be marked as proposed for staging and then have different status like accepted, rejected, needs work, or something similar I can imagine a few similar ways to improve this part of the process (not necessarily centered on staging itself, but maybe on patch status).
Thanks for your input. This is going to take some time to completely flesh out but adding a "stating status" could be a start. We will still need in investigate in due course, but is worth looking into.
For example, I have proposed yesterday the inclusion of patches from bugs 44089 and 45127 to Zebediah on irc. Other wine developers where there and there was some great feedback from everyone, but that's somehow lost it doesn't reflect in bugzilla or other public records. With a personal email a similar thing would have happened maybe one gets good or bad feedback but that won't necessarily reflect in bugzilla.
Fair point. Information is discussed in various forms and that is great, and bugzilla will miss this information. At end of the day, each staging patchset should be associated with a bugzilla issue. So, *anybody* looking at a patchset can get an idea of what application was affected and how.
Thanks. Alistair.
On 2018-05-26 13:33, Alistair Leslie-Hughes wrote:
On 26/05/18 21:00, Pablo Martin wrote:
Maybe a feature could be added to bugzilla so a patch or bug could be marked as proposed for staging and then have different status like accepted, rejected, needs work, or something similar I can imagine a few similar ways to improve this part of the process (not necessarily centered on staging itself, but maybe on patch status).
Thanks for your input. This is going to take some time to completely flesh out but adding a "stating status" could be a start. We will still need in investigate in due course, but is worth looking into.
Let me know if you decide about some concrete specs about what you want I can work on implementing it in bugzilla if no one with more bugzilla specific experience is willing or free to do it.
Regards,
Pablo
I guess our WineConf talk has been coöpted...
On 05/26/2018 12:39 AM, Dmitry Timoshkov wrote:
Do you realize that you've essentially killed the project?
We haven't killed wine staging, nor do we intend for wine-staging to die. What we would like to do is move staging away from being a fork of the WineHQ project and towards a, well, staging branch, the way that most people seem to envision it. Sebastian and Michael (and you) may never have said or considered outright that Staging was a fork, but it has been quite effectively treated that way. There are plenty of good-quality patches there, especially yours, that have simply never been submitted upstream for reasons that are less than sanguine.
I understand that you've been frustrated with WineHQ's review process. I've been frustrated with it myself. I personally think there is value in having a place where new developers can get acquainted with Wine in a more friendly and helpful environment. To what degree I can help provide that environment is less than clear, of course, but regardless I think Staging should continue on to fill this void. However, I think that trying to achieve this by distancing Staging from the rest of the project is more detrimental than helpful to its overall goal.
As Rosanne says, getting rid of the Staging website is the best thing we can do to eliminate the idea that Staging is a fork. Therefore this is what we're trying to do. Since many patches are picked up from Bugzilla to solve bugs, and Bugzilla also has some degree of infrastructure for tracking Staging patches, we'd like to merge the staging patch tracker there. Similarly we'd like to, as Rosanne says, redirect the www.wine-staging.com website to a WineHQ wiki page.
I'm admittedly less than comfortable with the idea of "e-mail Alistair or me". I do agree with Pablo that such conversations should be public. Perhaps a good solution would be to CC one (or preferably both) of us on a bug, with a request to include the patch in Staging and some description of what the patch does. Another solution would perhaps be to try to use wine-devel for Staging submissions.
ἔρρωσθε, Zeb
Le vendredi 25 mai 2018 à 23:23 +0000, Alistair Leslie-Hughes a écrit :
Hi,
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.
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".
Once the bug it created and the patch(s) attached, email myself or Zebediah
asking for staging consideration. Please don't just CC me on a bug and assume
we know what you want.
Regards
Alistair.
Hi,
This is fine for me.
The way I see it is this:
- Someone reports a bug; - Someone attach a patch to the bug; - * Someone send a recommendation for the patch to the staging team; - The staging team examine the patch; - The staging team comments whether the patch is accepted or not; - If rejected, the staging team notifies the bug with a comment; - If accepted, the staging team marks the bug as STAGED and put the patchset in the proper field; - Discussion about the staging rejection/patch implementation details are made in the comments; - Patch author attach new implementation and marks old patch obsolete; - When someone thinks the patchset is ready for upstream submission he can make an appropriate statement in the comments.
Everyone involved in the bug (affected users, testers, patch author, reviewers, staging maintainers) are given a central place where to discuss and be notified of feedback/improvements/updates.
I really don't see any big issue with using bugzilla to track staging patchset.
* about patch recommendation implementation: What about having a form on wine-staging.com (or winehq.org) with a simple bug # field and a 'recommend to staging' button? The form would trigger a script that send an email notification to the staging maintainers addresses listed in a file. The whole thing could be maintained through github (I think the wine-staging.com is maintained through github. Is it?)
The staging documentation can go into the wiki and link to the patchset recommendation form.
It could also be implemented in bugzilla itself with a 'recommend to staging' button, if bugzilla permits.
Regards,
-
Alistair Leslie-Hughes -
Dmitry Timoshkov -
Henri Verbeet -
Olivier F. R. Dierick -
Pablo Martin -
Rosanne DiMesio -
Zebediah Figura