Re: Governance revisited (Wineconf report)
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 also???) and the inability of the Wine community to set up a patch management system (so patches won't disappear into the big void) because Alexandre refuses to use it if it won't work in Emacs I'm starting to wonder if people realise that the developers don't work for Alexandre. He's a great Benovelent Dictator on technical issues, but in my opinion only a Dictator on patch process management. While we're going on about personal likes and dislikes, I like git, it saved me a lot of work this summer, and the ability to branch whatever I like is cool. 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 are accepted. Our idea was to have patches be recieved by the subsytem maintainers, and Alexandre would only apply patches he got from those guys. We voted that one down. Now I would be interested in your idea for such a system. I figure that writing an emacs frontend won't be too troublesome if it's reasonably designed, so let's ignore that for now. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpOIh1Warbez.pgp Description: PGP signature
Re: Governance revisited (Wineconf report)
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 one-to-one arguments about patch acceptability while still providing good excellent control. It will also have the effect of reducing Alexandres workload. I think this process would be completely redundant, so can you give an example of the patches that would meet the Patch Acceptance policy but have been rejected by Alexandre? I could (If there were a patch acceptance policy) but it'd be pointless at this point. BTW, you already have a right to appeal - it's a message to wine-devel with a well-reasoned argument. Ah yes, but is it independent... There is a single acceptance channel, this is poor system design. Bob
Re: Governance revisited (Wineconf report)
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 base doesn't measure important to Wine users and set policy to provide that value. This means Wine isn't a particularly good Product. Wine is a developers play-thing, Crossover is a Product ! Considering that CrossOver does pay the bill for some part and the major driving force behind Wine is and has been for a long time Codeweavers, no matter if you like it or not, I feel that a Wine with a much more loose acceptance policy but without the Codeweavers support it has now would be not half as far as it is. It would contain all sorts of hacks and workarounds for specific applications but be basically an unmaintainable beast and much further from providing a proper basic infrastructure with COM/DCOM and MSI support (to name some examples) as it should be done rather than as it might just barely work for some popular applications. A project driven mostly by users most likely is focusing on providing fast fixes that make a specific application work, while Alexandre is specifically trying to make sure that there is a clean (both technically and legally) infrastructure on which one can build for years to come. And which by coincidence will deliver a very good platform to build CrossOver from. It does mean that you can't expect it to immediately deliver support for all the apps you and many others might like but on the other hand it will mean that once new MS technologies get used more widespread it is much easier if not only possible then, to add them and provide faster support for newer apps. For some part it does boil down to I want to have fun now vs I want to have a technically sound infrastructure that can stand some time. In that sense Wine as is is maybe not a product in the sense of our fast and trigger happy marketing world but it is certainly a product in the sense of engineering and even more so than CrossOver. But then you pay something for CrossOver and not for Wine so maybe that is also why Wine can't and shouldn't really be a product in the sense of marketing. And as with all OpenSource projects, those that provide the most support in terms of code submissions, testing and documentation get to say the most and I think it has been clear that most of them are quite content if not happy with the modus operandi. Of course Alexandre can be a pain sometimes but he has been always with a reason as far as I can tell. Rolf Kalbermatter You make the implicit assumption that you can't have both functionality and technical soundness. I did not suggest a free-for-all, I suggested that a managed objective be established and that Hacks that are necessary for functionality and are sufficiently limited in scope can be acceptable if they meet a need of the community. Secondly, I am starting to get rather annoyed that I am being portrayed as anti Alexandre. This is not the case, Alexandre does a pretty good job given the governance model, but the model itself has severe deficiencies and is not community focused. Bob
Re: Governance revisited (Wineconf report)
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 are accepted. Our idea was to have patches be recieved by the subsytem maintainers, and Alexandre would only apply patches he got from those guys. We voted that one down. Now I would be interested in your idea for such a system. I figure that writing an emacs frontend won't be too troublesome if it's reasonably designed, so let's ignore that for now. A patch management system isn't exactly a new idea. It came up last year, during the same type of discussion we're having now (and it will probably come up next year when we have the same discussion again). See e.g. http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and note this sentence: However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered. The users of such a patch management system would fall into 3 categories: Developers/patch submitters, subsystem maintainers and Alexandre. I can take a guess at what subsystem maintainers and Alexandre would want from such a system, but of course I can only really speak as a patch submitter. My primary requirements would be to be able to: - Submit a patch - Specify a subsystem - Keep track of its progress - Resubmit after receiving feedback - Get an overview of patches in the queue - Apply a queued patch to my working copy - Provide feedback to others - Withdraw a patch In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to: - Get an overview of patches relevant to their subsystem - Recommend a patch for inclusion In addition to all of the above, I guess Alexandre would need to be able to: - Get an overview of recommended patches - Commit a patch - Reject a patch - All from within emacs Moving on to implementation, I see a set of database tables giving a patch the following attributes: - Submitter - Short description - Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed, Rejected) - Subsystem - Patch text (multiple versions, to allow resubmits and still keep a history) - Comments Some status changes are restricted (e.g. only a subsystem maintainer would be able to recommend a patch). Everyone would be able to submit a patch, which would initially have Queued status. When feedback is provided, the feedback provider (anyone) could change the status to Waiting for developer. If a patch is in Waiting for developer status too long (say a month) it could be automatically rejected. When Waiting, the submitter could provide a new version or respond with a comment, setting the status back to Queued again. Or he could decide to Withdraw the patch. When a patch makes it into the tree it will gain the most holy of all statuses, Committed. I envision manually Rejecting a patch to be a pretty rare case, normally feedback would be provided and the Waiting status would be set. Uncommittable patches would then exit the system via the automatic clean up (in Waiting too long) or via a Withdraw. The heart of the system would be a couple of web pages. However, not everyone likes web pages and the current system with mailing lists does have its strong points too. So, there could be a two-way gateway between the web system and the mailing lists. If a patch is submitted via the web, it could be sent out via wine-patches too. If a patch comes in via wine-patches, it could be added to the database automatically (when that doesn't succeed a notification is sent to the author). Same for comments, they could be fed from the web page to wine-devel. 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. Gé van Geldorp.
Re: Governance revisited (Wineconf report)
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/051052.html n0dalus.
Re: Governance revisited (Wineconf report)
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 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 appear on a web page. Any comments posted that reference the patch are appended to the patch page too. The project's maintainer can then scan through the list of patches, marking each with a certain state, such as Accepted, Rejected or Under Review. Old patches can be sent to the archive or deleted. - http://ozlabs.org/~jk/projects/patchwork/ I have never used it myself though, so no idea if it does everything you want.
Re: Governance revisited (Wineconf report)
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 appear on a web page. Any comments posted that reference the patch are appended to the patch page too. The project's maintainer can then scan through the list of patches, marking each with a certain state, such as Accepted, Rejected or Under Review. Old patches can be sent to the archive or deleted. - http://ozlabs.org/~jk/projects/patchwork/ I have never used it myself though, so no idea if it does everything you want. 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 getting any use - it's just a mirror of the mailing list. So clearly the folks on the Linux PPC 64 project didn't feel it was worth investing much energy into. Also, it might be interesting to compare how the Linux kernel does things; presumably they are a successful model. My sense was that it was all pretty ad-hoc, and as bad, or much worse, than Wine when it came to patches going into the void. (I'm batting .500 with patches to the kernel; one took me 2 years and a personal plea to Alan Cox to get in, the other is still not in, despite the sub system maintainer agreeing that it was good [after many repeated pleas]). Has that changed? I presume that this same thread has come up over there - did a consensus ever develop? (Forgive me, but I don't follow LKML, I'm hoping someone braver than I might know). Cheers, Jeremy
Re: Governance revisited (Wineconf report)
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 getting any use - it's just a mirror of the mailing list. I think a good system would still be useful even if no developers or maintainers ended up using it. At the least, it could provide a nice interface for people to find old patches easily. Patchwork seems ok, but has no real features that the mailing list combined with a decent email client doesn't have. A system such as described by Ge and I would allow anyone who was interested to combine, group and watch patches, which gives some incentive to use it. It doesn't even need to have an emacs interface. Alexandre could continue with his current approach and the system would know whether or not a patch has been accepted by watching the wine-cvs list. n0dalus.
Re: Governance revisited (Wineconf report)
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 not getting any use - it's just a mirror of the mailing list. Are you sure about that? Scroll down and take a look at some of the rejected or changes requested ones. First you have a status for each patch. You also have a record of the discussion for each patch. On the other hand the most recent patch listed there is from March so perhaps they have stopped using it. So clearly the folks on the Linux PPC 64 project didn't feel it was worth investing much energy into. Wouldn't it be better to ask them than to speculate? (query sent) It may well be that the PPC64 project was merged into the PPC one, which is seemingly more up to date: http://patchwork.ozlabs.org/ -- Troy Rollo - [EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
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 system and Bugzilla sound like similar systems. Wine already has a bugzilla. I'd like to at least consider how close it is to meeting the requirements. - Submit a patch Can do, as long as it has a bug. - Specify a subsystem Also possible, but the subsystem is specified in the bug. - Keep track of its progress Yes, but there may actually not be any progress. - Resubmit after receiving feedback Yep. - Get an overview of patches in the queue Uhh..I guess you could do some kind of search. You'd actually see bugs that have patches, not the patches themselves. - Apply a queued patch to my working copy I don't know how this is supposed to work, even forgetting about bugzilla for a moment. - Provide feedback to others Yep. - Withdraw a patch Uh huh. Aside from the working copy thing, which I'm completely confused about, you could keep track of patch status with keywords. Not everyone would know how/want to maintain the keywords manually--you'd need either an army of gnomes to patrol the bugzilla or an automated system to attach the right keywords if you want to make things easy for patch submitters, which it appears you do. A nice checkbox on the attachment form saying something like I believe this patch is ready to be included in wine in its current form, only not as stupid, could work (the rest has to be done by people who can handle keywords damnit). The other major problem is that not every patch goes with an existing bug. Presumably, each patch IS meant to improve Wine somehow. I think it could be made more convenient to submit a but report along with the patch. Having the history of events related to the patch/issue in one place (bugzilla) rather than two (bugzilla and the patch manager, or bugzilla and the wine-patches/wine-devel mailing list archives as it is now) could be convenient. Or it could just add lots of unwanted clutter to bugzilla. I don't know. In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to: - Get an overview of patches relevant to their subsystem Bugzilla queries take care of this. - Recommend a patch for inclusion Um..I guess you could use keywords for that too.. In addition to all of the above, I guess Alexandre would need to be able to: snip - All from within emacs I don't want to think about this anymore. -- Vincent Povirk
Re: Governance revisited (Wineconf report)
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 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 have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. You must be kidding. Even in your somewhat convoluted example, it would be fine to receive just a single notification No C++ style comments and I really wouldn't care if the notification came from Alexandre or from someone else on wine-patches. The reality is that a lot of patches (I haven't kept a precise count, but I estimate about a third of my own patches) are dropped silently, without any feedback at all. I have absolutely no problem with a strict patch acceptance policy, designed to keep the Wine quality high. Alexandre is amazingly smart and when he tells me why a certain patch was rejected I'll usually agree with him and even if I don't agree, I have enough confidence in him to accept his judgement. But having your patches dropped silently is pretty annoying. The usual response from the core Wine developers is well, just resubmit. I fail to see how this helps Alexandres productivity (or my own for that matter). If patches weren't dropped silently the sequence of events would be: 1) Submit patch 2) Alexandre looks at patch 3) Alexandre writes 10-second rejection reply With the resubmit: 1) Submit patch 2) Alexandre looks at patch 3) Wait a week 4) Resubmit patch 5) Alexandre looks at patch again 6) Alexandre writes 10-second rejection reply Seems to me this incurs extra work for Alexandre (number 5). The patch processes isn't very transparant. For example, I submitted a patch on 20 June 2006 to dlls/kernel/heap.c (www.winehq.org seems to be unreachable for me at the moment so I can't give a URL to the message) to fix a problem with the heap on Win64. This patch was silently dropped. On July 21 a change very similar to what I submitted was committed but not attributed to me. Now, either the commit was not based on my patch (in which case someone else spent another 2-3 days (it was one of those problems where a chain of out-of-buffer memory writes take place and you have to work your way up the chain to find the root cause) on tracking down an already known problem for which a fix was already available) or it was based on my patch (in which case my patch shouldn't have been dropped and I should have been given credit). 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 also???) and the inability of the Wine community to set up a patch management system (so patches won't disappear into the big void) because Alexandre refuses to use it if it won't work in Emacs I'm starting to wonder if people realise that the developers don't work for Alexandre. He's a great Benovelent Dictator on technical issues, but in my opinion only a Dictator on patch process management. Ge van Geldorp.
Re: Governance revisited (Wineconf report)
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 describe the problem, and the resolution. It seems a fairly short time, especially if there is no feedback to say that it is rejected. Thre is another aspect to this, what we are saying is that some developers are able to write good code and won't need to resort to Bugzilla and other developers just won't cut it and Bugzilla is the way for them. I think the discussion on mentoring and developing the WineHQ compilant skills of developers is a more positive way forward. noise in the database with a lot of patches that would normally be This will not be noise but _correct_ use of bug database. Making good bug report is really helpful and 1/2 of the resolution. I was thinking here of the 4,000 patches we have had since March this year and how many would be added to Bugzilla. I expect that a fair few hundred or more would be in this category. accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing Of course ultimately bug submitter would be the right person to test if bug is still present in new version and act upon it. If this process is being directed at hackers who can't get patches accepted, they probably won't be on the list for long enough to test the patch as they probably will leave. the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted. They don't have to. All they need is update Wine to new version whenever it's released. You misunderstood me here, but I think the answer is that the person who make the patch to resolve a Bug report will close the Bug. Vitaliy Jeff
Re: Governance revisited (Wineconf report)
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 loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. 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. And all the information describing the problem. Everything in one place. 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 to help us track your work properly until it's fully applied. As alternative to bugzilla we have this section in the wiki. http://wiki.winehq.org/InterestingPatches This has several hac^H^H^Hpatches that I found uesfull and have used over time. I particularly like the Mouse Hack patch http://wiki.winehq.org/PatchMouseHack The thing is that if a patch is useful it will have a life of its own and I am glad that I have an easy way of getting to them when I want to try them. Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though). Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.). Yes please.. -- Tony Lambregts
Re: Governance revisited (Wineconf report)
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. 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 have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. Now, we agreed to try something different, two things actually. The first thing is the ambassador thing Steve and a couple of other people mentioned before. New contributors would be contacted by someone who would explain the way wine works to them. Secondly, we wanted to make a standard practice of what Mike's been doing for MSI patches. A developer proficient in a certain area of wine will reply to all the patches for his area, do a review and also makes sure they don't disappear into the void. Well, as long as SOMEONE writes the 10-second reply, I suppose it doesn't matter. But until we appoint the equivalent of Mike and MSI for every part of Wine, Alexandre ends up being the default person to do it. Thanks, Scott Ritchie Well, the way it works at present, nobody is obliged to write a 10 second reply and often don't. There has to be feedback to keep the process moving. I don't receive it and patches languish unapplied, delaying me considerably on tackling new work as I wait for acceptance before proceeding. Jeff Latimer
Re: Governance revisited (Wineconf report)
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 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 have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. How about emacs macros that would send Patch rejected or Patch under consideration to wine-patches or wine-devel ? This would get rid of the feeling that patches are dropping into a black hole while only costing Alexandre a fraction of a second per patch.
RE: Governance revisited (Wineconf report)
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 policy to provide that value. This means Wine isn't a particularly good Product. Wine is a developers play-thing, Crossover is a Product ! Considering that CrossOver does pay the bill for some part and the major driving force behind Wine is and has been for a long time Codeweavers, no matter if you like it or not, I feel that a Wine with a much more loose acceptance policy but without the Codeweavers support it has now would be not half as far as it is. It would contain all sorts of hacks and workarounds for specific applications but be basically an unmaintainable beast and much further from providing a proper basic infrastructure with COM/DCOM and MSI support (to name some examples) as it should be done rather than as it might just barely work for some popular applications. A project driven mostly by users most likely is focusing on providing fast fixes that make a specific application work, while Alexandre is specifically trying to make sure that there is a clean (both technically and legally) infrastructure on which one can build for years to come. And which by coincidence will deliver a very good platform to build CrossOver from. It does mean that you can't expect it to immediately deliver support for all the apps you and many others might like but on the other hand it will mean that once new MS technologies get used more widespread it is much easier if not only possible then, to add them and provide faster support for newer apps. For some part it does boil down to I want to have fun now vs I want to have a technically sound infrastructure that can stand some time. In that sense Wine as is is maybe not a product in the sense of our fast and trigger happy marketing world but it is certainly a product in the sense of engineering and even more so than CrossOver. But then you pay something for CrossOver and not for Wine so maybe that is also why Wine can't and shouldn't really be a product in the sense of marketing. And as with all OpenSource projects, those that provide the most support in terms of code submissions, testing and documentation get to say the most and I think it has been clear that most of them are quite content if not happy with the modus operandi. Of course Alexandre can be a pain sometimes but he has been always with a reason as far as I can tell. Rolf Kalbermatter
Re: Governance revisited (Wineconf report)
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 providing good excellent control. It will also have the effect of reducing Alexandres workload. I think this process would be completely redundant, so can you give an example of the patches that would meet the Patch Acceptance policy but have been rejected by Alexandre? BTW, you already have a right to appeal - it's a message to wine-devel with a well-reasoned argument. -- Rob Shearman
Re: Governance revisited (Wineconf report)
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 want to wait and see if X happens where X is something that might take I long time. This has been known to happen. In a couple of cases I (or somebody working for me) have had this response after going through extensive discussion about how a thing should be done and then doing it that way. Essentially, sometimes Alexandre has ideas about how something should be done but is unwilling to commit. Sometimes he will have a suggestion as to how something should be done and then change his mind later (reflecting the reality that nobody is right *all* of the time). The developers have the right to disagree and we do quite often. However we have mob rule with a benevolent despot and none of us really like to work any other way. If the project demographics change and the developers decide they don't like the system then, once again, we would change. The present system is self-reinforcing since people who run into significant problems will slow down on (or cease) their contributions. Things would be much better if there were a system in place that ensured every patch that didn't get in resulted in feedback. Right now it seems only a tiny fraction of patches that don't go in result in feedback. Contributors shouldn't feel like they have to go around begging for feedback every time a patch is not applied. Having a suitable system in place would also prevent the oops, missed that one, please resubmit situation. As things stand it actually involves less effort per patch to maintain a separate branch than to go through the begging-for-feedback process. Our governance is ultimately that Alexandre rules at the consent of the governed and while it can suck to be in the minority of mob rule from time to time, the mob agrees to keep Alexandre as the benevolent dictator for life. I for one hope this never changes as it seems to be the best system for making stable FOSS software. Yes, kind of. It would suck to establish a full-scale bureaucracy that might actually slow things down. On the other hand there seems to be a culture here that there is only One True Answer to every problem - in reality two people may disagree about the way a thing should be done and both be equally right. etc. As a Wine developer I do not develop for the users. I develop for my own needs and really don't care what the users have to say other than how it relates to my job. Bob and I are in somewhat different situations, given that we are developing for customers and both have customers using Winelib apps. I *was* also making some contributions for non work-related stuff but don't do that anymore, in large part because it's such a PITA to do so. I suspect there is also a significant difference between contributions extending Winelib functionality and contributions on Win32 compatibility. For Winelib functionality there is often a larger design element involved than Win32 were you are just trying to find the best way to implement the same functionality Windows has. -- Troy Rollo - [EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
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 have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. All this points to is a need to automate - sending this reply should be a one-click action. In fact this particular one (and no doubt many others) could be done by a reply-bot. Other things that could be done by a reply-bot: unacceptable patch format no patch found in message missing ChangeLog Perhaps a reply-bot should send out a copy of the guidelines the first time a new contributor submits something to wine-patches (or even to existing contributors when there have been changes to the guidelines). -- Troy Rollo - [EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
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 (eg, WoW patch set) - Show which patches still apply cleanly - Collect statistics, and be able to show which patches or patch sets are the most downloaded - Allow logged-in users with confirmed email addresses to send comments (replies) and new patches to the wine-patches list through the website - Watch wine-cvs for corresponding accepted patches, and mark the patches that have been accepted Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects. Thanks, Scott Ritchie
Re: Governance revisited (Wineconf report)
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 patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. Now, we agreed to try something different, two things actually. The first thing is the ambassador thing Steve and a couple of other people mentioned before. New contributors would be contacted by someone who would explain the way wine works to them. Secondly, we wanted to make a standard practice of what Mike's been doing for MSI patches. A developer proficient in a certain area of wine will reply to all the patches for his area, do a review and also makes sure they don't disappear into the void. This should solve most of the problems people (including myself) were having when getting started with wine development. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpXherDSo4X7.pgp Description: PGP signature
Re: Governance revisited (Wineconf report)
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 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 have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. Now, we agreed to try something different, two things actually. The first thing is the ambassador thing Steve and a couple of other people mentioned before. New contributors would be contacted by someone who would explain the way wine works to them. Secondly, we wanted to make a standard practice of what Mike's been doing for MSI patches. A developer proficient in a certain area of wine will reply to all the patches for his area, do a review and also makes sure they don't disappear into the void. Well, as long as SOMEONE writes the 10-second reply, I suppose it doesn't matter. But until we appoint the equivalent of Mike and MSI for every part of Wine, Alexandre ends up being the default person to do it. Thanks, Scott Ritchie
Re: Governance revisited (Wineconf report)
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 go through that I believe could improve. For the record, Governance is something we often spend a chunk of time on at each Wine conference. Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance. Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote. First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests. Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better. Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: I can't tell you what to change, but your patch is wrong. However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right. We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future. So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine. If you have a specific concrete suggestion for change, this would be a fine time to put it forward. But if your proposal is largely: Alexandre should accept more patches, I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue. Cheers, Jeremy I have never said anything of the sort, patches should be accepted according to a policy, and they are, but the policy is largely unstated, and (In my opinion) - wrong. What I have suggested is a changed governance model where Wine development is guided by the collective will toward a community goal and that patch acceptance policy is set by the community - including the user community. 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 policy to provide that value. This means Wine isn't a particularly good Product. Wine is a developers play-thing, Crossover is a Product ! Bob
Re: Governance revisited (Wineconf report)
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 Wine's sake. This category includes the core developers, and others who just feel strongly about a particular aspect in order to improve it and perfect it. These people have time to spend developing and perfecting their code to meet the necessary high standards for acceptance and would not see the current system of governance to be an issue. These are the very people that would attend Wineconf and discuss the issue! There is another category, however, and I suspect it is the larger of the two. Some people simply need to quickly fix an aspect of Wine in order simply to get an application working. These individuals, a category into which I fall, are driven by a very different motive. To take an example, my (very) small contribution to Wine was driven by the need to get a commercial ECAD application running, so that I could continue to use the application as a production tool on a production system in order to continue to function as an electronics engineer. In my case, I am also a software developer who believes in feeding useful fixes back to the community, so I used up some of my valuable free time and got the patch accepted. It took approximately three times longer to get the patch accepted than it did to fix the problem in the first place! I persevered, but I wonder how many other individuals who fall into this category would do the same? Another contractor driven purely by commercial pressures may have just got it working and kept the fix in their own tree. Such people do not have the free time or the inclination to go through the numerous iterations to get the patch accepted. Free time is a rare commodity these days, and most software developers will have other projects. These are not the people who would attend Wineconf and whose opinions can only be solicited through other means. How many Wine trees are there out there containing useful small fixes that see the light of day outside of the developers's box, simply because they do not have the time to struggle through the QA system. A number of these patches could be being lost to the community. 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 and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. The quality of Wine is important, and a workable QA system is very necessary. However there should be a mechanism to enable widespread dissemination of contributions that for various reasons do not merit direct inclusion in the tree at that time and for which the developer has neither the time nor the inclination to do battle with the QA system. Just my thoughts. John. Thank you Dr Gow, very insightful, but I don't think a technical solution can paper over what is actually a structural (and perhaps a behavioural) problem. Some Transparency would certainly help, but I don't think this is the whole answer. Rather than harping on about the problem, let me make a few concrete suggestions for improvement. These ideas minimally affect Alexandre's status as maintainer, but add some structure to avoid the downside of the current governance model. 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 standing wineconf agenda item here. 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 providing good excellent control. It will also have the effect of reducing Alexandres workload. 2. Have a Wine Developers - Bill of rights - particularly preserve the right to dissent and disagree. To develop freely, most importantly It must recognise, as Dr Gow has so eloquently said, that most Wine developers don't have any interest in WIne and must be treated as valuable volunteers. This has to be respected in the Bill of Rights. 3. Have a community process for properly handling process
Re: Governance revisited (Wineconf report)
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 to help us track your work properly until it's fully applied. 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 describe the problem, and the resolution. noise in the database with a lot of patches that would normally be This will not be noise but _correct_ use of bug database. Making good bug report is really helpful and 1/2 of the resolution. accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing Of course ultimately bug submitter would be the right person to test if bug is still present in new version and act upon it. the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted. They don't have to. All they need is update Wine to new version whenever it's released. Vitaliy
Re: Governance revisited (Wineconf report)
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 the governance discussion at Wineconf so please don't think your point of view and others are not considered. The question about governance has come up from time to time in regard to several issues such as design decisions, development methods and general patch submission processes. These issues collectively have made me interested in the overall topic of governance and seeing if there is a way we can streamline and or broaden the process. On 9/22/06, Robert Lunnon [EMAIL PROTECTED] wrote: 1. Publish the patch acceptance policy - Make sure this is the acceptancepolicy and not the patch acceptance process. The Patch acceptance policyshould be developed by community process and be subject to change (and change control). Perhaps a standing wineconf agenda item here.I think we all have agreed that Alexandre's rules for patch acceptance should be more broadly stated on the website or wiki, as well as have a system for first time contributors to be made aware of the rules and be mentored on how to become a good Wine contributor. It has always bothered me, the thought that someone might be submitting a patch for the first time, only to have that patch go to the void for whatever reason and be turned off to the project. For all we know that new developer might have turned out to be a very active member of the project. It is my hope that the new ambassador system we have proposed will help with this situation of getting new developers up to speed and get more new patches in to the tree quicker. In regards to making it a standing item, it already defacto is as we have had a discussion about the process in one form or another every year. I am happy to keep trying to tweak the process in the future. 2. Adapt the patch acceptance process to create a right of appeal where apatch can be proven to be within the Patch Acceptance policy. Appeal should be independent of and binding on Alexandre - this eliminates one-to-onearguments about patch acceptability while still providing good excellentcontrol.It will also have the effect of reducing Alexandres workload. I jokingly referred to the discussion as the off with his head meeting at Wineconf however we all came to the conclusion this was unneeded. It was in fact Jeremy White that proposed having some sort of democratic system to override Alexandre if we thought he was making some sort of mistake. It was at this point I asked him and every other developer in the room to name one time Julliard has been wrong on a technical issue. There are plenty of areas of disagreement on the patch submission process and even some disagreements on design decisions from time to time however even when there are disagreements on design, it has never been shown to me where the situation comes does to Julliard being wrong and someone else being right. If you can show a pattern of patches rejected that clearly should have been merged then I might agree with you and the rest of the Wine developers would also be chanting off with his head. As far as I understand the problem with your Solaris patches recently, your had quite a large number of invasive changes that were able to be corrected with some minor tweaking of compiler flags. Clearly this is a disagreement on design rather than the merits of the patches. If Alexandre were to ever develop a pattern of rejecting technically sound patches for no damn good reason I assure you we would revisit this discussion. As it stands right now the only reason technically good patches have been rejected is due to concerns over reverse engineering in another project. 2. Have a Wine Developers - Bill of rights - particularly preserve the right to dissent and disagree. To develop freely, most importantly It mustrecognise, as Dr Gow has so eloquently said,that most Wine developers don'thave any interest in WIne and must be treated as valuable volunteers. This has to be respected in the Bill of Rights.The developers have the right to disagree and we do quite often. However we have mob rule with a benevolent despot and none of us really like to work any other way. If the project demographics change and the developers decide they don't like the system then, once again, we would change. Our governance is ultimately that Alexandre rules at the consent of the governed and while it can suck to be in the minority of mob rule from time to time, the mob agrees to keep Alexandre as the benevolent dictator for life. I for one hope this never changes as it seems to be the best system for making stable FOSS software. I've been in projects that had full access to everyone to the tree and seen the types of problems that result from development anarchy. The Wine model is the best for
Re: Governance revisited (Wineconf report)
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 standing wineconf agenda item here. 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 providing good excellent control. It will also have the effect of reducing Alexandres workload. 2. Have a Wine Developers - Bill of rights - particularly preserve the right to dissent and disagree. To develop freely, most importantly It must recognise, as Dr Gow has so eloquently said, that most Wine developers don't have any interest in WIne and must be treated as valuable volunteers. This has to be respected in the Bill of Rights. 3. Have a community process for properly handling process change. 4. Have a similar wine users Bill of rights - The users of wine need a say. 5. Have a community process for handling these requests according to the BOR. Having a bureaucratic process like that would slow down the wine project more than a handful of rejected patches ever could. There may be structural problems, but bureaucracy is not the solution. As others have proposed, I think it would be good to implement a system so that rejected patches don't just get forgotten. I don't personally think that bugzilla is a good solution to the problem though -- it's very difficult to use efficiently and the interface is terrible. 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 (eg, WoW patch set) - Show which patches still apply cleanly - Collect statistics, and be able to show which patches or patch sets are the most downloaded - Allow logged-in users with confirmed email addresses to send comments (replies) and new patches to the wine-patches list through the website - Watch wine-cvs for corresponding accepted patches, and mark the patches that have been accepted If anyone is interested, I'd be happy to write a little mockup in php or something. n0dalus.
Re: Governance revisited (Wineconf report)
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 acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. 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. And all the information describing the problem. Everything in one place. 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 to help us track your work properly until it's fully applied. Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though). Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.). Andreas -- GNU/Linux. It's not the software that's free, it's you.
Re: Governance revisited (Wineconf report)
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 bugzilla to help us track your work properly until it's fully applied. Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though). Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.). This would be an excellent idea - it would simply highlight the fact that there is an alternative route to providing visibility for patches that are not accepted. I must admit I had always thought of bugzilla as a bug-reporting mechanism and I hadn't thought of using it in this manner: to open a bug specifically in order to present your own fix! John.
Re: Governance revisited (Wineconf report)
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. And all the information describing the problem. Everything in one place. 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 to help us track your work properly until it's fully applied. The next question is how long does someone wait till resorting to Bugzilla. Depending on the criteria it could generate a fair bit of noise in the database with a lot of patches that would normally be accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted. Jeff Latimer
Re: Governance revisited (Wineconf report)
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 record, Governance is something we often spend a chunk of time on at each Wine conference. Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance. Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote. First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests. Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better. Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: I can't tell you what to change, but your patch is wrong. However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right. We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future. So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine. If you have a specific concrete suggestion for change, this would be a fine time to put it forward. But if your proposal is largely: Alexandre should accept more patches, I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue. Cheers, Jeremy
Re: Governance revisited (Wineconf report)
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 - many, but not all) isn't relevant, it's the process that they go through that I believe could improve. For the record, Governance is something we often spend a chunk of time on at each Wine conference. Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance. Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote. First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests. Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better. Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: I can't tell you what to change, but your patch is wrong. However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right. We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future. So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine. If you have a specific concrete suggestion for change, this would be a fine time to put it forward. But if your proposal is largely: Alexandre should accept more patches, I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue. Cheers, Jeremy
Re: Governance revisited (Wineconf report)
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
Re: Governance revisited (Wineconf report)
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 others who just feel strongly about a particular aspect in order to improve it and perfect it. These people have time to spend developing and perfecting their code to meet the necessary high standards for acceptance and would not see the current system of governance to be an issue. These are the very people that would attend Wineconf and discuss the issue! There is another category, however, and I suspect it is the larger of the two. Some people simply need to quickly fix an aspect of Wine in order simply to get an application working. These individuals, a category into which I fall, are driven by a very different motive. To take an example, my (very) small contribution to Wine was driven by the need to get a commercial ECAD application running, so that I could continue to use the application as a production tool on a production system in order to continue to function as an electronics engineer. In my case, I am also a software developer who believes in feeding useful fixes back to the community, so I used up some of my valuable free time and got the patch accepted. It took approximately three times longer to get the patch accepted than it did to fix the problem in the first place! I persevered, but I wonder how many other individuals who fall into this category would do the same? Another contractor driven purely by commercial pressures may have just got it working and kept the fix in their own tree. Such people do not have the free time or the inclination to go through the numerous iterations to get the patch accepted. Free time is a rare commodity these days, and most software developers will have other projects. These are not the people who would attend Wineconf and whose opinions can only be solicited through other means. How many Wine trees are there out there containing useful small fixes that see the light of day outside of the developers's box, simply because they do not have the time to struggle through the QA system. A number of these patches could be being lost to the community. 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 and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. The quality of Wine is important, and a workable QA system is very necessary. However there should be a mechanism to enable widespread dissemination of contributions that for various reasons do not merit direct inclusion in the tree at that time and for which the developer has neither the time nor the inclination to do battle with the QA system. Just my thoughts. John. Vijay Kiran Kamuju wrote: 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 - many, but not all) isn't relevant, it's the process that they go through that I believe could improve. For the record, Governance is something we often spend a chunk of time on at each Wine conference. Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance. Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote. First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests. Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better. Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: I can't tell you what to change, but your patch is wrong. However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think
Re: Governance revisited (Wineconf report)
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 and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. 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. And all the information describing the problem. Everything in one place. Vitaliy
