appdb developers please read
Troy Rollo
wine at troy.rollo.name
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
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).
More information about the wine-devel
mailing list