/. wants a fork

[Remco]

Oh great, now there is poison on slashdot:

http://tech.slashdot.org/article.pl?sid=09/05/24/2044239

Let's not fork, shall we?

Remco

[Henri Verbeet]

2009/5/25 Remco :
> Oh great, now there is poison on slashdot:
>
> http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
>
> Let's not fork, shall we?

Out of pure curiosity, does anyone know if this "Elektroschock" guy
has a real name?
Personally I don't see a lot of "dissatisfaction of core developers
with the arbitrary project governance", but I guess it's been a while
since we had a "real" Governance thread.

[Tommy]

Hello,

I'd like to ask why you can't include this engine until someone does
it the "right" way? If it doesn't do anything until user will manually
trigger it, it shouldn't do any harm. If it can't be possible, I can
provide a script to automatically download WINE from git, apply DIB
engine patches and compile, so maybe someone could post it on WINE
website for really DIB-engine-curious users.

2009/5/25 Henri Verbeet :
> 2009/5/25 Remco :
> > Oh great, now there is poison on slashdot:
> >
> > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
> >
> > Let's not fork, shall we?
>
> Out of pure curiosity, does anyone know if this "Elektroschock" guy
> has a real name?
> Personally I don't see a lot of "dissatisfaction of core developers
> with the arbitrary project governance", but I guess it's been a while
> since we had a "real" Governance thread.

[Stefan Dösinger]

Am Montag, 25. Mai 2009 15:47:30 schrieb Henri Verbeet:
> 2009/5/25 Remco :
> > Oh great, now there is poison on slashdot:
> >
> > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
> >
> > Let's not fork, shall we?
>
> Out of pure curiosity, does anyone know if this "Elektroschock" guy
> has a real name?

He posted similar slashdot stories in the past:
http://developers.slashdot.org/developers/07/10/08/0344231.shtml
> Personally I don't see a lot of "dissatisfaction of core developers
> with the arbitrary project governance", but I guess it's been a while
> since we had a "real" Governance thread.

I guess we had one on Sept. 27 or 28 2008. I guess the next one is not yet 
scheduled, but will be somewhen in the fall I guess.

On that subject, I think Dan Kegel's patchwatcher was a really, really good 
idea, and we should revive it. Not only to catch simple problems, but also to 
broaden the set of platforms patches are pre-tested before they are 
applied(/me thinks about different graphics drivers)

[Zachary Goldberg]

On Mon, May 25, 2009 at 1:24 PM, Stefan Dösinger  wrote:
> Am Montag, 25. Mai 2009 15:47:30 schrieb Henri Verbeet:
> > 2009/5/25 Remco :
> > > Oh great, now there is poison on slashdot:
> > >
> > > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
> > >
> > > Let's not fork, shall we?
> >
> > Out of pure curiosity, does anyone know if this "Elektroschock" guy
> > has a real name?
>
> He posted similar slashdot stories in the past:
> http://developers.slashdot.org/developers/07/10/08/0344231.shtml
> > Personally I don't see a lot of "dissatisfaction of core developers
> > with the arbitrary project governance", but I guess it's been a while
> > since we had a "real" Governance thread.
>
> I guess we had one on Sept. 27 or 28 2008. I guess the next one is not yet
> scheduled, but will be somewhen in the fall I guess.
>
> On that subject, I think Dan Kegel's patchwatcher was a really, really good
> idea, and we should revive it. Not only to catch simple problems, but also to
> broaden the set of platforms patches are pre-tested before they are
> applied(/me thinks about different graphics drivers)

Patchwatcher is coming back.  Look for something from me in the next
couple weeks either on wine-devel or in WWN.

[Francois Gouget]

On Mon, 25 May 2009, Stefan Dösinger wrote:
[...]
> On that subject, I think Dan Kegel's patchwatcher was a really, really good 
> idea, and we should revive it. Not only to catch simple problems, but also to 
> broaden the set of platforms patches are pre-tested before they are 
> applied(/me thinks about different graphics drivers)

Agreed. I think it's one of the projects that has the most potential for 
helping Wine move faster. As usual it's probably best to start small 
even if it does not do all we would like at first. Then once the basics 
are in place, well tested and stable we can broaden the scope and think 
about the wilder reaches (testing on multiple platforms: FreeBSD and 
Solaris, automatic conformance test runs on multiple Windows versions, 
etc).

But the first and most important step is to get things in place.

[Tom Wickline]

On Mon, May 25, 2009 at 9:47 AM, Henri Verbeet  wrote:
> 2009/5/25 Remco :
> > Oh great, now there is poison on slashdot:
> >
> > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
> >
> > Let's not fork, shall we?
>
> Out of pure curiosity, does anyone know if this "Elektroschock" guy
> has a real name?

