A new method of storing package data base information, proposing packages, and announcing updates
Mon May 3 22:06:00 GMT 2004
On 2004-03-27T00:26-0500, Daniel Reed wrote:
) To propose a new package, one would simply send the proposed initial
) contents of the package's .hint file to the cygwin-apps mailing list. An
) I have not decided on an optimal machine-readable format for announcing
) updates. If the hint URL (#!hint) has not changed, all that is needed for
) automation purposes is the new CURR and possibly a new PREV. It may be
) easiest in practice to allow package updates to be announced by again
) posting the .hint file in the above format.
) I think this is a good proposal, but I am open to any suggestions.
) Maintaining the PPL and assorted support files has become very time-
) consuming lately; I am hopeful this new method will allow us to redistribute
) some of the coordination load and help streamline Cygwin maintenance.
This latter situation has not changed, so I have been working on the former
proposals during my free time.
I have a template web site showing information for a fictitious foomaster
program, partway through its ITP->acceptance phase, available at
This is what I would like to implement:
Creating an initial ticket:
Go to http://example.com/package-maint/, fill out form with information and
email address. ALTERNATIVELY: Send new-style setup.hint to
Initial tickets will have a status of UNCONFIRMED.
An email is sent to your address with the contents of the ticket (in
new-style setup.hint format). This message will have a Reply-To:
<package-maint-confirm-XXXXXX-XXXXXXXXXXXXXXXXXXXXXXX@example.com> and a
link to http://example.com/package-maint/confirm/XXXXXX-XXXXXXXXXXXXXXXXXXXXXXX
If you send an email to that address or visit that web address in a web
browser, the ticket will be moved to NEW and notification will either go to
cygwin-apps or to some Cygwin-maintainer-only address.
A Cygwin maintainer will review the ticket and move it to PENDING before it
will appear in the data base (PPL and elsewhere).
Ticket states can be UNCONFIRMED, NEW, PENDING, ACCEPTED.
Updating an existing ticket via the web:
Go to http://example.com/package-maint/ and search by package name or go to
http://example.com/package-maint/view/PACKAGENAME . Modify fields, filling
in your email address (which will be saved as a cookie), then Commit.
Updating an existing ticket via email:
Send a new-style setup.hint to <email@example.com>. This must have
an "@ packagename" line, but otherwise only needs entries that have changed.
(Usually this will just be curr: and prev:, unless the listed URLs were not
templated or changed locations, in which case #!hint, #!bin, etc. may need
to be supplied as well.)
A confirmation message will be emailed to you as with an initial ticket. The
confirmation message will contain a diff of the changes rather than the
Once you have replied to package-maint-confirm-XX... or gone to the web URL,
the change will be applied immediately. If the VERSION and/or RELEASE
changed, a message will be sent to cygwin-apps announcing the availability.
For all changes, a message will be sent to you (in addition to the initial
confirm), the package coordinator, and perhaps anyone on a package-specific
For the web page, things like "Categories" and "Veto" need to be hyperlinks
to pages that describe what they are, when you should (or are allowed to)
use them, etc.
If anyone wants to suggest purely-cosmetic changes to the HTML, feel free to
mail me directly.
Anyway, is this crackrock? Good stuff? Suggest any tweaks?
Daniel Reed <firstname.lastname@example.org> http://people.redhat.com/djr/ http://naim.n.ml.org/
It is not the strongest of the species that survives, nor the most
intelligent, but the one most responsive to change. -- Charles Darwin
More information about the Cygwin-apps