This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: "submission rules page" proposal [Was: monotone]
On Thu, Jan 05, 2006 at 07:06:48AM -0700, Eric Blake wrote:
>-----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.
Ditto!
I agree with all of Eric's points but I have a couple more to add.
(Thanks for text-izing this, Eric)
>> 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.
Please mention Fedora and SuSE here, too.
>> * 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
Yep. We increased the votes when we allowed packages that were already
in other distributions to slide in.
>> 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.
Yes! Also, please reiterate that the "@ foo" notation should not be
used.
>> 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
Again, big yes! That makes life easier for package uploaders.
>> 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.
Unless this was described earlier, you should explain what GTG (and ITP for
that matter) means.
>> 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.
Maybe we should just include a template of a valid cygwin-announce email
on this web page.
>> 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.
Please mention that there is no reason to editorialize about the reason
for the upload. We trust you as the package maintainer (unlike cygwin bug
reporters where we need at least 42 people to report a bug before we will
even consider it a bug). All that we need in this email is the raw
details needed for uploading the packages to sourceware.org. Again, maybe
a template email message would help.
>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.
I've been meaning to mention this. The disk space limitations on the new
sourceware are pretty much nonexistent now - at least for a year or so.
I don't think there's any harm in keeping old versions around now unless
people think this is a bad idea in general.
>> 3. Feel free to delete your temporary copy once the files have
>> been uploaded to sourceware.org.
Please mention that someone with login privileges on sourceware.org will send
an "Uploaded" response eventually.
>> 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.
Please mention that the cygwin-announce message should not be sent until the
software has been uploaded but it should be sent as soon as possible after
the uploaded message has been sent to cygwin-apps.
Thanks again for doing this.
cgf