Not sure, but I see the second time around was a success for him..

First attempt on the subject :
http://slashdot.org/firehose.pl?op=view&id=4193755

Tom

[Jeremy White]

> Not sure, but I see the second time around was a success for him..
>
> First attempt on the subject : 
> http://slashdot.org/firehose.pl?op=view&id=4193755
> http://slashdot.org/firehose.pl?op=view&id=4193755

Ah.  I see; he apparently believes that CrossOver has a DIB Engine
and we've been holding out all these years.  That's why he decided we were evil.

/me goes to review Huw's commits to find the one where he snuck
a DIB Engine into CrossOver without my knowing it <grin>.

Cheers,

Jeremy

[Nicklas Börjesson]

> Not sure, but I see the second time around was a success for him.

Let's not look to hard. 
He (or her) does have the right to having an opinion and going out of one's way finding out and posting here would only appear vindictive and fuel interest.

//Nicklas

[King InuYasha]

2009/5/25 Nicklas Börjesson
> > Not sure, but I see the second time around was a success for him.
>
> Let's not look to hard.
> He (or her) does have the right to having an opinion and going out of one's
> way finding out and posting here would only appear vindictive and fuel
> interest.
>
> //Nicklas

I don't post on here very often, I don't even hang out in #winehq(-social)
very often either, so my opinion may not be considered too important, but by
just looking at the efforts of the Wine Project to address the DIB engine
over the years, I feel disheartened by the lack of real progress. There have
been patches regarding the DIB engine that goes all the way back to 2002
with TransGaming!

But the implementations are always stonewalled and left to die over
arbitrary architectural reasons. I say arbitrary because I don't have a clue
what the spec is for this supposed architecture that the DIB engine is
supposed to follow. Eventually, Bug #421 may just be like one of those
10-year-old bugs that live in the GNOME and Mozilla bugzillas, that are just
left there because people don't care enough anymore to do anything about it.

While it is true that the DIB engine isn't the One True Solution regarding
compatibility with many Windows applications, it helps a lot with
graphics-intensive ones. At this rate, the DIB engine will be reassigned to
the 1.4.0 milestone because nobody will accept any implementation.

And nobody say, "Patches welcome!" or "Patches accepted!" because there is
proof to the contrary. The fact people say that is also a problem. A vast
majority of people are not technically inclined to the level of being able
to produce such things. Even people that subscribe to mailing lists like I
do, are not capable of contributing like that. And really, code IS NOT the
most valuable form of contribution for any project. If anything, it is of
the LEAST value. Documentation, advice, testing, support people, moderators,
infrastructure management, all these are MUCH more valuable than code or
money. Now, this problem is not limited to the Wine Project. This problem is
all over the open source world. It bugs me a lot when I get rebuffed because
I'm not a programmer. Granted, most people that ask are whiny and demanding,
and they get on people's nerves. But, people are generally happier with an
explanation in a cordial manner. Being mean or sarcastic about it, or even
asking for something they can't give is not a good way to go about it.

But, I digress. The Wine Project is making great strides, and with the work
the ReactOS Project is doing alongside them, the work is a lot more
momentous than just a compatibility API/ABI layer for UNIX and Unix-like
systems.

[James McKenzie]

Nicklas Börjesson wrote:
> > Not sure, but I see the second time around was a success for him.
>
> Let's not look to hard. 
> He (or her) does have the right to having an opinion and going out of one's way finding out and posting here would only appear vindictive and fuel interest.

1.  I don't feel like creating a /. account just to reply.
2.  AJ has keep several bad patches from being applied to Wine since
I've been here.  Without this, we would have a project that supports a
couple of programs real well and others would be complete garbage..
3.  There should be a code style and submission guidance document. 
Something that explains coding style (four spaces vice tabs) and comment
style ('c' style vice C++/VC++/Java).  It would also be nice to have a
statement that a patch has to affect one and only one area or bug.   Oh,
fixes CANNOT break existing running programs, just to get your favorite
running, if you want them accepted.

Now with that being said, getting the DIB engine into Wine may take a
lot of shoehorning and for AJ to look over all of the code and
accept/reject it with good notes and reasons.  "You can do better" is
not, in my book, a good reason.  "Your code is not up to our standards"
is with a side comment of "look at what is accepted and what is
peer-rejected before resubmission".  Of course, AJ does take on projects
that a coder just cannot make work within the standards.  And this is a
good thing.  Sadly, Electroshock decided that he would take his toys and
go play in another sandbox.

