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
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
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.
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
19 matches
Mail list logo
