Suggestions for improvement of the emulator

[Troy Rollo]

The only reason I had not made some of these comments earlier was that I knew 
that they would not be well received, and that there would be at least some 
unconstructive responses. A prerequisite for having a productive discussion 
of this kind is being able to recognise the possible validity of alternative 
points of view, and to be aware of and have the maturity to accept the 
reality that nobody is infallible and in any particular instance it may be 
you who is wrong, and to react appropriately when it turns out you were 
wrong. There are some people here who can do that, and others who cannot. 
Unfortunately the ones who are not are usually the loudest and tend to 
destroy any value in the discussion.

I always find it particularly amusing when people try to tell me what a 
commercial organisation in a particular situation would do when I'm a person 
who makes the particular type of decision concerned in a commercial 
organisation.

I do not intend to fully respond to the replies. I did not expect the 
discussion to go anywhere productive (and still don't).  I only made my 
detailed comments because I was asked directly based on a deliberately vague 
comment that I thought would not be controversial. I am at least not 
surprised by the complete lack of any attempt to be constructive on the part 
of one participant (who, for avoidance of doubt, is not one of the people 
quoted below).

Nevertheless, two new points have been raised that merit some type of comment.

On Tue, 6 Sep 2005 21:58, Robert Lunnon wrote:
> by my customers. These days I submit my patches to comply with the LGPL,
> and if they go in all well and good, if not I no longer care... Is this how

This is not necessary to comply with the LGPL, not is it even a possible 
element in ensuring compliance.

On Tue, 6 Sep 2005 23:26, Francois Gouget wrote:
> The way forward is to dig up the patches that were rejected, post them
> to wine-devel with the reason that was given for their rejection
> (because you asked why they were rejected, right?), and ask for
> suggestions on how to make them more acceptable.

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). 
This is not to criticise Alexandre, but to point out that systems need to be 
put in place to help him manage these things. Just taking patches of the 
mailing list is not a sufficient mechanism. 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.

The present system leads to inevitable delays since the submitter has to wait 
a while until it seems likely that the patch is not going to go in, then ask 
why - if submitters received immediate feedback once there is a decision, 
they could turn around a new version of the patch much more quickly (and an 
ideal system would link the new submission to the original to put it in more 
complete context). Then others who may be depending on the patch can get on 
with their work too.

It ought to help Alexandre too since it would mean he wouldn't have to try to 
remember a week later why he rejected a particular patch, or re-examine the 
patch to figure out what he was thinking.

It may be that Bugzilla could be coaxed into this role, although I suspect 
it's not particularly well adapted to this core task without some 
customisation.