10 Do's and Don'ts of successful collaboration at fedora.us

[Michael Schwendt]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041015/72c2c129/attachment.sig>