> "em·u·late: Computer Science, Software: Imitation of the function of
> (another system), by dynamic recompilation or interpretive translation as
> to allow the imitating system to accept the same data, execute the same
> binary programs, and achieve the same results as the imitated system."
I li
Mike Hearn wrote:
From a dictionary:
"em·u·late: Computer Science. To imitate the function of (another
system), as by modifications to hardware or software that allow the
imitating system to accept the same data, execute the same programs, and
achieve the same results as the imitated system."
On 9/9/05, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> The better word is "clone" if you don't like a wordy "independent
> implementation".
Heh, no that would be ReactOS. I always like the term "compatibility
layer" when speaking of Wine.
Thanks
Steven
"Mike Hearn" <[EMAIL PROTECTED]> wrote:
> >From a dictionary:
>
> "em·u·late: Computer Science. To imitate the function of (another
> system), as by modifications to hardware or software that allow the
> imitating system to accept the same data, execute the same programs, and
> achieve the same re
On Tue, 06 Sep 2005 21:29:22 -0700, Juan Lang wrote:
> 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.
FWIW, I share these concerns though given my non-existant patch writing
speed lately I'm not sure how much my
On Mon, 05 Sep 2005 18:21:18 -0500, Evil wrote:
> No, of course not. Now, if the gas had to be converted to a completely
> different substance before it could power the car, then it would probably
> be an emulator.
Ah, car analogies, the developers favourite tool :)
>From a dictionary:
"em·u·la
On Thursday 08 September 2005 10:11, Francois Gouget wrote:
> On Thu, 8 Sep 2005, Robert Lunnon wrote:
> [...]
>
> > The issue isn't about Alexandre, it's about a governance model that
> > revolves around the opinion of a single person and whether the difficulty
> > of having a patch moved forward
Excuse the top posting, yes, this is exactly my point.
On Thursday 08 September 2005 11:02, Troy Rollo wrote:
> On Thu, 8 Sep 2005 04:42, Jeremy White wrote:
> > But the best way to persuade me (and others) of that is to highlight
> > the patches. Show me patches you've submitted, along
> > with
Jeremy White wrote:
We actually have a todo on Jeremy Newman's list to build
a patch management system for wine-devel, for Alexandre.
Our hope was that we could adopt some of the CodeWeavers
systems (we have a ticket system that's pretty slick,
for example).
However, it became clear that the re
Robert Lunnon wrote:
takeup (progress) of wine in the market. Interestingly even codeweavers has
such patches that Jeremy White terms "Proprietary Advantage". This'd be good
for me if I was making a living off Wine like codeweavers are. In fact
perhaps I'd go out of my way to produce patches
On Thu, 8 Sep 2005 04:42, Jeremy White wrote:
> But the best way to persuade me (and others) of that is to highlight
> the patches. Show me patches you've submitted, along
> with arguments for them, and persuade me that he has
> been wrong to refuse them.
I said I wouldn't comment further, but I
On Thu, 8 Sep 2005, Robert Lunnon wrote:
[...]
The issue isn't about Alexandre, it's about a governance model that revolves
around the opinion of a single person and whether the difficulty of having a
patch moved forward is inhibiting the take up of developers.
I think this governance model can
On Tue, Sep 06, 2005 at 09:26:44AM +1000, Troy Rollo wrote:
> To scale better you would need to divide the project into different areas of
> responsibility and have multiple committers.
Well, one can say that this model already exists implicitely as most patches
to 'non-core' DLLs (DirectX in my
> takeup (progress) of wine in the market. Interestingly even codeweavers has
> such patches that Jeremy White terms "Proprietary Advantage". This'd be good
> for me if I was making a living off Wine like codeweavers are. In fact
> perhaps I'd go out of my way to produce patches that wouldn't b
Robert Lunnon wrote:
On Wednesday 07 September 2005 19:35, Alexandre Julliard wrote:
Francois Gouget <[EMAIL PROTECTED]> writes:
Yeah, maybe a very generic 'Needs review' email to wine-devel would be
enough. It would also be the clue to the other Wine developpers:
* that you're not goi
On Wednesday 07 September 2005 19:35, Alexandre Julliard wrote:
> Francois Gouget <[EMAIL PROTECTED]> writes:
> > Yeah, maybe a very generic 'Needs review' email to wine-devel would be
> > enough. It would also be the clue to the other Wine developpers:
> > * that you're not going to be duplicatin
Firstly , we are talking about a governance model here, not an individual.
Read on...
On Tuesday 06 September 2005 23:26, you wrote:
> On Tue, 6 Sep 2005, Robert Lunnon wrote:
> > On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
> >> On Tue, 6 Sep 2005, Troy Rollo wrote:
> >> [...]
> >
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Hiji <[EMAIL PROTECTED]> writes:
>
> > As a user, I've been particularly happy about how
> Wine
> > has progressed. However, what is of GRAVE concern
> to
> > me is when patches that fix serious bugs aren't
> > applied; specifically, bug 3148
On Wed, 7 Sep 2005, Alexandre Julliard wrote:
Francois Gouget <[EMAIL PROTECTED]> writes:
Yeah, maybe a very generic 'Needs review' email to wine-devel would be
enough. It would also be the clue to the other Wine developpers:
* that you're not going to be duplicating Alexandre's work if you
Francois Gouget <[EMAIL PROTECTED]> writes:
> Yeah, maybe a very generic 'Needs review' email to wine-devel would be
> enough. It would also be the clue to the other Wine developpers:
> * that you're not going to be duplicating Alexandre's work if you
>review this patch
> * to look at the p
On Wed, 7 Sep 2005, Ivan Leo Puoti wrote:
Juan Lang wrote:
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 particula
Jeremy White <[EMAIL PROTECTED]> writes:
> At the time we were discussing that, though, we didn't
> have many volunteer web programmers; maybe we should
> revisit that. Alexandre, would you be interested if
> folks other than Jer volunteered to help build such a system?
Sure, I don't really care
Hiji <[EMAIL PROTECTED]> writes:
> As a user, I've been particularly happy about how Wine
> has progressed. However, what is of GRAVE concern to
> me is when patches that fix serious bugs aren't
> applied; specifically, bug 3148. Even the patch
> submitter had to plead with this alias for someon
Troy Rollo wrote:
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.
Absolutely!
Bugz
Juan Lang wrote:
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 though
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 happen
> 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
> 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 (w
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> "Hiji" <[EMAIL PROTECTED]> wrote:
>
> > As a user, I've been particularly happy about how
> Wine
> > has progressed. However, what is of GRAVE concern
> to
> > me is when patches that fix serious bugs aren't
> > applied; specifically, bug 3148.
"Hiji" <[EMAIL PROTECTED]> wrote:
> As a user, I've been particularly happy about how Wine
> has progressed. However, what is of GRAVE concern to
> me is when patches that fix serious bugs aren't
> applied; specifically, bug 3148. Even the patch
> submitter had to plead with this alias for someo
--- Steven Edwards <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On 9/6/05, Francois Gouget <[EMAIL PROTECTED]> wrote:
> > I'll grant you that we could possibly setup a TinderBox type of system
> > but I feel that would be very overkill right now and even TinderBox can
> > only detect problems after p
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 a
Hello,
On 9/6/05, Francois Gouget <[EMAIL PROTECTED]> wrote:
> I'll grant you that we could possibly setup a TinderBox type of system
> but I feel that would be very overkill right now and even TinderBox can
> only detect problems after patches get committed.
I don't know if everyone follows wine
> [...]
> > I suspect the current model is either at or near
> its limits. It would
> > certainly not cope with a significant number of
> commercial outfits putting in
> > a serious level of contribution, nor does it
> encourage them to make the
> > attempt.
>
> I can assure you that there are man
On Tue, 6 Sep 2005, Robert Lunnon wrote:
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
On Tue, 6 Sep 2005, Troy Rollo wrote:
[...]
Having to pipe all the changes through one person limits scalability.
[...]
I must disagree, the LOTM (Lord Of The Manor) governance model may wor
Marcus Meissner wrote:
Personally I consider the WINE project fair in its patch acceptance policies.
IMHO it's also fair to call it Wine and not WINE, IIRC this was agreed on
before.
Ivan.
On Tue, Sep 06, 2005 at 09:58:03PM +1000, Robert Lunnon wrote:
...
> I must disagree, the LOTM (Lord Of The Manor) governance model may work for
> an small outfit but wine has already outgrown it. I have two or three
> withheld patches which are absolute show stoppers for running wine under
> S
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
> On Tue, 6 Sep 2005, Troy Rollo wrote:
> [...]
>
> > Having to pipe all the changes through one person limits scalability.
>
> This is far from being an issue with the current number of patches. By
> the time it becomes an issue I'm sure w
On Tue, 6 Sep 2005, Troy Rollo wrote:
[...]
Having to pipe all the changes through one person limits scalability.
This is far from being an issue with the current number of patches. By
the time it becomes an issue I'm sure we'll have switched to a
distributed repository model with different m
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> Even as things are now there is a disincentive to new developers. Some
> developers don't bother submitting patches because they feel it's too much
> work to get them accepted,
Right, if the patch is a pure hack, or of a bad quality, it won't be accepte
On Tue, 6 Sep 2005 09:59, Ivan Leo Puoti wrote:
> committed. Also I've recently noticed that very few of the patches being
> submitted are being committed, mainly because Alexandre appears to be
> *very* busy with some work (mac support maybe?),
He may well be very busy with something else, but at
Troy Rollo wrote:
The process requires that
developers risk their work amounting to nothing because it won't be accepted.
How many times have you seen people say that "Alexandre doesn't always know
what he wants, but he knows what he doesn't want"?.
That's a problem vitaly and I now have, nto
On Mon, 5 Sep 2005 20:30, Francois Gouget wrote:
> What makes you say that?
> What would need changing to efficiently accomodate more developpers?
I should preface this by saying that I don't mean any criticism or offence by
this. You asked the question and the following reflects my observation
Mike Hearn wrote:
On Mon, 05 Sep 2005 11:30:41 -0700, Hiji wrote:
Firstly, Wine is not an emulator, it it a binary loader and an
implementation of the Win32 API.
Bingo. It irritates me when people call Wine an emulator. ALEX, did you
know that Wine stands for "Wine Is Not an Emulat
On Mon, 05 Sep 2005 11:30:41 -0700, Hiji wrote:
>> Firstly, Wine is not an emulator, it it a binary loader and an
>> implementation of the Win32 API.
>
> Bingo. It irritates me when people call Wine an emulator. ALEX, did you
> know that Wine stands for "Wine Is Not an Emulator"??
It's playing
> What makes you say that?
> What would need changing to efficiently accomodate more developpers?
>
> I'm asking because I don't see a problem with the current organisation
> but I may be missing something. If there are issues it's best to get
> them out in the open so we can work on fixing them.
> Firstly, Wine is not an emulator, it it a binary
> loader and an
> implementation of the Win32 API.
Bingo. It irritates me when people call Wine an
emulator. ALEX, did you know that Wine stands for
"Wine Is Not an Emulator"??
Hiji
__
Do You Ya
On Mon, 5 Sep 2005, Troy Rollo wrote:
[...]
Secondly, even if there were sufficient manpower, the way the Wine project is
currently structured would prevent the manpower from being used efficiently.
What makes you say that?
What would need changing to efficiently accomodate more developpers?
Alex Tanner wrote:
I can't understand why the members of the Wine project
are always complaining about lack of manpower.
The lack of manpower is probably due to there being
different flavours of Wine developed by different
companies.
[...]
I think you overestimate the real number of Wine forks
On Mon, 5 Sep 2005 06:24, Alex Tanner wrote:
> If all the companies worked together on a
> single WinXP-Pro-emulating flavour of Wine, the
> manpower problem would be solved.
Not really. Firstly there is not (yet) enough commercial interest in
contributing to Wine development to provide the manpo
Hi Alex,
Firstly, Wine is not an emulator, it it a binary loader and an
implementation of the Win32 API.
Alex Tanner wrote:
companies. If all the companies worked together on a
single WinXP-Pro-emulating flavour of Wine, the
manpower problem would be solved.
Different companies have differ
I can't understand why the members of the Wine project
are always complaining about lack of manpower.
The lack of manpower is probably due to there being
different flavours of Wine developed by different
companies. If all the companies worked together on a
single WinXP-Pro-emulating flavour of Wine
52 matches
Mail list logo
