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
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
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 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:
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
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
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
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
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
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 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
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 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
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
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
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
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
35 matches
Mail list logo