And lastly, I think there is a site at repo.cz that has all of the
unaccepted Wine code somewhere, that we all could look at and fix.

James McKenzie

[Jerome Leclanche]

2009/5/26 James McKenzie :
> And lastly, I think there is a site at repo.cz that has all of the
> unaccepted Wine code somewhere, that we all could look at and fix.
>
> James McKenzie

All of it, definitely not. Only some of it (unless there IS one I'm
not aware of). It would be nice to have a repository of fixes that are
still in queue/have been rejected. Some patches do indeed just
disappear without any reason given, and the author never bothers to
fix what could be just a minor inconvenience in it. Seen years old
patches all of a sudden being fixed and resent in order to fix an
application that would have been running long before then.

It would probably be maintenance hell, though. Maybe patchwatcher could help?

[Daniel Devine]

On Monday 25 May 2009 23:12:57 Remco wrote:
> Oh great, now there is poison on slashdot:
>
> http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
>
> Let's not fork, shall we?
>
> Remco

I saw the article.

Anybody who thinks a fork is a good idea is quite frankly an idiot. However 
they are free to have their own GIT repo and play in their own corner.

At the end of the day anybody is able to write a patch and share it with 
whomever they like - it might even be extremely popular but that is no 
reason to spoil the main code base. Patching and compiling really is child's 
play - there is even automated scripts for Ubuntu so even your grandmother 
can do it. Stop whining and improve your code/design and try asking around 
for some help.

On the subject of the DIB engine I think that the parties involved need to 
just cool down, remember that they are on the same team and calmly and 
rationally work out the (full!) requirements.

I am not very well known to this list (but I hang in #winehq and -social quite 
a bit) so I'm not sure if I am right to submit my thoughts. Take whatever I 
have said wrong with a grain of salt. I love the Wine project and I hope to 
become a productive contributor eventually.

Also take Slashdot with pinch... I mean BAG of salt.

[Chris Howe]

2009/5/25 Remco
> Oh great, now there is poison on slashdot:
>
> http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
>
> Let's not fork, shall we?
>
> Remco
>
> Well, this is awkward.

For the record: I didn't intend to ambush anyone on here
with my frustrations, and I certainly wouldn't have chosen to
publicise them via Slashdot. Such is the nature of public
discourse, eh.

I don't think forking's the answer (and I'm certainly not putting
myself forward for that!) That said, there's only so long that
the issues of a proper DIB engine can go unadressed, and
I mean, it hasn't been addressed for some time, despite
the efforts of several people, latterly Massimo, to provide
at least proof of concept solutions. All that's really been
agreed upon is that what's there now can't be tweaked over
time to become the "right solution", but at the same time,
it can't be replaced wholesale as that might cause regression.
This would seem to be a logical impasse, and that's why
it needs a decision made, I think.

No one developer is going to be able to come out and write
the roadmap for it, because it needs broad input from a
lot of people, not just Alexandre. But certainly, as a starting
point, if it's so trivial to reject something on the grounds that
the architecture is WRONG it suggests that there is a
solution out there that's RIGHT, it just needs to be documented.

My intention was not to whine, (except that it's heartbreaking
to see good code go to waste over and over again) nor was it
my aim to throw stones, but to try and stimulate the required
discussion. If this list isn't the place for that,
then perhaps a section of the Wiki? Even just a timetable
for when it might be discussed? (As in, by release x.x.x, the
roadmap needs to have been agreed upon).

--
Chris

[Ben Klein]

2009/5/25 Remco :
> Oh great, now there is poison on slashdot:
>
> http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
>
> Let's not fork, shall we?
> From this post:

"The latest attempt of Massimo Del Fedel satisfied all requirements
set previously for the long standing bug 421, and his optional engine
seems to work fine by all Wine quality standards."

The issue is that it doesn't match Wine's quality standards (for architecture).

This Elektroschock guy is hilarious. What post did he use to
demonstrate "the dissatisfaction of core developers with the arbitrary
project governance"?
http://www.winehq.org/pipermail/wine-devel/2009-May/075844.html
Chris responding to Max responding to me. Who here is the "core
developer"? Chris doesn't appear in the WhosWho page on the wiki, nor
can I find his name in git log --author. That only leaves Max, who's
best work continues to remain floating on bug page #421 without being
committed.

For what it's worth, I agree with Chris. Someone needs to document how
the DIB engine architecture *should* work, and then Massimo and
<insert next guy to pick up DIB engine should Max lose interest> will
know how to proceed. I believe we're closer than we've ever been to
having a fully-working DIB engine, and I'd love to see real effort
made towards getting it upstream.