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 problems:
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 one.
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 with); 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 patch).