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 syste
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
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 gett
> 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
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
c
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:
http://www.winehq.org/pipermail/wine-devel/2006-September/05105
> 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
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 dev
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 elimin
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
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 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
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 prov
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 se
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 s
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 this
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
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 describ
> 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
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 do
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 p
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 dif
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
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 chair
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 it
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
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
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 for
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 b
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
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 f
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, and
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
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 doe
>>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 t
35 matches
Mail list logo
