"submission rules page" proposal [Was: monotone]

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Lapo Luchini on 1/5/2006 3:51 AM:
> 
> I guess the other message (with the HTML in attach) didn't get thru, so
> here it is: http://cyberx.lapo.it/~lapo/cygpackage.html

Overall, it looks good; I appreciate you doing this.  My comments, on a
text-ized version:

> Submitting a new package
>
> So you've got a package you want to submit. Follow the following
> checklist before emailing cygwin-apps@cygwin.com and you'll
> almost certainly save time.
>
>    1. Propose on cygwin-apps@cygwin.com that you are interested
>       in becoming a package maintainer for package foo. Some
>       packages cannot be distributed via cygwin's setup due to
>       vendor licence limitations. Other packages may not be
>       appropriate for cygwin. This step will save time if, for
>       some reason, we cannot accept the package.

Mention that the email subject should include [ITP], to make it obvious
this is a request for a new package.

>
>       Submission rules:
>
>           * Include a complete setup.hint file as part of your
>             proposal. Include this file in the text of your
>             message so that it can be commented on. Do not submit
>             it as an attachment.
>
>           * If the new package is a well-known program already
>             included in a major Linux distribution (e.g. debian)
>             please include the URL of the package page.
>
>           * If the package is not included in any major Linux
>             distro it must receive three positive votes from

I thought this number was five votes.  bsflite was a recent example of
this, http://cygwin.com/ml/cygwin-apps/2005-12/msg00050.html

>             other package mantainers in order to be accepted.
>
>    2. Do you have the time to maintain the package? Packages
>       without active maintainers are pulled from the
>       distribution. Generally speaking the time commitment is
>       relatively low, simply subscribe to cygwin@cygwin.com. We'd
>       prefer if you read the non-digest mode since prompt
>       response to packaging issues is a plus. When a bug in your
>       package is reported in the cygwin mailing list, address the
>       bug (if it's a cygwin-only bug) or pass back to the
>       vendor. When a solution exists, create an updated package
>       with the fix in it, and send a notification that you need
>       the package uploaded to cygwin-apps. Note that you are not
>       expected to be a helpdesk for the package - the users
>       should be pointed to the vendors lists if you've determined
>       that the bug is not a cygwin-related bug.
>
>    3. Look in the debian package list and identify the section
>       that your package is present in there - if it's available
>       via debian. If it's not, have a look and take a sensible
>       guess.
>
>    4. Create setup.hint file following the documentation on this
>       web page. Opinion on whether to mark your initial version
>       as a Test version is currently mixed. If you have doubts
>       about the stability of your initial offering you may decide
>       to mark it as Test. Then, once the package has no major bug
>       reports from users, a current package may be
>       introduced. Otherwise, it is perfectly acceptable to forgo
>       the Test designation in your first release.

You may want to move step 4 prior to step 1, since you mention submitting
the proposed setup.hint online.  Also, this would be a good place to
mention that writing
sdesc: "foo: program that does bar" is redundant for a package named foo,
and would look like "foo: foo: program that does bar" in setup.exe.

>
>    5. Place the package files in a web accessible http/ftp site
>       somewhere.

Mention that directory structure must exist.  For example, if I am
proposing foo and libfoo, my upload site should look like:
myserver.com/whatever/foo/foo-1-1.tar.bz2
myserver.com/whatever/foo/foo-1-1-src.tar.bz2
myserver.com/whatever/foo/setup.hint
myserver.com/whatever/foo/libfoo/libfoo-1-1.tar.bz2
myserver.com/whatever/foo/libfoo/setup.hint


>
>    6. Announce on cygwin-apps@cygwin.com that you have the
>       package ready for uploading. Provide the URLs to all
>       package files to your mail.
>
>    7. Each new package must in any case receive one GTG vote from
>       a package mantainer.

Explain that the GTG means that a maintainer has downloaded the package,
inspected the tarball contents, tested the applications, and rebuilt the
package from the source tarball without incident.  Also explain that by
becoming a package maintainer, you are allowed to provide the GTG reviews
for other package proposals.

>
>    8. Feel free to delete your temporary copy once the files have
>       been uploaded to sourceware.org.
>
>    9. Announce via cygwin-announce@cygwin.com that the new
>       package is available. Use a recent cygwin-announce message
>       from one of the core maintainers as a template for your
>       announcement.

Be sure the unsubscribe instructions are included at the end of the email,
since cygwin-announce does not add any.

>
>       Once sent, your message will be reviewed by one of the
>       cygwin-announce moderators and, once approved, will be
>       automatically forwarded to the cygwin mailing list with an
>       [ANNOUNCEMENT] prepended to the subject.
>
> Updating a package
>
> So you've got an updated package you want to submit. Follow the
> following checklist before emailing cygwin-apps@cygwin.com and
> you'll almost certainly save time.
>
>    1. Place the package files in a web accessible http/ftp site
>       somewhere.

Same layout rules as before - make your directory structure match what the
ultimate structure on the mirrors will be.

>
>    2. Announce on cygwin-apps@cygwin.com that you have the
>       package ready for uploading. Provide the URLs to all
>       package files to your mail. Just provide URLs for files
>       that have actually changed, i.e., it is not necessary to
>       provide a new link to a setup.hint file every time you
>       update your packages.

unless setup.hint actually changed.  Also, in the email, it is helpful if
you explicitly state which older versions to keep or delete from the mirrors.

>
>    3. Feel free to delete your temporary copy once the files have
>       been uploaded to sourceware.org.
>
>    4. Announce via cygwin-announce@cygwin.com that the new
>       package is available. Use a recent cygwin-announce message
>       from one of the core maintainers as a template for your
>       announcement.
>
>       Once sent, your message will be reviewed by one of the
>       cygwin-announce moderators and, once approved, will be
>       automatically forwarded to the cygwin mailing list with an
>       [ANNOUNCEMENT] prepended to the subject.
>
> NOTE: On any major version upgrade, you may want to mark the
> release as Test.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDvSf284KuGfSFAYARAjWyAJ9Ni66GLIDIjGi4W2f0Seb4jNZw+wCgp3Ul
p/QSJVGpRuyRaZPVPutPgkk=
=UPQx
-----END PGP SIGNATURE-----