$FreeBSD: head/el_GR.ISO8859-7/articles/problem-reports/article.xml
39632 2012-10-01 11:56:00Z gabor $
Το FreeBSD είναι ένα κατοχυρωμένο εμπορικό σύμβολο του FreeBSD Foundation.
Η λέξη CVSup είναι κατοχυρωμένο εμπορικό σύμβολο του John D. Polstra.
Οι λέξεις ή φράσεις IBM, AIX, EtherJet, Netfinity, OS/2, PowerPC, PS/2, S/390, και ThinkPad είναι εμπορικά σύμβολα της International Business Machines Corporation στις Ηνωμένες Πολιτείες, άλλες χώρες, ή και στα δύο ταυτόχρονα.
Οι λέξεις Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, και Xeon είναι εμπορικά σύμβολα ή κατοχυρωμένα εμπορικά σύμβολα της Intel Corporation και των θυγατρικών της στις Ηνωμένες Πολιτείες και σε άλλες χώρες.
Οι λέξεις ή φράσεις SPARC, SPARC64, SPARCengine, και UltraSPARC είναι εμπορικά σύμβολα της SPARC International, Inc. στις Ηνωμένες Πολιτείες και σε άλλες χώρες. Η SPARC International Inc. κατέχει όλα τα εμπορικά δικαιώματα των συμβόλων SPARC και επιτρέπει την ορθή χρήση τους από όλα τα μέλη της, κατόπιν σχετικής άδειας.
Οι λέξεις ή φράσεις Sun, Sun Microsystems, Java, Java Virtual Machine, JavaServer Pages, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, Sun Blade, Sun Enterprise, Sun Fire, SunOS, Ultra και VirtualBox είναι εμπορικά σύμβολα ή κατοχυρωμένα εμπορικά σύμβολα της Sun Microsystems, Inc. στις Ηνωμένες Πολιτείες και σε άλλες χώρες.
Πολλές από τις λέξεις ή φράσεις οι οποίες χρησιμοποιούνται από τους κατασκευαστές ή τους πωλητές τους για να διακρίνουν τα προϊόντα τους θεωρούνται εμπορικά σύμβολα. Όπου αυτές εμφανίζονται σε αυτό το κείμενο και για όσες από αυτές γνωρίζει η Ομάδα Ανάπτυξης του FreeBSD ότι είναι πιθανόν να είναι εμπορικά σύμβολα, θα δείτε ένα από τα σύμβολα: «™» ή «®».
Μια από τις πιο αποκαρδιωτικές εμπειρίες που μπορεί κάποιος να έχει σαν χρήστης ενός προγράμματος είναι να στείλει μια αναφορά προβλήματος μόνο και μόνο για να δει να την κλείνουν απότομα με μια σύντομη και απότομη εξήγηση όπως π.χ. «αυτό δεν είναι πρόβλημα» ή «λάθος PR». Κατά παρόμοιο τρόπο, μια από τις πιο αποκαρδιωτικές εμπειρίες ενός προγραμματιστή είναι να κατακλύζεται από αναφορές προβλημάτων που δεν είναι πραγματικά προβλήματα αλλά αιτήσεις για βοήθεια και υποστήριξη ή αναφορές που περιέχουν λίγες έως καθόλου πληροφορίες σχετικά με το πρόβλημα και πως μπορεί κάποιος να το αναπαράγει.
Αυτό το κείμενο είναι μια προσπάθεια να περιγράψουμε πως μπορείτε να γράφετε καλές αναφορές προβλημάτων. Τι είναι, θα αναρωτιέστε, μια καλή αναφορά προβλήματος; Λοιπόν, για να είμαστε ακριβείς, μια καλή αναφορά προβλήματος είναι αυτή που μπορεί να αναλυθεί και να τη χειριστεί κάποιος γρήγορα, με αποτέλεσμα την ικανοποίηση τόσο του αποστολέα όσο και του προγραμματιστή που την ανέλαβε.
Το κυριότερο μέρος αυτού του άρθρου αναφέρεται στις αναφορές προβλημάτων του FreeBSD. Τα πιο πολλά από όσα θα πούμε εδώ ισχύουν όμως και γενικότερα, για πολλά άλλα πράγματα.
Αυτό το άρθρο είναι οργανωμένο θεματικά κι όχι χρονολογικά, οπότε είναι πιο σωστό να το διαβάσετε ολόκληρο πριν στείλετε κάποια αναφορά προβλήματος και όχι να το χρησιμοποιήσετε σαν οδηγό, βήμα προς βήμα.
Υπάρχουν πολλοί τύποι προβλημάτων, και δεν αξίζουν όλοι μια αναφορά προβλήματος. Φυσικά κανείς δεν είναι τέλειος, και θα υπάρξουν φορές που θα έχετε πειστεί ότι βρήκατε κάποιο πρόβλημα σε ένα πρόγραμμα, όταν στην πραγματικότητα θα έχετε καταλάβει λάθος τη σύνταξη μιας εντολής ή θα έχετε κάνει κάποιο τυπογραφικό λάθος σε ένα αρχείο ρυθμίσεων (αν κι αυτό μερικές φορές είναι ενδεικτικό κακής ή λειψής τεκμηρίωσης ή ακόμα και κακής διαχείρισης λαθών από κάποια εφαρμογή). Ακόμα, υπάρχουν περιπτώσεις που το να στείλετε κάποια αναφορά προβλήματος δεν είναι σωστή κίνηση και το μόνο που μπορεί να πετύχει είναι να ενοχλήσει ή εσάς ή τους προγραμματιστές. Από την άλλη όμως, υπάρχουν περιπτώσεις που μπορεί να είναι καλή σκέψη να στείλετε μια αναφορά προβλήματος για κάτι που δεν είναι bug—μια βελτίωση ή μια αίτηση για κάποιο νέο χαρακτηριστικό, για παράδειγμα.
Τότε λοιπόν, πώς μπορείτε να αποφασίσετε αν κάτι είναι πρόβλημα ή όχι; Ένας απλός κανόνας είναι ότι το πρόβλημά σας δεν είναι bug αν μπορεί να εκφραστεί σαν ερώτηση (συνήθως της μορφής «Πώς κάνω το Χ;» ή «Πού μπορώ να βρω το Ψ;»). Δεν είναι πάντα τόσο άσπρο-μαύρο τα πράγματα βέβαια, αλλά ο κανόνας της ερώτησης καλύπτει την μεγαλύτερη πλειοψηφία των περιπτώσεων. Αν αυτό που ψάχνετε είναι κάποια απάντηση, ίσως είναι καλύτερα να στείλετε την ερώτησή σας στην ηλεκτρονική λίστα γενικών ερωτήσεων του FreeBSD.
Κάποιες περιπτώσεις που πιθανόν να είναι καλή ιδέα να στείλετε μια αναφορά προβλήματος για κάτι που δεν είναι bug, είναι:
Αιτήσεις για μελλοντικές βελτιώσεις. Είναι γενικά καλή ιδέα να δοκιμάσετε να συζητήσετε πρώτα τέτοιες ιδέες σε κάποια λίστα ηλεκτρονικού ταχυδρομείου πριν στείλετε μια αναφορά προβλήματος.
Ειδοποίηση για ενημερωμένες εκδόσεις προγραμμάτων (κυρίως ports, αλλά και μέρη του βασικού συστήματος που συντηρούνται από τρίτους, όπως το BIND και τα διάφορα GNU εργαλεία).
Όταν ένα πακέτο δεν είναι υπό την άμεση επίβλεψη ενός επίσημου υπεύθυνου (η τιμή του MAINTAINER είναι ports@FreeBSD.org) μπορεί οποιοσδήποτε committer ή άλλος ενδιαφερόμενος να διαχειριστεί αυτές τις ειδοποιήσεις. Μπορεί, ακόμη, να σας ζητηθεί και κάποιο patch για ενημερωθεί το πακέτο. Αν έχετε ήδη φτιάξει κάποιο patch, καλό είναι να το συμπεριλάβετε κι αυτό στην αναφορά προβλήματος που θα στείλετε. Έτσι αυξάνονται οι πιθανότητες να το δει κάποιος committer που ενδιαφέρεται και να χειριστεί αυτή την αναφορά προβλήματος πιο σύντομα.
Όταν ένα πακέτο είναι υπό την επίβλεψη κάποιου, συνήθως δεν είναι ιδιαίτερα χρήσιμες οι αναφορές που απλώς ανακοινώνουν μια καινούρια έκδοση από τον συγγραφέα του πηγαίου κώδικα του πακέτου. Συνήθως το ξέρει ήδη ο υπεύθυνος του πακέτου για το FreeBSD, ή έχει συνεργαστεί με τον συγγραφέα του πηγαίου κώδικα για τη νέα έκδοση, ή δοκιμάζει το πακέτο για να δει ότι όλα εξακολουθούν να δουλεύουν, κοκ.
Όπως και να 'χει, είναι καλή ιδέα να ακολουθήσετε τη διαδικασία από το Porter's Handbook.
Ένα bug που δεν μπορεί κανείς να το αναπαράγει είναι πολύ δύσκολο να διορθωθεί. Αν το bug εμφανίστηκε μια φορά μόνο και δεν μπορείτε να το αναπαράγετε εσείς, και φαινομενικά δεν εμφανίζεται σε κανέναν άλλο, είναι πολύ μικρές οι πιθανότητες να μπορεί κάποιος προγραμματιστής να το ανακαλύψει και να καταλάβει τί είναι αυτό που προκαλεί το λάθος. Αυτό δεν σημαίνει πως δεν συμβαίνει, αλλά σημαίνει πως η πιθανότητα να οδηγήσει η αναφορά σας στην λύση του προβλήματος είναι πάρα πολύ μικρή, και μάλλον είναι καλύτερο να σταματήσετε να ασχολείστε με το θέμα. Ακόμα χειρότερα, κάποιες φορές αυτού του είδους τα προβλήματα οφείλονται σε προβλήματα του υλικού (χαλασμένους σκληρούς δίσκους ή επεξεργαστές που υπερθερμαίνονται). Πρέπει πάντοτε πριν στέλνετε μια αναφορά προβλήματος, όταν φυσικά είναι δυνατόν να γίνει κάτι τέτοιο, να προσπαθείτε να αποκλείσετε τέτοιες περιπτώσεις.
Για να αποφασίσετε σε ποιά κατηγορία προβλημάτων ανήκει η αναφορά σας, πρέπει να έχετε κατά νου τα διάφορα μέρη του λογισμικού από το οποίο αποτελείται το FreeBSD:
Ο κώδικας του βασικού συστήματος που έχει γραφτεί και συντηρείται από την ομάδα του FreeBSD. Σε αυτή την κατηγορία λογισμικού ανήκουν ο πυρήνας, η βιβλιοθήκη της C, και οι οδηγοί συσκευών (κατηγορία kern), τα εργαλεία γραμμής εντολών του βασικού συστήματος (κατηγορία bin), οι σελίδες βοήθειας και η τεκμηρίωση του FreeBSD (κατηγορία docs), και ο ιστότοπος του FreeBSD (κατηγορία www). Όλα τα προβλήματα με κάποιο από αυτά τα μέρη του FreeBSD πρέπει να αναφέρονται στην ομάδα ανάπτυξης του FreeBSD.
Ο κώδικας του βασικού συστήματος που έχει γραφτεί και συντηρείται από τρίτους αλλά έχει ενσωματωθεί στο FreeBSD κι έχει προσαρμοστεί σε αυτό. Παραδείγματα τέτοιων προγραμμάτων είναι το bind, ο μεταγλωττιστής gcc(1) και το sendmail(8). Τα περισσότερα προβλήματα με κάποιο από αυτά τα προγράμματα πρέπει να αναφέρονται στην ομάδα ανάπτυξης του FreeBSD. Σε μερικές περιπτώσεις μπορεί να χρειαστεί να αναφερθούν στους αρχικούς συγγραφείς του αντίστοιχου προγράμματος· ειδικά αν το πρόβλημα δεν εμφανίζεται μόνο στο FreeBSD. Οι πιο συνηθισμένες κατηγορίες για τις αναφορές προβλημάτων σχετικά με αυτά τα προγράμματα είναι οι bin και gnu.
¶λλες εφαρμογές, οι οποίες δεν είναι μέρος του βασικού συστήματος του FreeBSD, αλλά υποστηρίζονται ως μέρος της Συλλογής των Ports (κατηγορία ports). Η συντριπτική πλειοψηφία αυτών των εφαρμογών δεν έχει γραφτεί από την ομάδα του FreeBSD. Αυτό που παρέχεται από το FreeBSD είναι απλά η δυνατότητα να εγκατασταθούν αυτές οι εφαρμογές (με μερικές χρήσιμες αλλά όσο το δυνατόν λιγότερες ή μικρότερες σε έκταση αλλαγές) σε ένα σύστημα FreeBSD. Οπότε πρέπει να αναφέρετε οποιοδήποτε πρόβλημα έχουν αυτές οι εφαρμογές στην ομάδα του FreeBSD κυρίως όταν πιστεύετε ότι το πρόβλημα εμφανίζεται μόνο στο FreeBSD. Σε αντίθετη περίπτωση είναι καλύτερη ιδέα να αναφέρεται το πρόβλημα στον αρχικό συγγραφέα του αντίστοιχου προγράμματος.
Τέλος, ελέγξτε ότι η αναφορά που στέλνετε αφορά ένα πρόβλημα το οποίο υπάρχει ακόμα. Μερικές φορές είναι κάπως ενοχλητικό για έναν προγραμματιστή να παίρνει ειδοποιήσεις για ένα πρόβλημα το οποίο έχει ήδη διορθωθεί.
Αν το πρόβλημα που αντιμετωπίζετε αφορά το βασικό σύστημα και δεν έχετε ενημερωθεί ήδη για τις τελευταίες εκδόσεις του FreeBSD, διαβάστε το τμήμα εκδόσεις του FreeBSD στη Λίστα Συχνών Ερωτήσεων του FreeBSD. Η ομάδα του FreeBSD μπορεί να συντηρεί μόνο ένα ορισμένο (μικρό) αριθμό κλάδων ανάπτυξης του FreeBSD. Δε μπορεί να διορθώνει προβλήματα για οποιαδήποτε έκδοση του FreeBSD. Οπότε αν αναφέρετε ότι έχετε πρόβλημα με μια πολύ παλιά έκδοση του συστήματος, η πιο πιθανή απάντηση που θα πάρετε θα είναι να αναβαθμίσετε το σύστημά σας σε μια έκδοση που υποστηρίζεται επίσημα από την ομάδα του FreeBSD και να κάνετε δοκιμές για να δείτε αν το πρόβλημα έχει ήδη διορθωθεί ή υπάρχει ακόμη. Η Ομάδα Ασφάλειας του FreeBSD συντηρεί και ενημερώνει μια λίστα εκδόσεων του FreeBSD που υποστηρίζονται επίσημα.
Αν το πρόβλημα που αντιμετωπίζετε αφορά ένα πακέτο, τότε πρέπει κατ' αρχήν να ενημερώσετε τα Ports σας στην τελευταία έκδοση της Συλλογής των Ports και να δείτε αν το πρόβλημα υπάρχει ακόμα. Οι εφαρμογές που περιέχονται στη Συλλογή των Ports αλλάζουν πολύ γρήγορα. Λόγω του γρήγορου ρυθμού με τον οποίο ενημερώνονται είναι πρακτικά αδύνατον για την ομάδα του FreeBSD να υποστηρίξει οποιαδήποτε παλιότερη έκδοση των Ports. Αυτό σημαίνει ότι τα προβλήματα που έχουν οι παλιές εκδόσεις κάποιων προγραμμάτων απλά δε γίνεται να διορθωθούν.
Είναι καλή ιδέα να κάνετε πάντα μια μικρή έρευνα πριν να στείλετε κάποια αναφορά προβλήματος. Μπορεί το πρόβλημά σας να το έχει ήδη αναφέρει και κάποιος άλλος. Μπορεί να είναι θέμα συζητήσεων σε κάποια λίστα ηλεκτρονικού ταχυδρομείου ή να ήταν πρόσφατα. Μπορεί ακόμα, να είναι ήδη διορθωμένο το πρόβλημα σε κάποια έκδοση νεώτερη από αυτή που τρέχετε. Πρέπει λοιπόν να ελέγχετε όλα τα προφανή σημεία, πριν να στείλετε μια αναφορά προβλήματος. Για το FreeBSD αυτό σημαίνει:
Την λίστα με τις πιο συχνές ερωτήσεις (FAQ) για το FreeBSD. Η λίστα αυτή παρέχει απαντήσεις σε μια μεγάλη ποικιλία ερωτήσεων, όπως αυτές που αφορούν το υλικό, τις εφαρμογές και τις ρυθμίσεις του πυρήνα.
Οι λίστες ηλεκτρονικού ταχυδρομείου—αν δεν έχετε γραφτεί σε κάποια από αυτές, μπορείτε να χρησιμοποιήσετε το αρχείο στις σελίδες του FreeBSD για να αναζητήσετε πληροφορίες σχετικές με το πρόβλημα. Αν το πρόβλημά σας δεν έχει συζητηθεί στις λίστες είναι, γενικά, καλή ιδέα να στείλετε ένα γράμμα στις λίστες ηλεκτρονικού ταχυδρομείου και να περιμένετε λίγες μέρες μήπως κάποιος βρει κάτι που εσείς δεν προσέξατε.
Προαιρετικά, όλο το δίκτυο. Χρησιμοποιήστε την αγαπημένη σας μηχανή αναζήτησης για να βρείτε πληροφορίες σχετικά με το πρόβλημα. Έτσι μπορεί να βρείτε ακόμη και αναφορές από λίστες ηλεκτρονικού ταχυδρομείου ή ομάδες συζητήσεων που δεν ξέρατε ότι υπάρχουν ή δεν σκεφτήκατε να ψάξετε.
Ύστερα μπορείτε να αναζητήσετε σχετικές αναφορές στην βάση αναφορών του FreeBSD (GNATS). Αν το πρόβλημά σας δεν είναι πρόσφατο ή αρκετά περίεργο, είναι πολύ πιθανόν να έχει ήδη στείλει κάποιος άλλος μια αναφορά.
Το πιο σημαντικό από όλα όμως είναι να δείτε μήπως η τεκμηρίωση του FreeBSD περιέχει κάποια λύση στο πρόβλημά σας.
Για το βασικό σύστημα του FreeBSD πρέπει να μελετήσετε προσεκτικά τις οδηγίες που περιέχει το αρχείο /usr/src/UPDATING στο σύστημά σας ή αυτές που περιέχει η τελευταία έκδοση του αρχείου, η οποία είναι διαθέσιμη στη διεύθυνση: http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING. (Αυτό το αρχείο περιέχει κρίσιμες πληροφορίες για αναβάθμιση από μια έκδοση του FreeBSD σε κάποια άλλη—ειδικά για τις εκδόσεις του FreeBSD-CURRENT).
Αν το πρόβλημα εμφανίζεται σε κάτι που εγκαταστάθηκε ως μέρος της Συλλογής των Ports του FreeBSD, τα αντίστοιχα αρχεία με πληροφορίες είναι τα: /usr/ports/UPDATING (για πληροφορίες σχετικά με συγκεκριμένα πακέτα), /usr/ports/CHANGES (για αλλαγές που αφορούν όλη την Συλλογή των Ports). Κι αυτά τα αρχεία είναι διαθέσιμα μέσω CVSweb, στις διευθύνσεις http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING και http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES αντίστοιχα.
Τώρα που έχετε αποφασίσει ότι αξίζει να γράψετε κάποια αναφορά προβλήματος, και ότι όντως είναι κάποιο πρόβλημα του FreeBSD αυτό που θέλετε να περιγράψετε, είναι ώρα να γράψετε την αναφορά. Πριν μπούμε σε λεπτομέρειες σχετικά με το πρόγραμμα που χρησιμοποιείται για να γράφονται και να στέλνονται οι αναφορές προβλημάτων, ας δούμε μερικά κόλπα που θα σας βοηθήσουν να στείλετε χρήσιμες αναφορές.
Μην αφήνετε κενή την γραμμή «Synopsis». Οι αναφορές προβλημάτων στέλνονται σε μια λίστα ηλεκτρονικού ταχυδρομείου, η οποία προωθεί την αναφορά σας σε ανθρώπους σε όλο τον κόσμο (όπου το κείμενο της γραμμής «Synopsis» χρησιμοποιείται ως θέμα του μηνύματος), αλλά και σε μια βάση δεδομένων. Οποιοσδήποτε προσπαθήσει αργότερα να δει μια λίστα με τις αναφορές προβλημάτων μπορεί να αγνοήσει εντελώς την αναφορά σας αν δεν έχει θέμα. Να έχετε κατα νου σας ότι οι αναφορές μένουν σε αυτή τη βάση μέχρι κάποιος να ασχοληθεί μαζί τους και να τις κλείσει. Μια ανώνυμη αναφορά, χωρίς κανένα θέμα, συνήθως, χάνεται στο θόρυβο.
Μη χρησιμοποιείτε αταίριαστες περιγραφές στη γραμμή «Synopsis». Μην θεωρείτε ότι οποιοσδήποτε διαβάσει την αναφορά σας θα έχει και το κατάλληλο υπόβαθρο για να καταλάβει τι λέτε, οπότε όσο περισσότερες λεπτομέρειες συμπεριλάβετε τόσο καλύτερα είναι. Για παράδειγμα, η αναφορά και το πρόβλημα που στέλνετε ποιο μέρος του συστήματός σας αφορά; Το πρόβλημα εμφανίζεται μόνο κατά τη διάρκεια της εγκατάστασης ή και μετά; Για παράδειγμα, δείτε πόσο πιο καλά είναι αν αντί να γράψετε Synopsis: portupgrade is broken γίνετε πιο περιγραφικοί Synopsis: port sysutils/portupgrade coredumps on -current. (Ειδικά στην περίπτωση των ports είναι πολύ χρήσιμο να υπάρχει τόσο η κατηγορία όσο και το όνομα του port στη γραμμή της σύνοψης).
Αν έχετε κάποιο patch, πείτε το. Είναι πολύ ππιο πιθανό να ασχοληθεί κάποιος με μια αναφορά προβλήματος που περιλαμβάνει και κάποιο patch από ότι με κάποια που απλά αναφέρει το πρόβλημα. Αν η αναφορά σας περιλαμβάνει κάποιο patch τότε είναι καλή ιδέα να προσθέσετε το κείμενο [patch] στην αρχή της «Synopsis» σας. (Παρόλο που δεν είναι υποχρεωτικό να χρησιμοποιήσετε ακριβώς αυτό το κείμενο, συνήθως αυτό χρησιμοποιούν οι περισσότεροι μέχρι σήμερα.)
Αν είστε εσείς ο υπεύθυνος για τη συντήρηση κάποιου μέρους του κώδικα, πείτε το. Αν είναι δική σας ευθύνη η συντήρηση κάποιου μέρους του κώδικα του FreeBSD (για παράδειγμα είστε ο MAINTAINER κάποιου port), δεν είναι άσχημη ιδέα να προσθέσετε το κείμενο [maintainer update] στην αρχή της «Synopsis» σας. Οπωσδήποτε όμως να θυμηθείτε να θέσετε την τιμή του «Class» της αναφοράς σας σε maintainer-update. Έτσι όποιο μέλος της ομάδας ανάπτυξης ασχοληθεί με την αναφορά σας δε θα χρειάζεται να ελέγξει αν όντως εσείς είστε ο maintainer.
Να είστε ακριβείς & συγκεκριμένοι. Όσο περισσότερες πληροφορίες γράψετε σχετικά με το πρόβλημα που αντιμετωπίζετε, τόσο αυξάνονται οι πιθανότητες να πάρετε μια χρήσιμη και σωστή απάντηση.
Συμπεριλάβετε την έκδοση του FreeBSD που χρησιμοποιείτε (παρακάτω θα δούμε πως υπάρχει συγκεκριμένο μέρος που μπορείτε να το γράψετε αυτό) και ποιας αρχιτεκτονικής είναι το μηχάνημά σας. Είναι ιδιαίτερα χρήσιμο να γράψετε αν τρέχετε κάποια επίσημη έκδοση (π.χ. από ένα CDROM ή κάποια που κατεβάσατε από το δίκτυο) ή αν το σύστημα σας το ενημερώνετε με το cvsup(1) (κι αν ναι, πόσο πρόσφατα το ενημερώσατε). Αν χρησιμοποιείτε το FreeBSD-CURRENT, αυτό είναι και το πρώτο πράγμα που θα σας ρωτήσει κάποιος, επειδή οι αλλαγές και οι διορθώσεις (ειδικά για τα σημαντικά προβλήματα) γίνονται, γενικά, πολύ γρήγορα και συχνά. Οι χρήστες του FreeBSD-CURRENT πρέπει να τις παρακολουθούν με προσοχή και να ενημερώνουν συχνά το σύστημά τους.
Συμπεριλάβετε και τις ρυθμίσεις που περιέχει το αρχείο make.conf στο σύστημά σας. Σημειώστε πως η χρήση της επιλογής -O2 του gcc(1) είναι γνωστή πηγή προβλημάτων. Παρόλο που η ομάδα ανάπτυξης του FreeBSD δεν θα 'λεγε όχι σε patches που να διορθώνουν αυτά τα προβλήματα είναι γενικά απρόθυμη στο να αναζητά τις αιτίες τέτοιων προβλημάτων επειδή δεν έχει το χρόνο ή το ανθρώπινο δυναμικό να το κάνει. Αν τα προβλήματά σας οφείλονται σε αυτό το πρόβλημα των optimizations μπορεί να σας απαντήσουν ότι δεν υποστηρίζεται αυτός ο τρόπος χρήσης του FreeBSD.
Αν το πρόβλημά σας αφορά τον πυρήνα, τότε να είστε προετοιμασμένοι να δώσετε και τις εξής έξτρα πληροφορίες. (Δεν είναι ανάγκη να τις συμπεριλάβετε έτσι κι αλλιώς, αφού το μόνο που θα καταφέρετε είναι να αυξήσετε χωρίς λόγο το χώρο που απαιτεί η βάση προβλημάτων στο δίσκο, αλλά δεν είναι κακή ιδέα να συμπεριλάβετε μόνο τα μέρη που θεωρείτε σχετικά):
τις ρυθμίσεις του πυρήνα σας (και ποιές συσκευές έχετε εγκατεστημένες στο μηχάνημά σας)
αν έχετε ενεργοποιημένες επιλογές debugging στον πυρήνα σας (όπως π.χ. την επιλογή WITNESS) κι αν ναι αν το πρόβλημα συνεχίζει να υπάρχει αφαιρώντας αυτές τις επιλογές
ένα backtrace, αν μπορέσατε να καταγράψετε κάποιο
αν έχετε διαβάσει προσεκτικά το αρχείο src/UPDATING κι αν το πρόβλημά σας αναφέρεται ή όχι σε αυτό (είναι σίγουρο ότι κάποιος θα σας ρωτήσει γι αυτό)
αν μπορείτε να τρέξετε κάποιο άλλο πυρήνα σαν προσωρινή λύση (έτσι αποκλείονται προβλήματα με το υλικό, όπως δίσκοι που άρχισαν να χαλάνε ή επεξεργαστές που υπερθερμαίνονται, που μπορεί να σας μπερδέψουν και να νομίσετε ότι έχει πρόβλημα ο πυρήνας)
Αν έχετε πρόβλημα με κάποιο port, τότε να έχετε διαθέσιμες τις εξής πληροφορίες. (Δεν είναι ανάγκη να τις συμπεριλάβετε έτσι κι αλλιώς, αλλά δεν είναι κακή ιδέα να συμπεριλάβετε μόνο τα μέρη που θεωρείτε σχετικά):
ποια ports έχετε εγκαταστήσει
μεταβλητές του περιβάλλοντος που μπορεί να επηρεάζουν τις προκαθορισμένες ρυθμίσεις του συστήματος στο αρχείο bsd.port.mk, όπως π.χ. η μεταβλητή περιβάλλοντος PORTSDIR
αν έχετε διαβάσει το αρχείο ports/UPDATING κι αν το πρόβλημά σας αναφέρεται ή όχι σε αυτό (είναι σίγουρο ότι κάποιος θα σας ρωτήσει γι αυτό)
Αποφύγετε τις ασαφείς αιτήσεις για νέα χαρακτηριστικά. Οι αναφορές της μορφής «στ' αλήθεια, κάποιος πρέπει να υλοποιήσει κάτι που να κάνει το τάδε ή το δείνα» δεν είναι πολύ σίγουρο ότι θα τύχουν καλύτερης αντιμετώπισης από τις αναφορές που περιγράφουν συγκεκριμένες αλλαγές. Να θυμάστε ότι ο κώδικας είναι διαθέσιμος σε όλους, οπότε αν θέλετε κάποιο νέο χαρακτηριστικό ο καλύτερος τρόπος να το δείτε να υλοποιείται σαν μέρος του FreeBSD είναι να το φτιάξετε εσείς. Πολλές φορές μάλιστα είναι προτιμότερο να ρωτήσετε στην freebsd-questions παρά να δημιουργήσετε μια καινούρια εγγραφή στη βάση αναφορών προβλημάτων.
Σιγουρευτείτε ότι δεν έχει στείλει ήδη κάποιος άλλος μια παρόμοια αναφορά. Παρόλο που το έχουμε ξαναπεί αυτό, αξίζει να το αναφέρουμε πάλι εδώ. Χρειάζεται μόνο ένα λεπτό για να ανοίξετε ένα φυλλομετρητή και να χρησιμοποιήσετε τη μηχανή αναζήτησης αναφορών προβλημάτων του FreeBSD στη διεύθυνση http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query. (Φυσικά, όλοι έχουμε ξεχάσει κάποιες φορές να το κάνουμε αυτό.)
Αποφύγετε τις επικίνδυνες αιτήσεις. Αν η αναφορά σας επηρεάζει ένα μέρος του κώδικα για το οποίο υπήρξαν διαφωνίες στο παρελθόν, μάλλον πρέπει εκτός από τα patches που θα ετοιμάσετε να είστε προετοιμασμένοι και για να δικιολογήσετε τις αλλαγές σας, εξηγώντας γιατί είναι «Σωστό να Γίνουν». Όπως είπαμε και πιο πριν, μια προσεκτική αναζήτηση στα αρχεία των λιστών ηλεκτρονικού ταχυδρομείου στη διεύθυνση http://www.FreeBSD.org/search/search.html#mailinglists είναι πάντα καλός τρόπος να προετοιμαστείτε για τέτοιες καταστάσεις.
Να είστε ευγενικοί. Σχεδόν όλοι όσοι πρόκειται να ασχοληθούν με την αναφορά σας για κάποιο πρόβλημα είναι εθελοντές. Σε κανέναν δεν αρέσει να τους λένε τι να κάνουν όταν ήδη κάνουν το ίδιο πράγμα εδώ και καιρό για λόγους που δεν έχουν σχέση με οικονομικές απολαβές. Είναι καλό να το έχετε κατά νου αυτό όταν ασχολείστε με προγράμματα Ανοιχτού Λογισμικού ή Λογισμικού Ελεύθερου Κώδικα.
Αν χρησιμοποιείτε το πρόγραμμα send-pr(1), σιγουρευτείτε ότι η μεταβλητή περιβάλλοντος VISUAL (ή η μεταβλητή περιβάλλοντος EDITOR αν δεν είναι ορισμένη η VISUAL) έχει κάποια λογική τιμή.
Ελέγξτε επίσης ότι η αποστολή ηλεκτρονικής αλληλογραφίας λειτουργεί σωστά. Το πρόγραμμα send-pr(1) χρησιμοποιεί μηνύματα ηλεκτρονικής αλληλογραφίας για την αποστολή και την παρακολούθηση των αναφορών προβλημάτων. Αν δε μπορείτε να στείλετε μηνύματα ηλεκτρονικής αλληλογραφίας από το μηχάνημα στο οποίο χρησιμοποιείτε το πρόγραμμα send-pr(1), το μήνυμά σας και η αναφορά δε θα φτάσει ποτέ στη βάση αναφορών προβλημάτων του FreeBSD. Για λεπτομέρειες σχετικά με τη ρύθμιση της ηλεκτρονικής αλληλογραφίας στο FreeBSD δείτε το κεφάλαιο περί «Ηλεκτρονικής Αλληλογραφίας» στο Εγχειρίδιο του FreeBSD στη διεύθυνση http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html.
Σιγουρευτείτε ότι το πρόγραμμα αλληλογραφίας το οποίο χρησιμοποιείτε δεν θα αλλάξει ούτε το περιεχόμενο ούτε τη μορφή του κειμένου που στέλνετε πριν αυτό φτάσει στο σύστημα GNATS του FreeBSD. Πιο συγκεκριμένα, αν το πρόγραμμα αλληλογραφίας σας αποφασίζει αυτόματα για το μήκος κάθε γραμμής κειμένου, αλλάζει τους χαρακτήρες στηλοθέτη με κενά ή επεμβαίνει στους χαρακτήρες αλλαγής γραμμής, τότε κάθε patch που στέλνετε μπορεί να είναι εντελώς άχρηστο. Από την άλλη, στα πεδία της αναφοράς προβλήματος τα οποία περιέχουν απλό κείμενο είναι πιο βολικό να έχει περίπου 70 στήλες η κάθε γραμμή. Έτσι διαβάζεται πιο εύκολα το κείμενο της αναφοράς μέσα από το web interface μας.
Παρόμοια προσοχή χρειάζεται και όταν, αντί για το εργαλείο send-pr(1), χρησιμοποιείτε τη φόρμα υποβολής αναφορών που έχει η ιστοσελίδα μας. Η αντιγραφή και επικόλληση κειμένου μπορεί να επηρεάσει τη μορφοποίηση του κειμένου. Σε μερικές περιπτώσεις μπορεί να χρειαστεί ακόμα και το εργαλείο uuencode(1) για να είστε σίγουροι ότι ένα patch φτάνει ως εμάς χωρίς αλλαγές.
Τέλος, αν η αναφορά σας περιέχει μεγάλα αρχεία ή αρκετό κείμενο, ίσως είναι καλύτερα να την προετοιμάσετε σε ένα ξεχωριστό αρχείο και να την αποθηκεύσετε πριν προσπαθήσετε να τη στείλετε. Αν δεν πετύχει η αποστολή της αναφοράς, δε θα ριψοκινδυνέψετε να χαθεί ότι έχετε γράψει μέχρι εκείνη τη στιγμή. Η φόρμα αποστολής μέσω web είναι συχνά πηγή τέτοιων προβλήματων.
Το πρόγραμμα send-pr(1) έχει την
δυνατότητα να επισυνάψει αρχεία σε μια αναφορά προβλήματος. Μπορείτε να επισυνάψετε
όσα αρχεία θέλετε, αρκεί το καθένα να έχει μοναδικό βασικό όνομα (το όνομα του
αρχείου χωρίς την διαδρομή). Απλά χρησιμοποιήστε την παράμετρο -a στην γραμμή εντολών για να καταδείξετε τα ονόματα των
αρχείων που θέλετε να επισυνάψετε:
% send-pr -a /var/run/dmesg -a /tmp/errors
Δεν χρειάζεται να ανησυχείτε για τα αρχεία που δεν είναι κείμενο. Θα κωδικοποιηθούν κατάλληλα για να μην τα αλλάξει το πρόγραμμα αποστολής ηλεκτρονικής αλληλογραφίας που χρησιμοποιείτε.
Αν μαζί με την αναφορά στείλετε και κάποιο patch, φροντίστε να χρησιμοποιήσετε
την επιλογή -c ή την -u στην
εντολή diff(1) για να
δημιουργήσετε ένα context ή unified αρχείο διαφορών, και μην ξεχάσετε να σημειώσετε
τις ακριβείς εκδόσεις των αρχείων που αλλάξατε έτσι ώστε οι προγραμματιστές που
θα διαβάσουν την αναφορά σας να μπορούν να κάνουν τις ίδιες αλλαγές εύκολα. Για τα
προβλήματα που αφορούν τον πυρήνα ή τα εργαλεία του βασικού συστήματος είναι
προτιμότερο το patch σας να βασίζεται στο FreeBSD-CURRENT (το HEAD branch του CVS)
αφού όλες οι αλλαγές πρέπει πρώτα να γίνονται σε αυτό το branch για να δοκιμαστούν.
Αφού περάσει κάποιος καιρός κι οι αλλαγές δοκιμαστούν αρκετά μόνο τότε
ενσωματώνονται/μεταφέρονται οι αλλαγές στο FreeBSD-STABLE branch.
Αν ενσωματώσετε το patch σας στην αναφορά, αντί να το στείλετε σαν επισύναψη, προσέξτε αρκετά γιατί ένα αρκετά συχνό πρόβλημα είναι πως πολλά προγράμματα ηλεκτρονικής αλληλογραφίας έχουν την τάση να μετατρέπουν τους στηλοθέτες σε κενά, κάτι που καταστρέφει εντελώς οτιδήποτε αποτελεί μέρος κάποιου Makefile.
Μη στέλνετε τα patches σας ως επισυνάψεις με την κωδικοποίηση Content-Transfer-Encoding: quoted-printable. Αυτή η κωδικοποίηση αλλάζει κάποιους χαρακτήρες με αποτέλεσμα να είναι άχρηστο ολόκληρο το patch.
Γενικά, πάντως, δεν τρέχει τίποτα αν ενσωματώσετε κάποιο μικρό patch στην αναφορά σας—ειδικά αν είναι φανερό πως διορθώνει το πρόβλημα που περιγράφεται στην αναφορά. Τα πιο μεγάλα patches, κυρίως κώδικας που μπορεί να απαιτεί λεπτομερή ανάλυση και δοκιμές πριν γίνει commit, είναι καλύτερα να τα ανεβάζετε σε κάποιο web ή ftp server και να περιλαμβάνετε στην αναφορά σας το URL για να τα βρίσκει ο αναγνώστης της αναφοράς αντί να ενσωματώνετε το ίδιο το patch. Πολλές φορές τα patches καταστρέφονται όταν είναι μέρος ενός email, ειδικά όταν περνούν από το πρόγραμμα GNATS, κι όσο πιο μεγάλο είναι το patch τόσο πιο δύσκολο θα είναι για όποιον ενδιαφέρεται να το διορθώσει για να το δοκιμάσει. Ένα άλλο καλό που έχει η διανομή ενός patch μέσω web ή ftp είναι ότι μπορείτε να αλλάξετε το patch χωρίς να χρειάζεται να το ξαναστείλετε όλο σαν μέρος μιας απάντησης στην αρχική αναφορά. Τα μεγάλα patches αυξάνουν μόνιμα το μέγεθος της βάσης αναφορών, αφού ακόμη κι όταν διορθωθεί ένα πρόβλημα και κλείσει η αντίστοιχη αναφορά προβλήματος δε σβήνεται τίποτα από τη βάση αναφορών, αλλά απλά σημειώνεται ως closed.
Μην ξεχνάτε επίσης ότι, αν δεν το δηλώσετε ρητά στην αναφορά που θα στείλετε ή στο ίδιο το patch, οποιεσδήποτε αλλαγές στείλετε θεωρείται αυτόματα ότι είναι διαθέσιμες κάτω από τους ίδιους όρους και με την ίδια άδεια που έχει η έκδοση του κάθε αρχείου που έχετε τροποποιήσει.
Όταν τρέξετε το πρόγραμμα send-pr(1) θα δείτε μια φόρμα αναφοράς. Η φόρμα της αναφοράς αποτελείται από μια σειρά πεδίων. Κάποια από αυτά είναι είναι προσυμπληρωμένα. Κάποια άλλα έχουν σχόλια που εξηγούν τον σκοπό τους ή αναφέρουν τις αποδεκτές τιμές. Μην ανησυχείτε για τα σχόλια, αφού έτσι κι αλλιώς θα αφαιρεθούν αυτόματα αν δεν τα αλλάξετε ή δεν τα σβήσετε.
Στην κορυφή της φόρμας, κάτω από τις γραμμές που αρχίζουν με SEND-PR: υπάρχουν οι επικεφαλίδες ενός γράμματος. Συνήθως δεν χρειάζετε να κάνετε κάποια αλλαγή σε αυτές, εκτός κι αν στέλνετε την αναφορά από κάποιο μηχάνημα το οποίο μπορεί να στείλει email αλλά δεν μπορεί να λάβει, που θα πρέπει να προσέξετε οι γραμμές From: και Reply-To: να έχουν την πραγματική σας email διεύθυνση. Μπορείτε φυσικα να στείλετε στον εαυτό σας ή κάποιον άλλο ένα αντίγραφο της αναφοράς προβλήματος προσθέτοντας τις κατάλληλες Cc: γραμμές.
Μετά θα δείτε μια σειρά από πεδία μιας γραμμής:
Submitter-Id: Μην το αλλάξετε αυτό. Η προκαθορισμένη τιμή του, current-users, είναι σωστή ακόμα κι αν χρησιμοποιείτε το FreeBSD-STABLE.
Originator: Αυτό το πεδίο είναι κανονικά προσυμπληρωμένο με το όνομα του τρέχοντος χρήστη. Αν αυτό δεν είναι σωστό, παρακαλώ συμπληρώστε την τιμή αυτού του πεδίου με το πραγματικό σας όνομα και προαιρετικά την email διεύθυνσή σας μέσα σε < και >.
Organization: Αυτό το πεδίο δεν χρησιμοποιείται για τίποτα σημαντικό.
Confidential: Αυτό το πεδίο είναι προσυμπληρωμένο με no. Δεν έχει νόημα να το αλλάξετε σε κάτι άλλο, αφού δεν υπάρχουν εμπιστευτικές αναφορές προβλημάτων στο FreeBSD—η συλλογή των προβλημάτων είναι ανοιχτή και διαθέσιμη μέσω CVSup για όλο τον κόσμο.
Synopsis: Συμπληρώστε αυτό με μια σύντομη και ακριβή περιγραφή του προβλήματος. Η synopsis χρησιμοποιείται σαν το θέμα στα email τα σχετικά με την αναφορά, καθώς και σε λίστες αναφορών και περιλήψεις. Οι αναφορές προβλήματος με περίεργες περιγραφές στο πεδίο αυτό συνήθως αγνοούνται.
Όπως είπαμε παραπάνω, αν η αναφορά σας περιλαμβάνει κάποιο patch καλό είναι να ξεκινήσετε την γραμμή της σύνοψης με το κείμενο [patch]. Αν πάλι είστε ο υπεύθυνος (maintainer) για κάποιο μέρος του κώδικα, καλό είναι να προσθέσετε στη σύνοψη το κείμενο [maintainer update] και να θέσετε την τιμή της επικεφαλίδας «Class» σε maintainer-update.
Severity: Μπορεί να πάρει τιμή non-critical, serious ή critical. Μην αντιδράτε υπερβολικά. Αποφύγετε να χαρακτηρίζετε τις αναφορές σας critical εκτός κι αν είναι όντως μεγάλης σημασίας (π.χ. root exploit, κάποιο panic που μπορεί να αναπαραχθεί εύκολα) ή serious εκτός κι αν είναι κάτι που αφορά πολλούς χρήστες (προβλήματα με συγκεκριμένους οδηγούς συσκευών ή εργαλεία του συστήματος). Δεν είναι απαραίτητο πως οι προγραμματιστές του FreeBSD θα ασχοληθούν πιο νωρίς με το πρόβλημά σας αν υπερβάλλετε για την σημασία του επειδή υπάρχει πολύς κόσμος που το κάνει αυτό—μάλιστα, υπάρχουν προγραμματιστές που αγνοούν εντελώς αυτό το πεδίο και το επόμενο, ακριβώς επειδή αυτοί που στέλνουν τις αναφορές έχουν την τάση να υπερεκτιμούν τα προβλήματά τους.
Priority: Μπορεί να πάρει τιμή low, medium ή high. Προτεραιότητα high πρέπει να δίνεται μόνο σε αναφορές προβλημάτων τα οποία επηρεάζουν πρακτικά όλους τους χρήστες του FreeBSD και medium στα προβλήματα που αφορούν ένα μεγάλο αριθμό χρηστών.
Category: Επιλέξτε μια από τις ακόλουθες κατηγορίες (από το αρχείο http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/send-pr/categories):
advocacy: αναφορές σχετικές με την δημόσια εικόνα του FreeBSD. Χρησιμοποιείται σπάνια.
alpha: αναφορές σχετικές με την πλατφόρμα Alpha platform.
amd64: αναφορές σχετικά με προβλήματα της πλατφόρμας AMD64.
bin: αναφορές σχετικές με προγράμματα στο βασικό σύστημα.
conf: αναφορές σχετικές με αρχεία ρυθμίσεων, προκαθορισμένες τιμές, κλπ.
docs: αναφορές σχετικές με τις manual pages ή γενικά την τεκμηρίωση.
gnu: αναφορές σχετικές με προγράμματα GNU, όπως π.χ. gcc(1) ή grep(1).
i386: αναφορές σχετικές με την πλατφόρμα i386 platform.
ia64: αναφορές σχετικές με την πλατφόρμα ia64.
java: αναφορές σχετικές με την υλοποίηση της Εικονικής Μηχανής Java™. (Οι αναφορές για πακέτα τα οποία απλά απαιτούν τη Java για να τρέξουν καταχωρούνται στην κατηγορία ports.)
kern: αναφορές για τον πυρήνα.
misc: οτιδήποτε δεν ταιριάζει σε κάποια από τις υπόλοιπες κατηγορίες. (Σημειώστε πως είναι εύκολο να χαθεί μια αναφορά σε αυτή την κατηγορία.)
ports: αναφορές σχετικές με τα ports.
powerpc: αναφορές σχετικές με την πλατφόρμα PowerPC.
sparc64: αναφορές σχετικές με την πλατφόρμα SPARC.
standards: αναφορές σχετικές με την συμβατότητα με τα διάφορα Πρότυπα.
threads: αναφορές σχετικές με την υλοποίηση των threads στο FreeBSD (ειδικά στο FreeBSD-CURRENT).
usb: αναφορές σχετικά με το υποσύστημα USB του FreeBSD και την υποστήριξη συσκευών USB.
www: αλλαγές ή βελτιώσεις στην δικτυακή σελίδα του FreeBSD.
Class: Για το πεδίο αυτό, επιλέξτε μια από τις παρακάτω τιμές:
sw-bug: software bugs.
doc-bug: λάθη στην τεκμηρίωση.
change-request: ιδέες και αιτήσεις για πρόσθετα χαρακτηριστικά ή αλλαγές σε υπάρχοντα.
update: ενημερώσεις των ports ή άλλων προγραμμάτων που φτιάχνονται από τρίτους.
maintainer-update: ενημερώσεις σε ports για τα οποία συντηρείτε εσείς.
Release: Η έκδοση του FreeBSD που χρησιμοποιείτε. Αυτό το πεδίο συμπληρώνεται αυτόματα από την send-pr(1) και χρειάζεται να το αλλάξετε μόνο στην περίπτωση που στέλνετε μια αναφορά προβλήματος από άλλο μηχάννημα, κι όχι από αυτό που έχει το πρόβλημα.
Τέλος, υπάρχει μια σειρά από πεδία με περισσότερες από μια γραμμές το καθένα:
Environment: Εδώ πρέπει να περιγράφεται, με όσο το δυνατόν μεγαλύτερη ακρίβεια, το περιβάλλον στο οποίο παρατηρήσατε το πρόβλημα. Αυτό περιλαμβάνει την έκδοση του λειτουργικού συστήματος, την έκδοση του συγκεκριμένου προγράμματος ή αρχείου που έχει το πρόβλημα και οποιαδήποτε άλλα χαρακτηριστικά από το σύστημα και τις ρυθμίσεις του θεωρείτε σημαντικά, άλλα εγκατεστημένα προγράμματα που πιστεύετε ότι πιθανόν έχουν σχέση με το πρόβλημα, κλπ—πολύ απλά, οτιδήποτε χρειάζεται να ξέρει ένας προγραμματιστής για να εξομοιώσει με ακρίβεια το περιβάλλον στο οποίο εμφανίζεται το πρόβλημα.
Description: Μια πλήρης και ακριβής περιγραφή του προβλήματος που αντιμετωπίζετε. Προσπαθείστε να αποφύγετε εικασίες σχετικά με την αιτία του προβλήματος εκτός κι αν είστε σίγουροι ότι βρίσκετε σε σωστό δρόμο, καθώς μπορεί να οδηγήσετε κάποιο προγραμματιστή να κάνει λάθος υποθέτοντας κάποια πράγματα που δεν είναι σωστά.
How-To-Repeat: Μια περίληψη των ενεργειών που χρειάζονται για να αναπαράγει κάποιος το πρόβλημα.
Fix: Κατά προτίμηση κάποιο patch ή τουλάχιστον κάτι που ξεπερνά/αποφεύγει το πρόβλημα (κάτι που όχι μόνο βοηθά όποιον έχει το ίδιο πρόβλημα να το αποφύγει, αλλά μπορεί ακόμη και να βοηθήσει κάποιον προγραμματιστή να καταλάβει την πραγματική αιτία του προβλήματος). Αν δεν έχετε βέβαια κάποια ιδέα, μπορείτε πάντα να αφήσετε αυτό το πεδίο κενό. Είναι πολύ καλύτερα από το να κάνετε απλώς εικασίες.
Όταν τελειώσετε με το γράψιμο, την συμπλήρωση της φόρμας, και σώσετε το κείμενο της
αναφοράς σε ένα αρχείο, το πρόγραμμα send-pr(1) θα σας
δείξει μια προτροπή s)end, e)dit or a)bort?. Μπορείτε
τότε να πατήσετε s για να συνεχίσετε και να σταλεί η
αναφορά, e για να ξεκινήσετε πάλι τον κειμενογράφο σας,
ή a για να εγκαταλείψετε. Αν επιλέξετε το
τελευταίο, το κείμενο της αναφοράς σας θα παραμείνει στο δίσκο (η send-pr(1) θα γράψει
το όνομα του αρχείου πριν τερματίσει), οπότε μπορείτε να το επεξεργαστείτε με την
ησυχία σας αργότερα ή να το μεταφέρετε σε κάποιο σύστημα με καλύτερη σύνδεση
δικτύου, πριν να το στείλετε με την επιλογή -f της
send-pr(1):
% send-pr -f ~/my-problem-report
Αυτή η εντολή θα διαβάσει μια αναφορά προβλήματος από το αρχείο, θα κάνει κάποιους ελέγχους στα περιεχόμενα, θα σβήσει τα σχόλια και στείλει την αναφορά.
Μόλις η αναφορά σας καταχωρηθεί, θα πάρετε μια απάντηση μέσω email που θα περιλαμβάνει τον αριθμό που έχει σχετιστεί με την αναφορά σας και μια διεύθυνση URL όπου μπορείτε να διαβάσετε την αναφορά και την κατάστασή της. Με λίγη τύχη, κάποιος θα ενδιαφερθεί για την αναφορά σας και θα προσπαθήσει να λύσει το πρόβλημα ή τουλάχιστον, ανάλογα με την περίπτωση, να σας εξηγήσει γιατί δεν είναι πρόβλημα. Θα ειδοποιήστε αυτόματα για κάθε αλλαγή στην κατάσταση της αναφοράς, και θα παίρνετε αντίγραφα μέσω αλληλογραφίας με οποιαδήποτε σχόλια ή patches στέλνει κάποιος σαν απάντηση στην αναφορά σας.
Αν κάποιος σας ζητήσει επιπλέον πληροφορίες ή θυμηθείτε κάτι ή ανακαλύψετε κάτι που δεν έχετε αναφέρει στην αρχική σας αναφορά, τότε χρησιμοποιήστε έναν από τους ακόλουθους τρόπους για να στείλετε συμπληρωματικές πληροφορίες:
Ο πιο εύκολος τρόπος είναι να ακολουθήσετε το σύνδεσμο στην σελίδα της αναφοράς, την οποία μπορείτε να βρείτε από τη σελίδα αναζήτησης των αναφορών. Αν ακολουθήσετε το σύνδεσμο που έχει στο κάτω μέρος η σελίδα θα ανοίξει το πρόγραμμα αλληλογραφίας σας με το σωστό αποστολέα και το σωστό θέμα (αρκεί ο φυλλομετρητής σας υποστηρίζει την εκτέλεση εξωτερικών προγραμμάτων).
Εναλλακτικά μπορείτε να στείλετε απλά ένα μήνυμα στη διεύθυνση <bug-followup@FreeBSD.org>,
προσέχοντας να βάλετε το σωστό αριθμό αναφοράς στο θέμα έτσι ώστε να τον βρει το
σύστημα παρακολούθησης αναφορών του FreeBSD και να ξέρει σε ποιά αναφορά πρέπει
να επισυνάψει το μήνυμά σας.
Σημείωση: Αν δεν συμπεριλάβετε το σωστό αριθμό αναφοράς στο θέμα, το πρόγραμμα GNATS που οργανώνει τις αναφορές σε κατηγορίες θα μπερδευτεί και θα ανοίξει μια νέα αναφορά την οποία μετά αναθέτει στον διαχειριστή του συστήματος GNATS. Έτσι η απάντησή σας θα μείνει αφανής μέχρι να ψάξει κάποιος για αναφορές που είναι καταχωρημένες λάθος και να τις ξεκαθαρίσει, κάτι που μπορεί να γίνει μετά από μέρες ή και ολόκληρες εβδομάδες.
Λάθος τρόπος:
Subject: that PR I sent
Σωστός τρόπος:
Subject: Re: ports/12345: compilation problem with foo/bar
Αν η αναφορά προβλήματος παραμένει στην κατάσταση «open» παρόλο που το πρόβλημα έχει σταματήσει να εμφανίζεται πλέον, απλώς στείλτε μια απάντηση στην αναφορά (με τον τρόπο που αναφέραμε παραπάνω), εξηγώντας πως ή πότε διορθώθηκε το πρόβλημα.
Παρακάτω θα βρείτε κάποιες πηγές που είναι σχετικές με το θέμα των αναφορών προβλήματος. Δεν είναι μια πλήρης ή επαρκής λίστα, φυσικά.
How to Report Bugs Effectively—μια πολύ καλή έκθεση από τον Simon G. Tatham που περιγράφει πως μπορείτε να γράφετε χρήσιμες αναφορές προβλήματων (όχι μόνο για το FreeBSD).
Problem Report Handling Guidelines—χρήσιμες πληροφορίες για τον τρόπο με τον οποίο χειρίζεται τις αναφορές προβλημάτων η ομάδα ανάπτυξης του FreeBSD
Αυτό το κείμενο, και άλλα κείμενα, μπορεί να βρεθεί στο ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Για ερωτήσεις σχετικά με το FreeBSD, διαβάστε την τεκμηρίωση πριν να επικοινωνήσετε με την
<questions@FreeBSD.org>.
Για ερωτήσεις σχετικά με αυτή την τεκμηρίωση, στείλτε e-mail στην <doc@FreeBSD.org>.