Wine staging tree

Thu Oct 2 11:02:34 CDT 2014

On Oct 2, 2014 5:21 PM, "Sebastian Lackner" <sebastian at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20141002/0ea85a42/attachment-0001.html>