diff --git a/el_GR.ISO8859-7/articles/problem-reports/Makefile b/el_GR.ISO8859-7/articles/problem-reports/Makefile new file mode 100644 index 0000000000..9c4a72fd56 --- /dev/null +++ b/el_GR.ISO8859-7/articles/problem-reports/Makefile @@ -0,0 +1,18 @@ +# $FreeBSD$ +# Original revision: 1.1 + +DOC?= article + +FORMATS?= html + +INSTALL_COMPRESSED?=gz +INSTALL_ONLY_COMPRESSED?= + +JADEFLAGS+= -V %generate-article-toc% +TIDYFLAGS+= -raw + +SRCS= article.sgml + +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/el_GR.ISO8859-7/articles/problem-reports/article.sgml b/el_GR.ISO8859-7/articles/problem-reports/article.sgml new file mode 100644 index 0000000000..b724f6ec9e --- /dev/null +++ b/el_GR.ISO8859-7/articles/problem-reports/article.sgml @@ -0,0 +1,557 @@ + + + +%man; + +%mailing-lists; +]> + +
+ + Γράφοντας Αναφορές Προβλημάτων για το FreeBSD + + $FreeBSD$ + + + + Αυτό το άρθρο περιγράφει πως να μορφοποιήσετε και να + στείλετε μια αναφορά προβλήματος στην ομάδα ανάπτυξης του FreeBSD. + + + + + Dag-Erling + Smørgrav + Γράφτηκε από + + + + + αναφορές προβλημάτων + + + Εισαγωγή + + Μια από τις πιο αποκαρδιωτικές εμπειρίες που μπορεί κάποιος + να έχει σαν χρήστης ενός προγράμματος είναι να στείλει μια + αναφορά προβλήματος μόνο και μόνο για να δει να την κλείνουν + απότομα με μια σύντομη και απότομη εξήγηση όπως π.χ. αυτό + δεν είναι πρόβλημα ή λάθος PR. Κατά + παρόμοιο τρόπο, μια από τις πιο αποκαρδιωτικές εμπειρίες σαν + προγραμματιστής είναι να κατακλύζεται κανείς από αναφορές + προβλημάτων που δεν είναι πραγματικά προβλήματα αλλά αιτήσεις + για βοήθεια και υποστήριξη, ή αναφορές που περιέχουν λίγες ή και + καθόλου πληροφορίες σχετικά με το πρόβλημα και πως μπορεί + κάποιος να το αναπαράγει. + + Αυτό το κείμενο είναι μα προσπάθεια να περιγράψω πως μπορείτε να + γράφετε καλές αναφορές προβλημάτων. Τι είναι, θα με ρωτήσετε, μια καλή + αναφορά προβλήματος; Λοιπόν, για να είμαστε ακριβείς, μια καλή αναφορά + προβλήματος είναι αυτή που μπορεί να αναλυθεί και να την χειριστεί + κάποιος γρήγορα, με αποτέλεσμα την ευχαρίστηση τόσο του αποστολέα όσο + και του προγραμματιστή που την ανέλαβε. + + Παρόλο που το κυριότερο μέρος αυτού του άρθρου αναφέρεται στις + αναφορές προβλημάτων του FreeBSD, τα πιο πολλά από όσα θα πούμε εδώ + ισχύουν και γενικότερα, για πολλά άλλα πράγματα. + + Αυτό το άρθρο είναι οργανωμένο θεματικά κι όχι χρονολογικά, οπότε + είναι πιο σωστό να το διαβάσετε ολόκληρο πριν να στείλετε κάποια αναφορά + προβλήματος, και όχι να το χρησιμοποιήσετε σαν κάποιο βήμα προς βήμα + οδηγό. + + + + Πότε να στείλετε μια αναφορά προβλήματος + + Υπάρχουν πολλοί τύποι προβλημάτων, και δεν αξίζουν όλοι μια αναφορά + προβλήματος. Φυσικά κανείς δεν είναι τέλειος, και θα υπάρξουν φορές που + θα έχετε πειστεί ότι βρήκατε κάποιο πρόβλημα σε ένα πρόγραμμα, όταν στην + πραγματικότητα θα έχετε καταλάβει λάθος τη σύνταξη μιας εντολής ή θα + έχετε κάνει κάποιο τυπογραφικό λάθος σε ένα αρχείο ρυθμίσεων (αν κι αυτό + μερικές φορές είναι ενδεικτικό κακής ή λειψής τεκμηρίωσης ή ακόμα και + κακής διαχείρισης λαθών από κάποια εφαρμογή). Ακόμα, υπάρχουν + περιπτώσεις που το να στείλετε κάποια αναφορά προβλήματος δεν είναι + σωστή κίνηση και το μόνο που μπορεί να πετύχει είναι να ενοχλήσει ή εσάς + ή τους προγραμματιστές. Από την άλλη όμως, υπάρχουν περιπτώσεις που + μπορεί να είναι καλή σκέψη να στείλετε μια αναφορά προβλήματος για κάτι + που δεν είναι bug—μια βελτίωση ή μια αίτηση για κάποιο νέο + χαρακτηριστικό, για παράδειγμα. + + Τότε λοιπόν, πώς μπορείτε να αποφασίσετε αν κάτι είναι πρόβλημα ή + όχι; Ένας απλός κανόνας είναι ότι το πρόβλημά σας + δεν είναι bug αν μπορεί να εκφραστεί σαν ερώτηση + (συνήθως της μορφής Πώς κάνω το Χ; ή Πού μπορώ να + βρω το Ψ;). Δεν είναι πάντα τόσο άσπρο-μαύρο τα πράγματα + βέβαια, αλλά ο κανόνας της ερώτησης καλύπτει την μεγαλύτερη πλειοψηφία + των περιπτώσεων. Αν αυτό που ψάχνετε είναι κάποια απάντηση, ίσως είναι + καλύτερα να στείλετε την ερώτησή σας στην &a.questions;. + + Κάποιες περιπτώσεις που πιθανόν να είναι καλή ιδέα να στείλετε μια + αναφορά προβλήματος για κάτι που δεν είναι bug, είναι: + + + + Αιτήσεις για μελλοντικές βελτιώσεις. Είναι γενικά καλή ιδέα να + δοκιμάσετε να συζητήσετε πρώτα τέτοιες ιδέες σε κάποια λίστα + ηλεκτρονικού ταχυδρομείου πριν στείλετε μια αναφορά + προβλήματος. + + + + Ειδοποίηση για ενημερωμένες εκδόσεις προγραμμάτων (κυρίως ports, + αλλά και μέρη του βασικού συστήματος που συντηρούνται από τρίτους, + όπως το BIND και τα διάφορα GNU εργαλεία). + + + + Κάτι άλλο σημαντικό που πρέπει να δώσετε προσοχή είναι αν το σύστημα + στο οποίο εμφανίζεται το πρόβλημα που σας απασχολεί είναι σχετικά + ενημερωμένο. Πρέπει πάντα να δοκιμάζετε να έχετε ένα όσο το δυνατόν πιο + ενημερωμένο σύστημα και να δοκιμάζετε να αναπαράγετε το πρόβλημα σε ένα + τέτοιο σύστημα πριν να στείλετε μια αναφορά προβλήματος. Υπάρχουν πολύ + λίγα πράγματα που μπορούν να ενοχλήσουν ένα προγραμματιστή περισσότερο + από το να παίρνει μια αναφορά προβλήματος για κάποιο bug που έχει ήδη + διορθωθεί. + + Τέλος, ένα bug που δεν μπορεί κανείς να το αναπαράγει είναι πολύ + δύσκολο να διορθωθεί. Αν το bug εμφανίστηκε μια φορά μόνο και δεν + μπορείτε να το αναπαράγετε εσείς, και φαινομενικά δεν εμφανίζεται σε + κανέναν άλλο, είναι πολύ μικρές οι πιθανότητες να μπορεί κάποιος + προγραμματιστής να το ανακαλύψει και να καταλάβει τί είναι αυτό που + προκαλεί το λάθος. Αυτό δεν σημαίνει πως δεν συμβαίνει, αλλά σημαίνει + πως η πιθανότητα να οδηγήσει η αναφορά σας στην λύση του προβλήματος + είναι πάρα πολύ μικρή, και μάλλον είναι καλύτερο να το παρατήσετε το + θέμα. + + + + Προετοιμασία + + Είναι καλή ιδέα να κάνετε πάντα μια μικρή έρευνα πριν να στείλετε + κάποια αναφορά προβλήματος. Μπορεί το πρόβλημά σας να το έχει ήδη + αναφέρει και κάποιος άλλος. Μπορεί να είναι θέμα συζητήσεων σε κάποια + λίστα ηλεκτρονικού ταχυδρομείου, ή να ήταν πρόσφατα. Μπορεί ακόμα, να + είναι ήδη διορθωμένο το πρόβλημα σε κάποια έκδοση νεώτερη από αυτή που + τρέχετε. Πρέπει λοιπόν να ελέγχετε όλα τα προφανή σημεία, πριν να + στείλετε μια αναφορά προβλήματος. Για το FreeBSD αυτό σημαίνει: + + + + Την + λίστα + με τις πιο συχνές ερωτήσεις (FAQ) για το FreeBSD. + + + + Τις λίστες ηλεκτρονικού ταχυδρομείου. Αν δεν έχετε γραφτεί σε + κάποιες από αυτές χρησιμοποιήστε την μηχανή αναζήτησης στις σελίδες + του FreeBSD. Αν το πρόβλημά σας δεν έχει συζητηθεί ήδη σε κάποια + από τις λίστες, μπορείτε να δοκιμάσετε να στείλετε εσείς κάποιο + σχετικόο μήνυμα και να περιμένετε λίγες μέρες για να δείτε αν + κάποιος μπορεί να σκεφτεί κάτι για να σας βοηθήσει. + + + + Προαιρετικά, όλο το δίκτυο. Χρησιμοποιήστε την αγαπημένη σας + μηχανή αναζήτησης για να βρείτε πληροφορίες σχετικά με το πρόβλημα. + Έτσι μπορεί να βρείτε ακόμη και αναφορές από λίστες ηλεκτρονικού + ταχυδρομείου ή ομάδες συζητήσεων που δεν ξέρατε ότι υπάρχουν ή δεν + σκεφτήκατε να ψάξετε. + + + + Τέλος, μπορείτε να κοιτάξετε την συλλογή αναφορών του FreeBSD. + Αν το πρόβλημά σας δεν είναι πρόσφατο ή αρκετά περίεργο, είναι πολύ + πιθανόν να έχει ήδη στείλει κάποιος άλλος μια αναφορά. + + + + Αφού έχετε κάνει όλα αυτά θα πρέπει να βεβαιωθείτε ότι η αναφορά σας + θα πάει στα κατάλληλα άτομα. + + Η πρώτη παγίδα εδώ είναι ότι αν το πρόβλημα αφορά κάποιο πρόγραμμα + που γράφεται από τρίτους κι όχι την ομάδα ανάπτυξης του FreeBSD (είναι + π.χ. για κάποιο port ή πακέτο που στήσατε), πρέπει να αναφέρετε το + πρόβλημα στον αρχικό συγραφέα του προγράμματος, κι όχι στην ομάδα του + FreeBSD. Υπάρχουν δυο εξαιρέσεις σε αυτόν τον κανόνα. Η πρώτη είναι + όταν το πρόβλημα δεν εμφανίζεται σε άλλες πλατφόρμες, οπότε σε αυτήν την + περίπτωση μπορεί το πρόβλημα να σχετίζεται με τον τρόπο που μεταφέρθηκε + το πρόγραμμα στο FreeBSD. Η δεύτερη περίπτωση είναι όταν ο αρχικός + συγγραφέας έχει ήδη διορθώσει το πρόβλημα και έχει διανείμει κάποιο + patch ή μια νέα έκδοση του προγράμματος, αλλά δεν έχει μεταφερθεί ακόμα + η νέα έκδοση στο FreeBSD. + + Η δεύτερη παγίδα είναι ότι το σύστημα που χρησιμοποιεί η ομάδα του + FreeBSD για να παρακολουθεί και να καταγράφει προβλήματα καταχωρεί τις + αναφορές σε κατηγορίες ανάλογα με τις επιλογές αυτού που στέλνει την + αναφορά. Έτσι, αν διαλέξετε λάθος κατηγορία για την αναφορά σας, + υπάρχει πάντα η πιθανότητα να περάσει απαρατήρητη για κάποιο χρονικό + διάστημα, μέχρι κάποιος να την βάλει στη σωστή κατηγορία + χειροκίνητα. + + + + Γράφοντας αναφορές προβλημάτων + + Τώρα που έχετε αποφασίσει ότι αξίζει να γράψετε κάποια αναφορά + προβλήματος, και ότι όντως είναι κάποιο πρόβλημα του FreeBSD αυτό που + θέλετε να περιγράψετε, είναι ώρα να γράψετε την αναφορά. Βεβαιωθείτε + ότι η μεταβλητή περιβάλλοντος VISUAL + (ή EDITOR αν η μεταβλητή VISUAL δεν έχει + κάποια τιμή) έχει κάποια λογική τιμή, και τρέξτε την εντολή + &man.send-pr.1;. + + + Επισυνάπτοντας patches ή αρχεία + + Το πρόγραμμα &man.send-pr.1; έχει την δυνατότητα να επισυνάψει + αρχεία σε μια αναφορά προβλήματος. Μπορείτε να επισυνάψετε όσα αρχεία + θέλετε, αρκεί το καθένα να έχει μοναδικό βασικό όνομα (το όνομα του + αρχείου χωρίς την διαδρομή). Απλά χρησιμοποιήστε την παράμετρο + στην γραμμή εντολών για να καταδείξετε τα ονόματα + των αρχείων που θέλετε να επισυνάψετε: + + &prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors + + Δεν χρειάζεται να ανησυχείτε για τα αρχεία που δεν είναι κείμενο. + Θα κωδικοποιηθούν κατάλληλα για να μην τα αλλάξει το πρόγραμμα + αποστολής ηλεκτρονικής αλληλογραφίας που χρησιμοποιείτε. + + Αν μαζί με την αναφορά στείλετε και κάποιο patch, φροντίστε να + χρησιμοποιήσετε την επιλογή ή την + στην εντολή &man.diff.1; για να δημιουργήσετε ένα + context ή unified αρχείο διαφορών, και μην ξεχάσετε να σημειώσετε τις + ακριβείς εκδόσεις των αρχείων που αλλάξατε έτσι ώστε οι + προγραμματιστές που θα διαβάσουν την αναφορά σας να μπορούν να κάνουν + τις ίδιες αλλαγές εύκολα. + + Μην ξεχνάτε επίσης ότι, αν δεν το δηλώσετε ρητά στην αναφορά που + θα στείλετε, οποιεσδήποτε αλλαγές στείλετε θεωρείται αυτόματα ότι + είναι διαθέσιμες κάτω από τους ίδιους όρους και με την ίδια άδεια που + έχει η έκδοση του κάθε αρχείου που έχετε τροποποιήσει. + + + + Συμπληρώνοντας την φόρμα της αναφοράς + + Η φόρμα της αναφοράς αποτελείται από μια σειρά πεδίων. Κάποια από + αυτά είναι είναι προσυμπληρωμένα. Κάποια άλλα έχουν σχόλια που + εξηγούν τον σκοπό τους ή αναφέρουν τις αποδεκτές τιμές. Μην + ανησυχείτε για τα σχόλια, αφού έτσι κι αλλιώς θα αφαιρεθούν αυτόματα + αν δεν τα αλλάξετε ή δεν τα σβήσετε. + + Στην κορυφή της φόρμας, κάτω από τις γραμμές που αρχίζουν με + SEND-PR: υπάρχουν οι επικεφαλίδες ενός γράμματος. + Συνήθως δεν χρειάζετε να κάνετε κάποια αλλαγή σε αυτές, εκτός κι αν + στέλνετε την αναφορά από κάποιο μηχάνημα το οποίο μπορεί να στείλει + email αλλά δεν μπορεί να λάβει, που θα πρέπει να προσέξετε οι γραμμές + From: και Reply-To: να έχουν την + πραγματική σας email διεύθυνση. Μπορείτε φυσικα να στείλετε στον + εαυτό σας ή κάποιον άλλο ένα αντίγραφο της αναφοράς προβλήματος + προσθέτοντας τις κατάλληλες Cc: γραμμές. + + Μετά θα δείτε μια σειρά από πεδία μιας γραμμής: + + + + Submitter-Id: Μην το αλλάξετε αυτό. + Η προκαθορισμένη τιμή του, current-users, + είναι σωστή ακόμα κι αν χρησιμοποιείτε την -STABLE έκδοση του + FreeBSD. + + + + Originator: Αυτό το πεδίο είναι κανονικά + προσυμπληρωμένο με το όνομα του τρέχοντος χρήστη. Αν αυτό δεν είναι + σωστό, παρακαλώ συμπληρώστε την τιμή αυτού του πεδίου με το + πραγματικό σας όνομα και προαιρετικά την email διεύθυνσή σας μέσα σε + < και >. + + + + Organization: Αυτό το πεδίο δεν + χρησιμοποιείται για τίποτα σημαντικό. + + + + Confidential: Αυτό το πεδίο είναι + προσυμπληρωμένο με no. Δεν έχει νόημα να το + αλλάξετε σε κάτι άλλο, αφού δεν υπάρχουν εμπιστευτικές αναφορές + προβλημάτων στο FreeBSD—η συλλογή των προβλημάτων είναι + ανοιχτή και διαθέσιμη μέσω CVSup για + όλο τον κόσμο. + + + + Synopsis: Συμπληρώστε αυτό με μια σύντομη + και ακριβή περιγραφή του προβλήματος. Η synopsis χρησιμοποιείται + σαν το θέμα στα email τα σχετικά με την αναφορά, καθώς και σε + λίστες αναφορών και περιλήψεις. Οι αναφορές προβλήματος με + περίεργες περιγραφές στο πεδίο αυτό συνήθως αγνοούνται. + + Αν η αναφορά σας περιλαμβάνει κάποιο patch, είναι καλή ιδέα να + ξεκινήσετε την περιγραφή στο πεδίο Synopsis με + [PATCH]. + + + + Severity: Μπορεί να πάρει τιμή + non-critical, + serious ή + critical. Μην αντιδράτε υπερβολικά. Αποφύγετε + να χαρακτηρίζετε τις αναφορές σας critical + εκτός κι αν είναι όντως μεγάλης σημασίας + (π.χ. root exploit, κάποιο panic που μπορεί + να αναπαραχθεί εύκολα). Οι προγραμματιστές συνήθως δεν δίνουν + σημασία σε αυτό το πεδίο, ακριβώς επειδή αυτοί που στέλνουν τις + αναφορές έχουν την τάση να υπερεκτιμούν τα προβλήματά τους. + + + + Priority: Μπορεί να πάρει τιμή + low, medium ή + high. Δείτε παραπάνω. + + + + Category: Επιλέξτε μια από τις ακόλουθες + κατηγορίες: + + + + advocacy: αναφορές σχετικές με την + δημόσια εικόνα του FreeBSD. Χρησιμοποιείται σπάνια. + + + + alpha: αναφορές σχετικές με την + πλατφόρμα Alpha platform. + + + + bin: αναφορές σχετικές με προγράμματα + στο βασικό σύστημα. + + + + conf: αναφορές σχετικές με αρχεία + ρυθμίσεων, προκαθορισμένες τιμές, κλπ. + + + + docs: αναφορές σχετικές με τις manual + pages ή γενικά την τεκμηρίωση. + + + + gnu: αναφορές σχετικές με προγράμματα + GNU, όπως π.χ. &man.gcc.1; ή &man.grep.1;. + + + + i386: αναφορές σχετικές με την + πλατφόρμα i386 platform. + + + + ia64: αναφορές σχετικές με την + πλατφόρμα ia64. + + + + java: αναφορές σχετικές με την + Java™. + + + + kern: αναφορές για τον πυρήνα. + + + + misc: οτιδήποτε δεν ταιριάζει σε κάποια + από τις υπόλοιπες κατηγορίες. + + + + ports: αναφορές σχετικές με τα + ports. + + + + powerpc: αναφορές σχετικές με την + πλατφόρμα PowerPC. + + + + sparc64: αναφορές σχετικές με την + πλατφόρμα SPARC. + + + + standards: αναφορές σχετικές με την + συμβατότητα με τα διάφορα Πρότυπα. + + + + www: αλλαγές ή βελτιώσεις στην + δικτυακή σελίδα του FreeBSD. + + + + + + Class: Για το πεδίο αυτό, επιλέξτε μια + από τις παρακάτω τιμές: + + + + sw-bug: software bugs. + + + + doc-bug: λάθη στην τεκμηρίωση. + + + + change-request: ιδέες και αιτήσεις για + πρόσθετα χαρακτηριστικά ή αλλαγές σε υπάρχοντα. + + + + update: ενημερώσεις των ports ή άλλων + προγραμμάτων που φτιάχνονται από τρίτους. + + + + maintainer-update: ενημερώσεις σε ports + για τα οποία συντηρείτε εσείς. + + + + + + Release: Η έκδοση του FreeBSD που + χρησιμοποιείτε. Αυτό το πεδίο συμπληρώνεται αυτόματα από την + &man.send-pr.1; και χρειάζεται να το αλλάξετε μόνο στην περίπτωση + που στέλνετε μια αναφορά προβλήματος από άλλο μηχάννημα, κι όχι + από αυτό που έχει το πρόβλημα. + + + + Τέλος, υπάρχει μια σειρά από πεδία με περισσότερες από μια γραμμές + το καθένα: + + + + Environment: Εδώ πρέπει να περιγράφεται, + με όσο το δυνατόν μεγαλύτερη ακρίβεια, το περιβάλλον στο οποίο + παρατηρήσατε το πρόβλημα. Αυτό περιλαμβάνει την έκδοση του + λειτουργικού συστήματος, την έκδοση του συγκεκριμένου προγράμματος + ή αρχείου που έχει το πρόβλημα και οποιαδήποτε άλλα χαρακτηριστικά + από το σύστημα και τις ρυθμίσεις του θεωρείτε σημαντικά, άλλα + εγκατεστημένα προγράμματα που πιστεύετε ότι πιθανόν έχουν σχέση με + το πρόβλημα, κλπ—πολύ απλά, οτιδήποτε χρειάζεται να ξέρει + ένας προγραμματιστής για να εξομοιώσει με ακρίβεια το περιβάλλον + στο οποίο εμφανίζεται το πρόβλημα. + + + + Description: Μια πλήρης και ακριβής + περιγραφή του προβλήματος που αντιμετωπίζετε. Προσπαθείστε να + αποφύγετε εικασίες σχετικά με την αιτία του προβλήματος εκτός κι + αν είστε σίγουροι ότι βρίσκετε σε σωστό δρόμο, καθώς μπορεί να + οδηγήσετε κάποιο προγραμματιστή να κάνει λάθος υποθέτοντας κάποια + πράγματα που δεν είναι σωστά. + + + + How-To-Repeat: Μια περίληψη των ενεργειών + που χρειάζονται για να αναπαράγει κάποιος το πρόβλημα. + + + + Fix: Κατά προτίμηση κάποιο patch ή + τουλάχιστον κάτι που ξεπερνά/αποφεύγει το πρόβλημα (κάτι που όχι + μόνο βοηθά όποιον έχει το ίδιο πρόβλημα να το αποφύγει, αλλά + μπορεί ακόμη και να βοηθήσει κάποιον προγραμματιστή να καταλάβει + την πραγματική αιτία του προβλήματος). Αν δεν έχετε βέβαια κάποια + ιδέα, μπορείτε πάντα να αφήσετε αυτό το πεδίο κενό. Είναι πολύ + καλύτερα από το να κάνετε απλώς εικασίες. + + + + + + Στέλνοντας την αναφορά + + Όταν τελειώσετε με το γράψιμο, την συμπλήρωση της φόρμας, και + σώσετε το κείμενο της αναφοράς σε ένα αρχείο, το πρόγραμμα + &man.send-pr.1; θα σας δείξει μια προτροπή + + s)end, e)dit or a)bort?. Μπορείτε τότε να πατήσετε + s για να συνεχίσετε και να σταλεί η αναφορά, + e για να ξεκινήσετε πάλι τον κειμενογράφο σας, + ή a για να εγκαταλείψετε. Αν επιλέξετε το + τελευταίο, το κείμενο της αναφοράς σας θα παραμείνει στο δίσκο (η + &man.send-pr.1; θα γράψει το όνομα του αρχείου πριν τερματίσει), οπότε + μπορείτε να το επεξεργαστείτε με την ησυχία σας αργότερα, ή να το + μεταφέρετε σε κάποιο σύστημα με καλύτερη σύνδεση δικτύου, πριν να το + στείλετε με την επιλογή της + &man.send-pr.1;: + + &prompt.user; send-pr -f ~/my-problem-report + + Αυτή η εντολή θα διαβάσει μια αναφορά προβλήματος από το αρχείο, + θα κάνει κάποιους ελέγχους στα περιεχόμενα, θα σβήσει τα σχόλια και + στείλει την αναφορά. + + + + + + Απαντήσεις + + Μόλις η αναφορά σας καταχωρηθεί, θα πάρετε μια απάντηση μέσω email + που θα περιλαμβάνει τον αριθμό που έχει σχετιστεί με την αναφορά σας και + μια διεύθυνση URL όπου μπορείτε να διαβάσετε την αναφορά και την + κατάστασή της. Με λίγη τύχη, κάποιος θα ενδιαφερθεί για την αναφορά σας + και θα προσπαθήσει να λύσει το πρόβλημα, ή τουλάχιστον, ανάλογα με την + περίπτωση, να σας εξηγήσει γιατί δεν είναι πρόβλημα. Θα ειδοποιήστε + αυτόματα για κάθε αλλαγή στην κατάσταση της αναφοράς, και θα παίρνετε + αντίγραφα μέσω αλληλογραφίας με οποιαδήποτε σχόλια ή patches στέλνει + κάποιος σαν απάντηση στην αναφορά σας. + + + Αν κάποιος σας ζητήσει επιπλέον πληροφορίες, ή θυμηθείτε κάτι, ή + ανακαλύψετε κάτι που δεν έχετε αναφέρει στην αρχική σας αναφορά, απλώς + στείλτε ένα email στην διεύθυνση bug-followup@FreeBSD.org, + και βεβαιωθείτε ότι ο αριθμός της αναφοράς σας αναφέρεται κάπου στο θέμα + του email ώστε το σύστημα καταγραφής αναφορών να ξέρει σε ποια αναφορά + προβλήματος αντιστοιχεί η απάντησή σας. + + Αν η αναφορά προβλήματος παραμένει στην κατάσταση + open παρόλο που το πρόβλημα έχει σταματήσει να εμφανίζεται + πλέον, απλώς στείλτε μια απάντηση στην αναφορά (με τον τρόπο που αναφέραμε + παραπάνω), εξηγώντας πως ή πότε το πρόβλημα διορθώθηκε. + + + + Αναφορές + + Παρακάτω θα βρείτε κάποιες πηγές που είναι σχετικές με το θέμα των + αναφορών προβλήματος. Δεν είναι μια πλήρης ή επαρκής λίστα, + φυσικά. + + + + + How to Report Bugs Effectively—μια πολύ καλή έκθεση + από τον Simon G. Tatham που περιγράφει πως μπορείτε να γράφετε + χρήσιμες αναφορές προβλήματων (όχι μόνο για το FreeBSD). + + + +