On Oct 2, 2014 5:21 PM, "Sebastian Lackner" <sebastian@fds-team.de> wrote:
>
> Hi Roderick,
>
> On 02.10.2014 06:59, Roderick Colenbrander wrote:
> > Hi Michael,
> >
> > Thanks for your long email about some sort of wine 'staging' project. I
> > understand what you are you trying to accomplish, but I have various
> > concerns, which I will share below.
> >
> > The initial motivation for this project seems to be to allow users to test
> > patches at an earlier stage. It may allow users to run their app sooner.
> > For developers it can give their code more testing, which I agree can be
> > useful.
> >
> > My main concern is that the quality of a lot of the patches is
> > unfortunately so-so, with various lose ends and side effects various
> > developers can't oversee. AJ is right to reject such patches. This can be a
> > hinder for a new developers, it is not always as easy to get feedback and
> > yes some mentoring for new developers can really help.
>
> As Michael already said in his previous mail, rejecting patches if they still contain flaws, is the right and the only way to do it. And of course having a more active mailing list would speed up the process of upstreaming stuff. Nevertheless, this has nothing to do with "new developers", we know _several_ examples of long-contributing developers (don't want to point at anyone...) who have the same impression, that just sending patches and getting it accepted _or_ useful feedback for improvements just doesn't work in most cases on wine-devel. At my opinion it mainly has to do with the interest of developers to get specific issues fixed. If there is not enough interest, then a lot of useful work might just not get enough attention, and is lost, even if it was for example actually done by a _payed_ GSoC student. Even if the implementation is _not used at all_ for the final version, it is still useful to see the ideas of other developers, or for example included testcases, to confirm tha
> t the "better" implementation is also correct. Developing is a process of improving a code over and over again, and there is no way to do that in an official repository. I personally like the current approach of shared repo, and it is not really that different from all the private developer repositories, which are also included in various Wine builds (wine-multimedia, wine-csmt, ...).
>
> >
> > Over the years there have been various projects in different forms like
> > PlayOnLinux to allow users to run Wine with non-upstreamed patches. As you
> > know the main concern of PlayOnLinux is that due to all the patching it is
> > not vanilla Wine anymore, but a 'tainted version'. This makes us typically
> > reject bug reports, because we don't know what code went in it, which can
> > waste a developers time.
>
> We are aware of that, and thats perfectly fine (more details below).
>
> >
> > No matter how good the intentions are to do a better job than PlayOnLinux,
> > I'm skeptical. I actually went over several of the patches in the repo and
> > various of them look incorrect. I understand that they may make app Z work
> > and while they may not always be as evil as PlayOnLinux-style hacks, I
> > still don't want them to be out in the public. In my opinion any tainted
> > Wine is bad for Wine developers. Yes, user may test your new patch, but I
> > expect to get a lot of issues back due to other incomplete patches with
> > side effects.
>
> "various look incorrect" <- Isn't that exactly what we were talking about? ;) If you spotted an error immediately while taking a short look, why don't you report it to us? If you mean one of the few patches, where we're not using an optimal solution yet, feel free to suggest a better one. Not sure which patches you were looking at, but most of them are correct, and might only need minor cleanup. We wouldn't add any patches where we are aware of, that it will have negative side affects for other applications. For most patches we also spend a lot of time discussing the possible effects before we come to a conclusion, if it should be added or not.
>
> >
> > In an ideal world there would be no need for your project, because all
> > patches make it upstream quickly. I think the discussion should be more on
> > how to get closer and closer to this situation. I think it should more be
> > found in mentoring and providing more feedback.
>
> Well, feel free to provide concrete suggestions if you have a better idea how to solve that. ;)
>
> >
> > Since Wine is an open source project, nobody forbids you from working on
> > your customized Wine. Providing builds to users to try it is fine with me,
> > but clearly don't mark it as the official Wine, but as you already doing by
> > calling it 'wine-compholio'.
> >
> > What does really scare me are the Fedora Wine builds. After you said that
> > they incorporate your changes, I checked the rpm and indeed it uses 150+
> > custom patches from your repo. In my opinion, distro packages need to be as
> > vanilla as possible to prevent the PlayOnLinux-like bug rejection issues.
> > Sometimes build system change or some minor change is needed, but such an
> > amount of patches is not justified. Myself I don't have much time to work
> > on Wine anymore these days, but if I got bugs from Fedora users, I would
> > reject their bugs. I hope other Wine developers would really do the same,
> > because the packages clearly can't be trusted.
>
> Please note that it was never our idea to get these patches into regular distribution packages. In case of Fedora the packager contacted us, and even proceeded after both Michael and I told him about the possible consequences, and that we personally don't recommend to do that. I will not cite anything here, as this was discussed in private mail contact, but I think the Fedora guys are totally aware that each bug report by Fedora users can get rejected without a comment.
>
> Recently I also opened a bug report, since I would really prefer to have a clear statement somewhere, that people shouldn't report bugs to winehq, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1147271
>
> >
> > Overall I know the intentions are good to allow users to test new code
> > sooner and allow developers to get their stuff test sooner. I'm really
> > skeptical about the benefit for developers due to the tainted Wine builds.
> > I think overall it may actually be more negative than positive for Wine.
>
> I don't think so. The question is just what is better: Having users reporting the same well-known issues over and over again (have to be identified as duplicates, also wastes time!), or probably a follow-up/regression issue which cannot be reproduced with vanilla Wine (bug reports can be easily closed, when error description doesn't match on developer machine). As you might know, the second problem already applies to a _huge_ amount of bugs, since users already use various (often unnecessary) winetricks recipes without knowing what they do, or report bugs when using PlayOnLinux or at least wine-multimedia (= _every_ Ubuntu user). Unless Wine reached a state, where it works out of the box with almost every app, there will always be a specific part of users with patched/modified versions - our approach is just a bit more combined and organized than some of the previous attempts, by reducing this to work-in-progress solutions. ;)
>
> If you want a solution to find out if a version contains our patches: Just ask the users on the bug tracker to run "wine --patches".
>
> >
> > Thanks,
> > Roderick
> >
>
> Regards,
> Sebastian

Having "wine --version" report wine-compholio would be a welcome change, imo.

Also a message to terminal a la winepulse, as Rosanne suggested.