Ge van Geldorp wrote:
Actually, that's not how I intended things to work. The automatic removal
from the queue would only happen if the patch had a RFC status, i.e. if
action is expected from the patch submitter. If the patch is unopposed and
just waiting in the queue, it should stay there.
It's
Mike McCormack wrote:
Ge van Geldorp wrote:
My objective is to improve Wine by maximizing the number of patches of
acceptable quality. In my opinion, this can be done by:
1) assuring no patches get lost
2) assuring an author gets informed about why his patch is not
acceptable in
its current
From: Vitaliy Margolen [EMAIL PROTECTED]
So in a sense you will require some one to respond for any
incoming e-mail to wine-patches. And if no one does,
Alexandre don't get to see the status?
Not sure I understand what you mean. If no-one responds to the patch on
wine-devel the patch
Ge van Geldorp ge at gse.nl writes:
From: Vitaliy Margolen wine-devel at kievinfo.com
So in a sense you will require some one to respond for any
incoming e-mail to wine-patches. And if no one does,
Alexandre don't get to see the status?
Not sure I understand what you mean. If
On Thursday 28 September 2006 05:49, Mike McCormack wrote:
Seems like that is a system that doesn't scale well at all, as it
requires Alexandre to specifically respond to each and every patch.
He still has to take an action to review each patch now, and presumably some
action to remove it
Ge van Geldorp wrote:
My objective is to improve Wine by maximizing the number of patches of
acceptable quality. In my opinion, this can be done by:
1) assuring no patches get lost
2) assuring an author gets informed about why his patch is not acceptable in
its current form so he can improve
Hello Mike,
From: Mike McCormack [mailto:[EMAIL PROTECTED]
That sounds good, but it's not reasonable to put the
responsibility on Alexandre, as he has enough work already.
Unless you can read Alexandres mind, he's really the only one who can tell
what he didn't like about a certain
From: Jakob Eriksson [mailto:[EMAIL PROTECTED]
I have been watching this thread with keen interest.
Alexandre does not HAVE to respond to that patch, he can
silently ignore it just like he can now.
The only difference with Patchwork would be that after a
certain time with no
On Tuesday 26 September 2006 22:09, Alexandre Julliard wrote:
Robert Lunnon [EMAIL PROTECTED] writes:
Well thats at least a reasoned response, even if I don't agree with the
reasoning. But again you simply miss the point. I don't care that
Alexandre doesn't move my patches (because its not
From: Alexandre Julliard [EMAIL PROTECTED]
If you expect
anything to happen, you'll need to make much more concrete
suggestions, and provide examples to make us understand how
what you are suggesting would work in practice
Fair enough. Some disclaimers upfront: I'm basically thinking
Ge van Geldorp wrote:
It would make sure the author always receives some kind of feedback (either
from the bot, other developers or yourself) and would make sure patches
don't get lost (patches are automatically entered into the system and only
leave the system when the author withdraws them
On 9/27/06, Mike McCormack [EMAIL PROTECTED] wrote:
Responding to each and every patch seems like it would be a waste of
Alexandre's time. We should encourage more people to participate in the
patch review process, so that we have more reviewers and a more scalable
process.
+1
--
James
From: Mike McCormack [mailto:[EMAIL PROTECTED]
Seems like that is a system that doesn't scale well at all,
as it requires Alexandre to specifically respond to each and
every patch.
No, it doesn't require that. It requires *someone* to respond, that could be
a fellow developer on
On Thursday 28 September 2006 05:49, Mike McCormack wrote:
Seems like that is a system that doesn't scale well at all, as it
requires Alexandre to specifically respond to each and every patch.
He still has to take an action to review each patch now, and presumably some
action to remove it
Ge van Geldorp wrote:
From: Mike McCormack [mailto:[EMAIL PROTECTED]
Seems like that is a system that doesn't scale well at all,
as it requires Alexandre to specifically respond to each and
every patch.
No, it doesn't require that. It requires *someone* to respond, that could be
a
As I speculated, the reason the PPC64 Patchwork example was so out of date was
that the PPC64 list had been folded into the vanilla PPC list, however the
big problem right now is that Patchwork is extra work for maintainers, so
right now they don't want to use it.
It ought to go without saying
Since you know better, how about maintaining your own Wine tree and
showing us how it's done?
Self evidently thats what I have to do until some core functionality patches
find their way into WineHQ wine. It's not particularly hard, but it is time
consuming to manage merge conflicts.
It's
On Tuesday 26 September 2006 19:35, Mike McCormack wrote:
Since you know better, how about maintaining your own Wine tree and
showing us how it's done?
Self evidently thats what I have to do until some core functionality
patches find their way into WineHQ wine. It's not particularly hard,
Troy Rollo wrote:
As I speculated, the reason the PPC64 Patchwork example was so out of date
was
that the PPC64 list had been folded into the vanilla PPC list, however the
big problem right now is that Patchwork is extra work for maintainers, so
right now they don't want to use it.
Ouch.
Robert Lunnon [EMAIL PROTECTED] writes:
Well thats at least a reasoned response, even if I don't agree with the
reasoning. But again you simply miss the point. I don't care that Alexandre
doesn't move my patches (because its not true that he doesn't) and since I
now have a patch
I didn't respond to Alexandre's point earlier, but wanted to now:
To the private email issues, Alexandre replied:
There are a fair number of such cases, yes. Not so much the bad
patches but the corrupted/mangled/doesn't apply patches; I don't want
to fill wine-devel with this patch is
Accepted patches will appear in the wine-cvs mailing list.
Patches with obvious problems may receive a response on wine-devel.
Some patches may not receive any response. In this case, your patch
maybe considered 'Not Obviously Correct', and you can:
* check the patch over yourself, and
On Tuesday 26 September 2006 22:55, Jeremy White wrote:
1. We can write a utility that lets us compare a winehq commit
message to a wine-patches email and see if there is a 'match'.
100% isn't required, but some nice non zero number is.
A key requirement is that
From: Steven Edwards [EMAIL PROTECTED]
Which is why we want to have the ambassadors project to help
new people in to wine. The thinking goes that if we have some
people to help hold the hands of new developers and the
developers that are defacto maintainers of a certain section
of code
On Sunday 24 September 2006 12:08, Ge van Geldorp wrote:
Like I said before, I have a lot of respect for Alexandres technical
abilities. But when I read comments in the Wineconf report about git:
Developers might not like it, but Alexandre does so it's a success (did I
mention I dislike git
Dimi Paun [EMAIL PROTECTED] wrote:
Bottom line, I don't know. At most I can say that sometimes I wish
Alexandre would be a bit more impulsive, and just let (a selected few)
things in that people want. Maybe this way we generate more excitement,
and the tiny bit of quality drop we pay with would
On Monday 25 September 2006 04:36, Robert Shearman wrote:
Robert Lunnon wrote:
2. Adapt the patch acceptance process to create a right of appeal where a
patch can be proven to be within the Patch Acceptance policy. Appeal
should be independent of and binding on Alexandre - this eliminates
On Sunday 24 September 2006 00:36, Rolf Kalbermatter wrote:
Robert Lunnon [EMAIL PROTECTED] wrote:
On community, the wine project doesn't represent a community in the sense
that Wine has an altruistic purpose to provide value to that community -
It doesn't do that because the wine developer
On Saturday 23 September 2006 16:36, Dmitry Timoshkov wrote:
Jim White [EMAIL PROTECTED] wrote:
snip
Steven cited the business at Wineconf of Alexandre never being proved
wrong on a technical matter. Another straw man. The part of
Alexandre's patch process that is the root of this
From: Kai Blin
Now, getting back to the patch submission process, you're talking about a
patch management system. How would that look like, in your opinion. We
were
discussing a couple of ideas, but in the end figured that most of those
would
slow down the submission speed of patches that
On Sunday 24 September 2006 01:06, Rolf Kalbermatter wrote:
Jim White wrote:
CodeWeavers Wine version is full of patches that Alexandre won't accept
for WineHQ. Obvious proof that the Alexandre's policy isn't the only
way to make a Wine that people value. In fact it proves that the
On Saturday 23 September 2006 16:42, Mike McCormack wrote:
The current process is crippling this project, limiting the developer
base and reducing community value. Without some healthy dissent it will
never change and get better. I am a friend of change, a true believer in
the process
On 9/25/06, Ge van Geldorp [EMAIL PROTECTED] wrote:
If there is genuine interest to make this work I could put up a few mock
webpages to get a better idea of how it would work.
See also my similar post regarding a patch system:
On Monday 25 September 2006 20:08, Ge van Geldorp wrote:
From: Steven Edwards [EMAIL PROTECTED]
Which is why we want to have the ambassadors project to help
new people in to wine. The thinking goes that if we have some
people to help hold the hands of new developers and the
developers
On Mon, 2006-09-25 at 19:47 +0900, Dmitry Timoshkov wrote:
Dimi, I thought you were aware of it, and Alexandre at least at
previous WineConf stated that he accepts dubious code in cases, when
he sees that nobody works on some component: that components were
OLE/COM, DDraw/D3D, BiDi at some
Hi
Ge van Geldorp wrote:
If there is genuine interest to make this work I could put up a few mock
webpages to get a better idea of how it would work.
maybe it is worth looking at patchwork?
---
PatchWork is a web-based patch tracking system designed to facilitate the
maybe it is worth looking at patchwork?
---
PatchWork is a web-based patch tracking system designed to facilitate the
contribution and management of contributions to an open-source project.
Patches that have been sent to a mailing list are 'caught' by the system,
and
Dimi Paun [EMAIL PROTECTED] wrote:
In fact, I must say that the most fun I had with Wine was when Alexandre
let me run with listview a few year back. He clearly committed patches
that weren't perfect, but I appreciated that because that's how I work:
I like to do several iterations, maybe redo
Troy Rollo [EMAIL PROTECTED] wrote:
If I say I've been coding since I was 14 (in those days home computers had
less than 1% penetration in Australia), in assembly language since shortly
after that and raw machine code not long after, having memorised the
instruction set, then was widely
On 9/25/06, Jeremy White [EMAIL PROTECTED] wrote:
Hmm. Now I'm worried; I've long thought this would be a Good Idea (TM),
and yet if you look at the 'live' project site (presumably the project
this was built for):
http://patchwork.ozlabs.org/linuxppc64/
It's pretty clear that it's not
On Tuesday 26 September 2006 00:16, Jeremy White wrote:
Hmm. Now I'm worried; I've long thought this would be a Good Idea (TM),
and yet if you look at the 'live' project site (presumably the project
this was built for):
http://patchwork.ozlabs.org/linuxppc64/
It's pretty clear that it's
Hi,
Dmitry Timoshkov wrote:
How many projects have you ever participated in? Every developers'
mailing list
of an open source I personally participated in *doesn't guarantee* not
only patch
acceptance, but even a reply with explanations why the patch has been
silently
dropped, and it
On Monday 25 September 2006 23:05, Robert Lunnon wrote:
On Saturday 23 September 2006 16:42, Mike McCormack wrote:
Since you know better, how about maintaining your own Wine tree and
showing us how it's done?
Self evidently thats what I have to do until some core functionality
patches find
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
I'm a Wine developer, and I don't work for codeweavers. Why should I read that?
It is your job to provide support for
James Hawkins wrote:
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
I'm a Wine developer, and I don't work for codeweavers. Why should I
read that?
You don't
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
James Hawkins wrote:
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
I'm a Wine developer, and I don't work
Wow, just like that!
James Hawkins wrote:
It is shocking to most FOSS code writers that maybe this is a real,
truly, paid for project. No! It can not be! I contribute to someones
profit? NOO~~~!.
The above is a famous quote I read from Linux Journal magazine.
I am well aware that
jimtabor [EMAIL PROTECTED] wrote:
First, he doesn't represent Codeweavers on the wine-devel mailing
list. Second, there's nothing unprofessional about his actions.
Missed my point! If his address has [EMAIL PROTECTED], than yes,
that person does represent that organization.
Then check
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
What do these two pages have to do with Wine's Governance ?
It is your job to provide support for this product, I spend
I don't have any real reason to have a say in this (as someone who
hasn't successfully made any changes to the wine tree, for which I
blame my inability to contribute anything that belongs there rather
than any problems with the current system), but I was just thinking
that Patch management
From: Kai Blin [EMAIL PROTECTED]
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second
reply to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow
down the overall
Hiji [EMAIL PROTECTED] wrote:
- Original Message
From: Mike McCormack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: wine-devel@winehq.org; Marcus Meissner [EMAIL PROTECTED]
Sent: Friday, September 22, 2006 11:42:36 PM
Subject: Re: Governance revisited
The current process
Vitaliy Margolen wrote:
The next question is how long does someone wait till resorting to
Bugzilla. Depending on the criteria it could generate a fair bit of
-several days :)
As in if some one wants to fix something, they should either provide a
test (best choice) or open bug and
Andreas Mohr wrote:
Hi,
On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote:
Dr J A Gow wrote:
How to capture these 'lost' contributions is a difficult issue. Maybe a
centralized repository for patches could be maintained separate from the
main
Wine tree and with a very
Scott Ritchie wrote:
On Sat, 2006-09-23 at 11:24 +0200, Kai Blin wrote:
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply
to wine-devel for each patch he rejects.
On WineConf, we decided against
From: Kai Blin [EMAIL PROTECTED]
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply
to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the overall
patch
On Saturday 23 September 2006 18:10, Hiji wrote:
I think Bob, Jim and co. were very diplomatic in their recommendations, and
I firmly believe that they symbolize the opinions of a much larger group of
people. I don't think they've overstepped their boundaries at all, have
complained or
Robert Lunnon [EMAIL PROTECTED] wrote:
On community, the wine project doesn't represent a community in the sense
that
Wine has an altruistic purpose to provide value to that community - It
doesn't do that because the wine developer base doesn't measure important to
Wine users and set
Jim White wrote:
CodeWeavers Wine version is full of patches that Alexandre won't accept
for WineHQ. Obvious proof that the Alexandre's policy isn't the only
way to make a Wine that people value. In fact it proves that the
WineHQ's patch process is not good enough to make Wine that people
Jim White wrote:
The whole quality and hack language is a red herring. To see that
it is selective and subjective, just look at the code, try xrender.c for
example.
The difference is that presumably the person who submitted that code
demonstrated that they understood the problem that they
Robert Lunnon wrote:
2. Adapt the patch acceptance process to create a right of appeal where a
patch can be proven to be within the Patch Acceptance policy. Appeal should
be independent of and binding on Alexandre - this eliminates one-to-one
arguments about patch acceptability while still
On Saturday 23 September 2006 11:39, Steven Edwards wrote:
As it stands right now the only reason technically
good patches have been rejected is due to concerns over reverse engineering
in another project.
I don't see the difference between rejection and I won't put this in yet
because I
On Saturday 23 September 2006 19:24, Kai Blin wrote:
On WineConf, we decided against this. That would still slow down the
overall patch submission speed. Consider you have a patch that's just fine,
but before you sent that, I sent in ten patches with C++ style comments.
Alexandre would now
On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
Everyone who complaints about problems with patch acceptance policy
seem to claim that, but my impression is that complaints are going
from technically incompetent people, who just feels that the process
can be improved, but can't
On Monday 25 September 2006 13:16, Dimi Paun wrote:
On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
Everyone who complaints about problems with patch acceptance policy
seem to claim that, but my impression is that complaints are going
from technically incompetent people, who just
-- Forwarded message --From: Steven Edwards [EMAIL PROTECTED]Date: Sep 25, 2006 1:27 AM
Subject: Re: Governance revisitedTo: Troy Rollo [EMAIL PROTECTED]On 9/25/06,
Troy Rollo [EMAIL PROTECTED] wrote:
The present system turns people off even before you've had time to learnwhether
On Monday 25 September 2006 15:27, Steven Edwards wrote:
Which is why we want to have the ambassadors project to help new people in
to wine. ... if... the developers that are defacto maintainers of
a certain section of code will respond to patches as they seem them...
the experts in that area
Steven Edwards wrote:
What you and others are asking for is the right to add broken hacks for
the sake of user experience.
...
I didn't ask for anything and I said I don't think WineHQ is even able
to change this process.
Misconstruing the words, intent, and plain meaning expressed by
The current process is crippling this project, limiting the developer base
and reducing community value. Without some healthy dissent it will never
change and get better. I am a friend of change, a true believer in the
process of continuous improvement. I believe one day, the WIne project
Jim White [EMAIL PROTECTED] wrote:
Your efforts don't add value to it either. All you trying to do, is
create another poor quality software that whole world just can't get rid of.
If you so much like to have bad quality patches, why don't you start
your own repository, and grant patch
On Sat, 2006-09-23 at 15:26 +0930, n0dalus wrote:
A good patch handling system might:
- Watch the wine-patches list, automatically adding patches and
comments (replies)
- Provide a way to categorise/tag patches
- Have a way of creating patch sets, which can be downloaded as a
single diff
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply
to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the overall
patch submission speed. Consider you have a
On Sat, 2006-09-23 at 11:24 +0200, Kai Blin wrote:
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply
to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the
- Original Message
From: Mike McCormack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: wine-devel@winehq.org; Marcus Meissner [EMAIL PROTECTED]
Sent: Friday, September 22, 2006 11:42:36 PM
Subject: Re: Governance revisited
The current process is crippling this project, limiting
On Thursday 21 September 2006 03:48, Jeremy White wrote:
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ. Whether the
wine core source has all the patches, (Which it doesn't - many, but not
all) isn't relevant, it's the process that they
On Thursday 21 September 2006 04:25, Mike McCormack wrote:
Robert Lunnon wrote:
Which you are entitled to, but my opinion happens to differ. Whether the
wine core source has all the patches, (Which it doesn't - many, but not
all) isn't relevant, it's the process that they go through that I
On Thursday 21 September 2006 07:09, Dr J A Gow wrote:
After having followed this thread for some time, I feel that there is an
aspect that is often missed in the debate.
As I see it, it would appear that Wine contributors fall into essentially
two camps. There are those who develop Wine for
Jeff Latimer wrote:
And exactly this information should probably be stated in the
wine-patches subscription welcome mail.
If for some reason the Wine patches you submit fail to get applied,
then we'd appreciate you taking the effort of submitting your current
patch
as a new item at bugzilla
Robert Lunnon wrote:
Getting feedback isn't always easy, so listen when you get it.
If you don't want to go to the effort required to get your patches into
Alexandre's tree, they're not going to get in themselves.
Mike
Rubbish,
The current process is crippling this project,
Hello Robert,I am an employee of CodeWeavers and one of the former project coordinators of the ReactOS Project though my views do not represent either the position of my employer or the ReactOS Project of which I am no longer actively affiliated.
This thread was part of the reason I wanted to
Vitaliy Margolen wrote:
Robert Lunnon wrote:
Getting feedback isn't always easy, so listen when you get it.
If you don't want to go to the effort required to get your patches into
Alexandre's tree, they're not going to get in themselves.
Mike
Rubbish,
The current process is crippling
Hi Jim,On 9/22/06, Jim White [EMAIL PROTECTED] wrote:
Steven cited the business at Wineconf of Alexandre never being provedwrong on a technical matter.Another straw man.The part ofAlexandre's patch process that is the root of this conflict between Wine
development-focused developers vs. Wine
On 9/23/06, Robert Lunnon [EMAIL PROTECTED] wrote:
1. Publish the patch acceptance policy - Make sure this is the acceptance
policy and not the patch acceptance process. The Patch acceptance policy
should be developed by community process and be subject to change (and change
control). Perhaps a
Hi,
On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote:
Dr J A Gow wrote:
How to capture these 'lost' contributions is a difficult issue. Maybe a
centralized repository for patches could be maintained separate from the
main
Wine tree and with a very loose method of
Andreas Mohr wrote:
And exactly this information should probably be stated in the wine-patches
subscription welcome mail.
If for some reason the Wine patches you submit fail to get applied,
then we'd appreciate you taking the effort of submitting your current patch
as a new item at
Andreas Mohr wrote:
Why reinvent the wheel? If such people can spend their time chasing down the
problem
and developing a fix for it, they sure can open a bug in bugzilla, describe
theproblem
and attach a patch they made. How more simple can it be?
No patches lost, no extra places to look
On Sunday 17 September 2006 21:48, Marcus Meissner wrote:
On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote:
I note the recent flamefest, where some of this list seared yet another
contributor (Roland Kaeser)
Since this particular very old, very shrivelled chestnut. is one of
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ. Whether the
wine
core source has all the patches, (Which it doesn't - many, but not all) isn't
relevant, it's the process that they go through that I believe could improve.
For the
Robert Lunnon wrote:
Which you are entitled to, but my opinion happens to differ. Whether the wine
core source has all the patches, (Which it doesn't - many, but not all) isn't
relevant, it's the process that they go through that I believe could improve.
The way to get your changes in is
Some kinda patch management system would help. I think like bugzilla.
On 9/20/06, Jeremy White [EMAIL PROTECTED] wrote:
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ. Whether the wine
core source has all the patches, (Which it doesn't -
On 9/20/06, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
Some kinda patch management system would help. I think like bugzilla.
It'd better have an emacs interface ;)
-Brian
After having followed this thread for some time, I feel that there is an aspect
that is often missed in the debate.
As I see it, it would appear that Wine contributors fall into essentially two
camps. There are those who develop Wine for Wine's sake. This category includes
the core developers,
Dr J A Gow wrote:
How to capture these 'lost' contributions is a difficult issue. Maybe a
centralized repository for patches could be maintained separate from the main
Wine tree and with a very loose method of acceptance (maybe just ensure that
it
is clearly indicated what the patch is for
On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote:
I note the recent flamefest, where some of this list seared yet another
contributor (Roland Kaeser)
Since this particular very old, very shrivelled chestnut. is one of my
personal favourites (thanks to Colin Wright for the
I note the recent flamefest, where some of this list seared yet another
contributor (Roland Kaeser)
Since this particular very old, very shrivelled chestnut. is one of my
personal favourites (thanks to Colin Wright for the chestnut thing...). I'd
like to repeat my observations about this. Feel
On Sunday 17 September 2006 00:09, you wrote:
I note the recent flamefest, where some of this list seared yet another
contributor (Roland Kaeser)
You might have noticed that none of the core contributers commented on this,
because they're all at WineConf right now. Just chill, I think there'll
96 matches
Mail list logo
