appdb developers please read

Troy Rollo wine at
Thu Sep 8 18:57:07 CDT 2005

On Thu, 8 Sep 2005 23:06, Francois Gouget wrote:
> If it's something Alexandre uses to apply patches, then his requirement
> that it be usable from his desktop environement (Emacs) precludes a
> web-based system.

Not really. A web based system could provide an alternative interface that 
allows for other front-ends (an XML interface for buzzword compliance). This 
would facilitate a split in development to that you don't need somebody who 
knows both PHP and elisp to develop it - get one who knows PHP and one who 
knows elisp. It would also lay the groundwork for having a variety of 
front-ends. More importantly, it would provide an opportunity for integration 
with bugzilla, and submission of patches via a web interface is likely to 
result in better consistency, specifically dealing with the following 

1. Submit the patch as a file  through the web and you get the same result 
every time, submit it through email and everybody's mail client might do 
something slightly different and wrong, multiplied by configuration 
differences and PEBCAKs);
2. A web submission system could insist on a ChangeLog and possibly some 
additional explanatory text (why the change is needed, why it was done a 
particular way);
3. A web submission system could effectively provide for other niceties such 
as recording patch dependencies and when a newer patch supercedes an older 

You would have four phases:

1. Define the functionality required;
2. Implement functionality with web-based interface (probably in PHP since 
that's what's used for the appdb and so what the appdb coders are familiar 
3. Implement an XML option for the functions that make sense inside an IDE 
(and I suppose you could call emacs the original IDE); and
4. Implement the emacs frontend for that interface.

At the moment we're really only at (1) though.

The broad basic requirements are:
1. Can receive patches via the web and/or wine-patches;
2. Provides an interface allowing for application of patches and changing the 
state of the patch, and whatever else Alexandre does;
3. Provides notification to the patch submitter whenever the state changes.

Other niceties would include:

4. Gateways web submissions back to wine-patches;
5. Tracks discussion of a particular patch;
6. Ability to assign a patch to somebody else to review;
7. Ability to determine who has primary responsibility for a patch based on 
the files modified by the patch (so that if there are different committers 
for particular areas, then only the appropriate one needs to deal with the 

More information about the wine-devel mailing list