Suggestions for improvement of the emulator

[Juan Lang]

> This of course points to another problem with the existing system -
> if a patch has been rejected, it should be a necessary consequence
> that the submitter is informed with reasons - they shouldn't have to
> be chasing up Alexandre to find out if the patch was rejected or
> merely missed (which happens often). 
(snip)
> What is needed is a system that records all patches, together with
> their current status (NEW, APPLIED, REJECTED (with reasons), and
> whatever other status), informs the submitter of any change, and does
> not allow for a patch merely to be forgotten.

What this misses is the most common status that causes us all to argue:
uncomitted, because Alexandre's not sure about it.  Perhaps he has a gut
feeling that the approach is not right, but hasn't taken the time to
identify any particular flaw.  Perhaps it merits additional thought. 
Perhaps it's too big to review quickly.  Perhaps he hopes the submitter
will realize it's not up to snuff, and resubmit a better patch.  There are
probably other reasons, but these all come to mind from my own experience.
 And no system can appropriately capture that, when the answer is not as
clearly defined as one of the above states.

This is frustrating, and some people do seem to be put off by it.  I have
no idea how many potential contributors we lose this way.  On the other
hand, this is Alexandre's style, and we've all had to get used to it.  Any
alternative that involves Alexandre doing more work will get summarily
rejected--he does a great deal as it is, more I think than any one of us
would be willing to do (or perhaps could do).

The only credible alternative is a multi-maintainer system.  This could
allow faster development of some larger features, or more invasive ones,
or more exploratory ones.  The problem I see with this is one of quality:

We have a large code churn rate, and, corresponding with that, a high bug
churn rate.  That makes regression testing and choosing an appropriate
wine version both very difficult.  Having multiple maintainers multiplies
the number of possible configurations.  Yes, I know we could have official
releases and the like, but who of us would resist trying out some
as-yet-unmerged DX9 patch from Oliver, or experimenting with safedisc?

Continuing in that vein, we're all lazy about merging in large patch sets.
  I'm merging in a fairly large set of changes at the moment, and the
slower pace has allowed me to catch issues that may not have surfaced
otherwise.  Having several competing trees with substantial differences
would, in my opinion, reduce the overall quality of the project.

So I see a tradeoff between development speed and quality.  We may be
perceived as having issues with speed, but I think we do pretty well with
our small stable of developers.  We do have issues with quality, IMHO, so
I'd be reluctant to endorse any radical changes.

What does seem to work is picking up for Alexandre by reviewing patches on
wine-devel, and helping newcomers along.  We seem to have picked up a few
lately that don't mind the public thrashing :)  There does seem to be some
more collaborative development going on lately, too.  Perhaps we should be
more vocal about how we do business, what kind of feedback to expect, and
how to get help?

--Juan


	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/