Changes between Version 2 and Version 3 of PortLoggingProposal

Timestamp:

Oct 5, 2007, 4:19:06 AM (17 years ago)

Author:

jmpp@…

Comment:

--

PortLoggingProposal

@@ -5 +5 @@
 The log format itself could be a versioned work in progress we would refine as we work toward polishing the logging feature, governing it by a public specification that defines what metadata we output to the log and how; said specification itself would be governed by us in turn (MacPorts). On the other hand, eligible file formats for the log could be: one record per line plain text with pound sign delimted comments (the logging specification version being one of them); html, with tags delimiting each of the insallation stages; xml, a schema or dtd version defining the logging specification; yaml or others. Well placed code abstractions could buy us some flexibility in separating our own log format specification (what we output and how) from the file level format we choose (plain text, html, xml, etc), and in switching from one to the other should the need ever arise. Two crucial factors in deciding what file level format we end up choosing, however, are the amount of metadata we decide to output to the log (e.g. MacPorts release, host platform, compiler version, requested port, requested action, built with root permissions? etc.) and the flexibility of the chosen file format to append data to an already open file.
 
-A second part of the proposal would comprise the design of a web based form, written in widely adopted and web oriented scripting language like PHP or Ruby on Rails, that would accept a submitted log and process it in specific ways to provide in a clear and concise fashion as much information as possible about a particular build run to reviewers, openly disclosing all success and error status and, in case of the latter, their reported causes thereof. Said form would probably have to be hosted on some central and official location endorsed by MacPorts (the Wiki being an option), so as to provide the general user base with authoritative information on the state of our ports tree at any given time, thus superseding the functionality provided by the now defunct ports.php page (not just information on available ports but also on their build status). A protocol governing who is allowed to submit logs to this central location would need to be developed, thus reducing the likelyhood of hosting and dispatching potentially fraudulent information. Regular users could still host their own logs and use them, for example, to communicate with maintainers and provide higher quality feedback. A command line level 'submit' action-flag of the new 'log' action would take care of submitting the log to the passed value, e.g. 'port log --submit maintainer <port>' or 'port log --submit <central-location> <port>', where the 'maintainer' value would expand to the maintainer of <port> and only authorized maintainers (probably holding a private digital signature) would be allowed to submit to the URL of the central location.
+A second part of the proposal would comprise the design of a web based form, written in widely adopted and web oriented scripting language like PHP or Ruby on Rails, that would accept a submitted log and process it in specific ways to provide in a clear and concise fashion as much information as possible about a particular build run to reviewers, openly disclosing all success and error status and, in case of the latter, their reported causes thereof. Said form would probably have to be hosted on some central and official location endorsed by MacPorts, so as to provide the general user base with authoritative information on the state of our ports tree at any given time. A protocol governing who is allowed to submit logs to this central location would need to be developed, thus reducing the likelyhood of hosting and dispatching potentially fraudulent information. Regular users could still host their own logs and use them, for example, to communicate with maintainers and provide higher quality feedback. A command line level 'submit' action-flag of the new 'log' action would take care of submitting the log to the passed value, e.g. 'port log --submit maintainer <port>' or 'port log --submit <central-location> <port>', where the 'maintainer' value would expand to the maintainer of <port> and only authorized maintainers (probably holding a private digital signature) would be allowed to submit to the URL of the central location.
 
 In its completed form, this proposal would pave part of the way to construct the software infrastructure that's needed to implement in a reliable fashion the massive build runs that are necessary to finally achieve the ultimate goal of distributing binary packages, since proper error reporting and handling is crucial in case something goes wrong while building in automated form a single port out of many of a large tree.