10 Do's and Don'ts of successful collaboration at http://fedora.us * Don't never return to an open package request of yours when somebody has reviewed it and has given you feedback. Do reply in time to comments added to your tickets. Give a brief status update in case vacation or a major lack of time prevent you from developing a package further. Don't keep tickets open when after weeks of inactivity you seem to have lost interest in a package and your download URLs give 404 Not Found. Close the tickets as WONTFIX or remove the QA keyword, at least. Notify release managers when your existing packages in the repository are unmaintained. * Don't add a comment to somebody's ticket if you don't seem to return in order to reply to the feedback you get. Do add your e-mail address to the CC list in the top right corner of a ticket in order to receive additional comments by e-mail. In particular, make sure you don't miss any additional comments until the package is published -- it might be that it fails in the build-system or is blocked by somebody else. You can remove yourself from the CC list again later, too. * Do show that you've read the documentation in the Wiki and e.g. avoid common packaging pitfalls. * Do read your own build logs (in particular the 'configure' output) and comment on missing features and any warnings before a reviewer notices them and raises questions. If you disable any features on purpose, a comment in the spec file would be very helpful. Look for unreleased package dependencies in the QA queue. * Don't target all of Red Hat Linux 8.0 and 9, Fedora Core 1 and 2, when your only testing and build environment is Fedora Core 2. It's okay to release new packages only for the latest distribution version. Certainly better than to confront reviewers with cross-distribution packaging problems (and who would do the verification?). * Do set bugzilla keywords on package requests, so your ticket appears in the proper QA and UPDATE queues: https://bugzilla.fedora.us/describekeywords.cgi * Do verify your own packages in the "pending" repository when a build team member marks a ticket as RESOLVED/PENDING: http://www.fedora.us/wiki/PendingRepository Don't expect the reviewers to take over the final verification always, because afterall, you--as the package developer-ought to find the binary builds satisfactory yourself. * Do show up in other tickets and encourage other developers to review your package in return for a review/approval of their package: http://www.fedora.us/wiki/PackageSubmissionQAPolicy#review * Do take a look at the REVIEWED queue: http://tinyurl.com/33zj3 These are package requests which have been reviewed and approved by somebody already, but need a review/approval by a second person. * Do react on bug reports about your packages in the repository, as long as you're not flooded with hundreds of new ones every day. Mark tickets ASSIGNED or close them as INVALID or WONTFIX if necessary. In particular, when you release an update which requires reviews, existing tickets in NEW state only cause confusion. -- Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.541 loadavg: 0.00 0.00 0.00
Attachment:
pgpyk0MtnKCeL.pgp
Description: PGP signature
