10 Do's and Don'ts of successful collaboration at fedora.us
Michael Schwendt
fedora at wir-sind-cool.org
Fri Oct 15 00:04:20 UTC 2004
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://lists.fedoraproject.org/pipermail/devel/attachments/20041015/72c2c129/attachment-0002.bin
More information about the devel
mailing list