[prev in list] [next in list] [prev in thread] [next in thread]
List: wine-devel
Subject: Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
From: Brian Vincent <brian.vincent () gmail ! com>
Date: 2009-06-30 22:13:09
Message-ID: 3010968c0906301513s21ccc959qe21aa0e5401be39f () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jun 26, 2009 at 2:42 PM, Mike Kronenberg <
mike.kronenberg@kronenberg.org> wrote:
> OS X
> My main concern is to have usable builds. Ie, usable without the need of a
> terminal. People on OS X don't care about how stuff works, it just has to
> work.
>
> Vanilla build
> I totally agree that by adding certain patches, the builds can't be
> considered as vanilla.
> I'll recheck the necessity of the patches again on Tiger and Leopard and
> they really get less and less.
My $.02: we've got two different problems we're trying to solve with the
same build. We're trying to give the user a great user experience by
including lots of extras; and this is a Noble Goal and a Good Thing. We're
also trying to collect good bug reports that aren't tainted by crap; and
this is also a Noble Goal and Good Thing.
It seems like this could be solved by two different builds. Keep the
Darwine stuff the way it is, just put a huge warning label on it that says
the code is unsupported. Second, provide another binary build that's as
much of a vanilla wine as possible. Because we like our user community and
we like to be nice to them, we'll provide links to BOTH of them from the
Wine website as well as put the giant UNSUPPORTED stamp on the first one.
Then we tell Mac users if they want to submit a bug report they should
download and install this other package and try to reproduce their bug.
Now, the side effect there is that maybe it will improve the quality of bugs
being reported. Folks who take the time to download that extra package, set
up their environment properly, etc, etc, well, they probably have the
ability to also write a coherent bug report. (You could also argue that
rather than provide this second package you could simply make people compile
it themselves, but I'd argue that it makes it an order of magnitude harder
to submit a bug report and we'd effectively alienate the vast majority of
the user community.)
Oh, and we have a branding issue where this code magically transforms from
Wine into something by another name. I completely understand why we're not
a big fan of that. I also understand it could break things if you attempt
to change paths. However, the sooner you do that, the sooner it gets done.
It's actually doing the user community a disservice by calling it Darwine
rather than Wine. If you throw "Darwine" into Google, you don't turn up a
single site on the first page that's a Wine web page. As a result, all the
great things like our AppDB, Wiki, developer tips, etc aren't a resource for
that user community.
(Wow! Look at our Page Rank for "Wine". We need to start selling bottles of
wine on winehq.org.)
-Brian
[Attachment #5 (text/html)]
On Fri, Jun 26, 2009 at 2:42 PM, Mike Kronenberg <span dir="ltr"><<a \
href="mailto:mike.kronenberg@kronenberg.org">mike.kronenberg@kronenberg.org</a>></span> \
wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> <div><div></div>OS X<br></div>
My main concern is to have usable builds. Ie, usable without the need of a terminal. \
People on OS X don't care about how stuff works, it just has to work.<br> <br>
Vanilla build<br>
I totally agree that by adding certain patches, the builds can't be considered as \
vanilla.<br> I'll recheck the necessity of the patches again on Tiger and Leopard \
and they really get less and less.</blockquote><div><br>My $.02: we've got two \
different problems we're trying to solve with the same build. We're trying \
to give the user a great user experience by including lots of extras; and this is a \
Noble Goal and a Good Thing. We're also trying to collect good bug reports that \
aren't tainted by crap; and this is also a Noble Goal and Good Thing. <br> \
<br>It seems like this could be solved by two different builds. Keep the Darwine \
stuff the way it is, just put a huge warning label on it that says the code is \
unsupported. Second, provide another binary build that's as much of a vanilla \
wine as possible. Because we like our user community and we like to be nice to them, \
we'll provide links to BOTH of them from the Wine website as well as put the \
giant UNSUPPORTED stamp on the first one. Then we tell Mac users if they want to \
submit a bug report they should download and install this other package and try to \
reproduce their bug. Now, the side effect there is that maybe it will improve the \
quality of bugs being reported. Folks who take the time to download that extra \
package, set up their environment properly, etc, etc, well, they probably have the \
ability to also write a coherent bug report. (You could also argue that rather than \
provide this second package you could simply make people compile it themselves, but \
I'd argue that it makes it an order of magnitude harder to submit a bug report \
and we'd effectively alienate the vast majority of the user community.)<br> \
<br>Oh, and we have a branding issue where this code magically transforms from Wine \
into something by another name. I completely understand why we're not a big fan \
of that. I also understand it could break things if you attempt to change paths. \
However, the sooner you do that, the sooner it gets done. It's actually doing \
the user community a disservice by calling it Darwine rather than Wine. If you throw \
"Darwine" into Google, you don't turn up a single site on the first \
page that's a Wine web page. As a result, all the great things like our AppDB, \
Wiki, developer tips, etc aren't a resource for that user community.<br> \
<br>(Wow! Look at our Page Rank for "Wine". We need to start selling \
bottles of wine on <a \
href="http://winehq.org">winehq.org</a>.)<br><br>-Brian<br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic