Σελίδα 1 από 1

Ubuntu +1: Testing & Bug Triaging

ΔημοσίευσηΔημοσιεύτηκε: 16 Σεπ 2015, 01:53
από eliasps
Πριν την κυκλοφορία κάθε έκδοσης Ubuntu που φτάνει στους υπολογιστές μας, υπάρχει μία περίοδος ανάπτυξης και ελέγχων αυτής της έκδοσης στο διάστημα που λαμβάνει χώρα από την ημέρα της κυκλοφορίας της προηγούμενης έκδοσης του Ubuntu, μέχρι την ημέρα της κυκλοφορίας της εν λόγω έκδοσης. Όσο βρισκόμαστε χρονικά σε αυτό το διάστημα, δηλαδή πριν την επίσημη ημερομηνία της κυκλοφορίας της έκδοσης, η έκδοση αυτή καλείται «υπό ανάπτυξη». Σε αυτό το διάστημα, πολλοί εθελοντές χρήστες και προγραμματιστές του Ubuntu, εγκαθιστούν αυτή την έκδοση στους υπολογιστές τους και διαρκώς κάνουν ελέγχους και δοκιμές σε διάφορους τομείς που αφορούν την σωστή λειτουργία και σταθερότητα του συστήματος, ώστε να επιβεβαιώσουν πως η έκδοση δεν παρουσιάζει σφάλματα, προκειμένου να είναι έτοιμη για τους τελικούς χρήστες κατά την επίσημη κυκλοφορία της.

Αυτοί οι έλεγχοι που πραγματοποιούνται μέσα σε αυτό το διάστημα έχουν τεράστια σημασία για το μέλλον της έκδοσης, καθώς είναι εκείνοι που επιβεβαιώνουν πως η διανομή είναι κατάλληλη για χρήση. Κατά την διάρκεια αυτών των δοκιμών, η έκδοση ελέγχεται και ανιχνεύονται σφάλματα προκειμένου να διορθωθούν πριν την κυκλοφορία της. Η σημασία αυτής της διαδικασίας είναι τόσο μεγάλη που αποτελεί ένα ξεχωριστό κλάδο μεταξύ των ομάδων του Ubuntu, αυτόν του Testing & Δοκιμών, όπου χιλιάδες χρήστες και προγραμματιστές του Ubuntu επικοινωνούν μεταξύ τους προκειμένου να ανιχνεύσουν, να αναφέρουν, να διορθώσουν και να ελέγξουν σφάλματα που επηρεάζουν την έκδοση.

Σε αυτόν τον οδηγό θα δούμε με ποιους τρόπους μπορούμε να κάνουμε και εμείς δοκιμές στην εκάστοτε υπό ανάπτυξη έκδοση του Ubuntu, ώστε να ανιχνεύσουμε τυχόντα σφάλματα, να τα φέρουμε στην προσοχή των υπευθύνων για να διορθωθούν το συντομότερο δυνατόν και γενικότερα να συνεισφέρουμε σε αυτόν τον τομέα της ανάπτυξης του Ubuntu.


Τρέχουσα υπό ανάπτυξη έκδοση: Ubuntu 17.04 Zesty Zapus




Περιεχόμενα:




Προετοιμασία




Ομάδες QA
Προτού μπούμε σε λεπτομέρειες και προκειμένου να είμαστε συγχρονισμένοι με άλλους χρήστες που ασχολούνται με τους ελέγχους, καθώς και ενημερωμένοι για την τρέχουσα κατάσταση της έκδοσης που ενδιαφερόμαστε να τεστάρουμε, καλό θα ήταν να συμμετάσχουμε σε ομάδες που έχουν δημιουργηθεί για ακριβώς αυτόν τον σκοπό και να χρησιμοποιούμε τα διαθέσιμα μέσα που μας παρέχονται.

Η επίσημη ομάδα ελέγχων και δοκιμών για το Ubuntu είναι η ομάδα “Ubuntu Quality”, η οποία βρίσκεται στο Launchpad. Αυτή η ομάδα διαθέτει και λίστα ηλεκτρονικού ταχυδρομείου στην οποία καλό θα ήταν να εγγραφούμε προκειμένου να συζητάμε με άλλα μέλη της ομάδας τα τρέχοντα ζητήματα που υπάρχουν σχετικά με την υπό ανάπτυξη έκδοση την οποία ελέγχουμε. Υπάρχει επίσης και το κανάλι #ubuntu-quality στο IRC (στον server freenode) στο οποίο τα μέλη μπορούν να επικοινωνούν άμεσα για όποια θέματα αφορούν τις δοκιμές.
Υπάρχει επίσης και η ελληνική ομάδα “Ubuntu Greece-QA”, η οποία βρίσκεται και αυτή στο Launchpad όπου γίνονται συζητήσεις στα ελληνικά σχετικά με σφάλματα και δοκιμές που αφορούν την ελληνική έκδοση, προκειμένου να μεταφερθούν στην επίσημη ομάδα εφόσον επιβεβαιωθούν.



Εγκατάσταση
Αφού γραφτούμε στις παραπάνω ομάδες, πριν μπούμε σε λεπτομέρειες για τους τρόπους με τους οποίους μπορούμε να τεστάρουμε μία υπό ανάπτυξη έκδοση του Ubuntu, θα πρέπει πρώτα να εγκαταστήσουμε την εν λόγω έκδοση στον υπολογιστή μας, είτε σε μία φυσική κατάτμηση του δίσκου μας στον υπολογιστή, είτε σε μία εικονική μηχανή στο VirtualBox.

Αρχικά, πρέπει να βρούμε το αρχείο ISO της έκδοσης του παραγώγου του Ubuntu που θέλουμε να τεστάρουμε. Οι εικόνες της υπό ανάπτυξη έκδοσης των παραγώγων του Ubuntu βρίσκονται εδώ. Για να πραγματοποιήσουμε δοκιμές στην υπό ανάπτυξη έκδοση του Ubuntu, επιλέγουμε είτε την τελευταία εικόνα που έχει δημιουργηθεί (daily-build), είτε την τελευταία εικόνα-ορόσημο που έχει δημιουργηθεί (milestone-release).
Για παράδειγμα, η τελευταία εικόνα του Ubuntu που έχει δημιουργηθεί, βρίσκεται στον φάκελο daily-live/current/, ενώ η τελευταία εικόνα-ορόσημο (alpha, beta κλπ.) θα βρίσκεται στο ubuntu/ΕΚΔΟΣΗ/releases/. Αντίστοιχα, για τα υπόλοιπα παράγωγα του Ubuntu, οι εικόνες τους θα βρίσκονται στις αντίστοιχες διαδρομές μέσα στον φάκελο του εκάστοτε παραγώγου.
Συνήθως επιλέγουμε την τελευταία εικόνα που έχει δημιουργηθεί (daily-build) επειδή περιέχει τις πιο πρόσφατες ενημερώσεις της διανομής όσον αφορά την ανάπτυξή της, και έτσι γνωρίζουμε σίγουρα πως θα εγκαταστήσουμε ένα περιβάλλον κατάλληλο για δοκιμές, συγχρονισμένο με τις τελευταίες εξελίξεις που το αφορούν. Μπορούμε επίσης να βρούμε τους συνδέσμους των ISO που θέλουμε να κατεβάσουμε, μέσω του QA Tracker, ενός συστήματος που δημιουργήθηκε για την αποτελεσματική διαχείριση των δοκιμών, συγκεκριμένα εδώ.

Αφού τελικά βρούμε ποια εικόνα θα χρησιμοποιήσουμε, μπορούμε να να προχωρήσουμε στην εγκατάσταση, είτε σε κάποια φυσική κατάτμηση στον δίσκο του υπολογιστή μας, είτε με την χρήση του Virtual Box, ακολουθώντας την γνωστή διαδικασία της εγκατάστασης. Αφού ολοκληρώσουμε την εγκατάσταση, θα πρέπει να κρατάμε το σύστημά μας ενημερωμένο με τα τελευταία διαθέσιμα πακέτα, με την χρήση της εντολής:
Κώδικας: Επιλογή όλων
sudo apt-get update && sudo apt-get dist-upgrade

Θα πρέπει επίσης να προσέχουμε κατά τη διάρκεια της ενημέρωσης πως δεν αφαιρούνται από το σύστημά μας σημαντικά πακέτα.

Έχουμε ολοκληρώσει την εγκατάσταση της υπό ανάπτυξης έκδοσης και είμαστε έτοιμοι να ξεκινήσουμε τους ελέγχους μας στο Ubuntu! Υπάρχουν διάφοροι τρόποι με τους οποίους μπορούμε να κάνουμε δοκιμές στο σύστημά μας.



Έλεγχος και Δοκιμές




Έλεγχος μέσω εξερεύνησης
Ο απλούστερος τρόπος για να δούμε αν υπάρχουν σφάλματα στην έκδοση, δεν είναι άλλος από το να την χρησιμοποιούμε όπως κάθε άλλη έκδοση και να παρατηρούμε αν όλα λειτουργούν όπως πρέπει. Απλώς χρησιμοποιούμε την διανομή που εγκαταστήσαμε και αν παρατηρήσουμε κάποιο σφάλμα, το αναφέρουμε.



Χειροκίνητος έλεγχος & δοκιμές (QA Tracker)
Προκειμένου να πραγματοποιήσουμε έναν πιο αναλυτικό έλεγχο της έκδοσης μας, θα χρειαστεί να κάνουμε χειροκίνητες δοκιμές. Υπάρχουν τρεις βασικές κατηγορίες δοκιμών στον χειροκίνητο έλεγχο:
  1. Έλεγχος του ISO
  2. Έλεγχος πακέτων
  3. Έλεγχος υλικού
Όπου και στις τρεις θα χρησιμοποιήσουμε το QA Tracker. Το QA Tracker είναι ένα εργαλείο που δημιουργήθηκε με σκοπό την διαχείριση, την οργάνωση, τον συγχρονισμό, την καταγραφή και την παρακολούθηση των ελέγχων και των δοκιμών και των αποτελεσμάτων αυτών, καθώς και την κατηγοριοποίησή τους. Λειτουργεί παρουσιάζοντας μία λίστα από ορόσημα (milestones) που διατίθενται για έλεγχο. Κάθε ορόσημο περιέχει προϊόντα ή πακέτα (products) τα οποία θέλουμε να τεστάρουμε. Κάθε ένα από αυτά τα πακέτα περιέχει μία σειρά από καταγεγραμμένες διαδικασίες ελέγχου (testcases) οι οποίες περιγράφονται βήμα βήμα. Και τέλος, για κάθε μία από αυτές τις διαδικασίες, ο χρήστης που πραγματοποιεί τον έλεγχο είναι σε θέση να δηλώσει το τελικό αποτέλεσμα αυτού ως "pass", πράγμα που σημαίνει πως η διαδικασία ολοκληρώθηκε ασχέτως αν υπήρξαν σφάλματα ή όχι, ή "fail", πράγμα που σημαίνει πως υπήρξαν σφάλματα τόσο σημαντικά που δεν επέτρεψαν στην διαδικασία να ολοκληρωθεί, καθώς και να καταγράψει αυτά τα σφάλματα ή τυχόντα σχόλια που αφορούν τον έλεγχο που πραγματοποιήθηκε.

Υπάρχουν τρεις κατηγορίες του QA Tracker όπου η κάθε μία χρησιμοποιείται για μία από της κατηγορίες δοκιμών που αναφέρθηκαν παραπάνω, αντιστοίχως. Είναι οι:
  1. http://iso.qa.ubuntu.com/: που χρησιμοποιείται για την διεξαγωγή ελέγχων στις εικόνες (ISO) της υπό ανάπτυξη έκδοσης.
  2. http://packages.qa.ubuntu.com/: που χρησιμοποιείται για την διεξαγωγή ελέγχων των πακέτων της υπό ανάπτυξη έκδοσης.
  3. http://laptop.qa.ubuntu.com/: που χρησιμοποιείται για την διεξαγωγή ελέγχων της υπό ανάπτυξη έκδοσης σε υλικό φορητών υπολογιστών.

Στο Video που ακολουθεί θα δούμε μία παρουσίαση του QA Tracker από τον Learner εξηγώντας βήμα βήμα τη διαδικασία που πρέπει να ακολουθήσει κάποιος για να το χρησιμοποιήσει.





Έλεγχος και δοκιμές του Unity 8
Το Unity 8 Desktop Preview είναι το νέο περιβάλλον Unity που τρέχει υπό τον Mir Display Server. Ονομάζεται Preview (Προεπισκόπηση) επειδή πρόκειται ακριβώς για μία προεπισκόπηση τεχνολογίας και σχεδιασμού του Unity 8 υπό τον Mir και όχι για ένα περιβάλλον έτοιμο για γενική χρήση. Υπάρχει για τους προγραμματιστές και για όποιον ενδιαφέρεται να το δοκιμάσει και να ελέγξει πως λειτουργεί το Unity 8.

To Unity 8 Desktop Preview είναι διαθέσιμο είτε ως ένα πρόσθετο πακέτο που υπάρχει σε μία έκδοση του Ubuntu ή σε ένα παράγωγό του, είτε ως ξεχωριστή εικόνα ISO η οποία μπορεί να τρέξει ως Live λειτουργικό χωρίς να επηρεάσει την τρέχουσα εγκατάσταση του υπολογιστή.

Προκειμένου να το δοκιμάσουμε, έχουμε τις εξής επιλογές:
  • Μία επιλογή είναι η εκτέλεση του Unity 8 ως ξεχωριστή συνεδρία χρήστη στην υπάρχουσα εγκατάστασή μας στον υπολογιστή, συνεδρία η οποία θα εγκατασταθεί σε ένα LXC Container ώστε να διατηρηθεί ασφαλής το τρέχον λειτουργικό μας. Προκειμένου να το πετύχουμε αυτό, έχει δημιουργηθεί ένα Project στο Launchpad καθώς και ένα αποθετήριο.
    Όσοι χρήστες χρησιμοποιούν το Ubuntu 14.04 LTS και επιθυμούν να δοκιμάσουν το τελευταίο build του Unity 8 Preview, θα πρέπει να προσθέσουν το παραπάνω αποθετήριο στις πηγές λογισμικού. Το build βρίσκεται ήδη στα αποθετήρια των Ubuntu 15.04 και 15.10 αλλά η εγκατάσταση μέσω του αποθετηρίου διασφαλίζει πως θα έχουμε την τελευταία έκδοση.
    Για να προσθέσουμε το αποθετήριο στο σύστημά μας, στο τερματικό εκτελούμε:
    Κώδικας: Επιλογή όλων
    sudo apt-add-repository ppa:unity8-desktop-session-team/unity8-preview-lxc

    Και προκειμένου να εγκαταστήσουμε το πακέτο, εκτελούμε:
    Κώδικας: Επιλογή όλων
    sudo apt-get update
    sudo apt-get upgrade
    sudo apt-get install unity8-lxc

    Σημείωση: Με αυτές τις εντολές θα εγκατασταθεί και μία ελαφρώς παραμετροποιημένη έκδοση του lightdm που θα επιτρέπει την είσοδο (login) σε LXC Container.
    Μετά την εγκατάσταση των πακέτων, θα πρέπει να κάνουμε επανεκκίνηση. Αφού γίνει η επανεκκίνηση, προκειμένου να γίνει η εγκατάσταση και η σωστές ρυθμίσεις του Unity 8 στο LXC Container, εκτελούμε στο τερματικό:
    Κώδικας: Επιλογή όλων
    sudo unity8-lxc-setup

    Με αυτή την εντολή γίνεται η παραμετροποίηση για το LXC, η λήψη του ISO και η εξαγωγή των περιεχομένων του και γενικότερα όποια απαραίτητη ρύθμιση πρέπει να γίνει προκειμένου να λειτουργήσει σωστά το Unity 8.
    Τέλος, για να χρησιμοποιήσουμε το Unity 8, επιλέγουμε στην οθόνη εισόδου την συνεδρία Unity 8 in LXC, όπως θα κάναμε σε οποιαδήποτε άλλη περίπτωση ύπαρξης δεύτερου περιβάλλοντος.
    Η αναφορά σφαλμάτων αν ακολουθήσουμε αυτή τη διαδικασία γίνεται υπό το πακέτο unity8-lxc
  • H άλλη επιλογή που έχουμε είναι η λήψη (από εδώ) και η εγγραφή της εικόνας του Unity 8 Preview σε ένα USB ή DVD το οποίο θα χρησιμοποιήσουμε για να εκκινήσουμε τον υπολογιστή μας (boot). Τα βήματα που πρέπει να ακολουθήσουμε είναι τα εξής:
    1. Λήψη της εικόνας
    2. Σύνδεση του USB στον υπολογιστή (θα διαγραφούν ότι δεδομένα υπάρχουν σε αυτό)
    3. Άνοιγμα της εφαρμογής “Disks
    4. Επιλογή του USB και κλικ στο εικονίδιο που βρίσκεται δεξιά
    5. Επιλογή “Restore Disk Image
    6. Αναζήτηση και επιλογή της εικόνας ISO που κατεβάσαμε στο βήμα 1
    7. Κλικ στο “Start restoring
    8. Αναμονή για ολοκλήρωση της διαδικασίας
    9. Εκκίνηση του υπολογιστή από το USB και επιλογή “Try Ubuntu
    Αφού ακολουθήσουμε την διαδικασία, δεν θα είμαστε σε θέση να κάνουμε login λόγω ενός bug που επηρεάζει την οθόνη εισόδου.
    Προκειμένου λοιπόν να κάνουμε login:
    1. Μπαίνουμε σε περιβάλλον κονσόλας πατώντας Ctrl + Alt + F1.
    2. Πληκτρολογούμε την εντολή “passwd” και πατάμε ENTER.
    3. Πατάμε ξανά ENTER διότι ο τρέχον κωδικός που θα ζητηθεί είναι κενός.
    4. Πληκτρολογούμε τον νέο κωδικό που επιθυμούμε (2 φορές για επαλήθευση).
    5. Γυρνάμε ξανά στο γραφικό περιβάλλον πατώντας Ctrl + Alt + F7.
    6. Πληκτρολογούμε τον νέο κωδικό που ορίσαμε στο βήμα 4.
    Και θα εισέλθουμε στην συνεδρία του Unity 8 Desktop Preview.
    Η λειτουργία εγκατάστασης λειτουργεί, αλλά δεν υπάρχει ακόμη κάποιος εγκαταστάτης. Επίσης, το Unity 8 δεν μπορεί να λειτουργήσει χωρίς οδηγούς για 3D γραφικά, και για αυτό πιθανότατα μία εγκατάσταση στο Virtual Box δεν θα λειτουργήσει (όμως υπάρχει πιθανότητα να λειτουργήσει στο VMware με 3D οδηγό).
  • Εναλλακτικά, αν ήδη χρησιμοποιούμε κάποια υπό ανάπτυξη έκδοση του Ubuntu, μπορούμε να εγκαταστήσουμε το Unity 8 Desktop Preview απευθείας με την εγκατάσταση του πακέτου unity8-desktop-session-mir και αφού αυτή πραγματοποιηθεί, αποσυνδεόμαστε (logout) από την τρέχουσα συνεδρία και στο LightDM (οθόνη εισόδου) επιλέγουμε να συνδεθούμε στο Unity 8. Τα σφάλματα που αναφέρουμε στο Unity 8 Desktop Preview τα αναφέρουμε υπό το κατάλληλο πακέτο, αλλά σε περίπτωση αμφιβολίας, χρησιμοποιούμε το πακέτο unity8-desktop-session.
Αφού λοιπόν ολοκληρώσουμε την εγκατάσταση του Unity 8 Desktop Preview, μπορούμε να ξεκινήσουμε τις δοκιμές. Συγκεκριμένα ελέγχουμε πράγματα όπως η εγκατάσταση εφαρμογών, η χρήση τους, η γενικότερη λειτουργία τους κλπ.



Bug Triaging




Το bug triaging (έλεγχος και βελτίωση αναφορών σφαλμάτων) είναι η διαδικασία μέσω της οποίας μπορούμε να βελτιώσουμε μία υπάρχουσα αναφορά σφάλματος προκειμένου να περιέχει όλες τις απαραίτητες πληροφορίες ώστε να διευκολύνουμε τους προγραμματιστές να ασχοληθούν και να διορθώσουν το σφάλμα.
Το Ubuntu Project λαμβάνει καθημερινά έναν μεγάλο αριθμό αναφορών σφαλμάτων μέσω του Launchpad. Κάθε μία από αυτές τις αναφορές πρέπει να εξεταστεί, να αξιολογηθεί και να κατηγοριοποιηθεί ώστε να γίνει η διόρθωση του σφάλματος στη συνέχεια. Κάθε αναφορά σφάλματος είναι μία συζήτηση μεταξύ των συμμετεχόντων (προγραμματιστές, testers, χρήστες) και του συγγραφέα της αναφοράς.



Βασικές οδηγίες
Η πρώτη επαφή που έχει συνήθως ο συγγραφέας της αναφοράς με την κοινότητα είναι μέσω ενός bug triager, ο οποίος προσπαθεί να βοηθήσει τον συγγραφέα να βελτιώσει και να ολοκληρώσει την αναφορά του. Είναι πολύ σημαντικό για έναν bug triager να δώσει μία καλή πρώτη εντύπωση, χρησιμοποιώντας φιλικό ύφος και όσο το δυνατόν καλύτερα Αγγλικά. Ένας καλός τρόπος για να ξεκινήσει ένας bug triager και να εξοικειωθεί με την διαδικασία καθώς θα συναντήσει κάθε στάδιο του κύκλου ζωής ενός σφάλματος είναι με τον εντοπισμό untriaged bugs, τα οποία μπορούν να βρεθούν σε αυτόν τον σύνδεσμο. Ουσιαστικά, ψάχνουμε για αναφορές με τα εξής χαρακτηριστικά:
  • Status: New
  • Importance: Undecided
  • Assigned to: Nobody
Περισσότερα για την σημασία και την κατάσταση μίας αναφοράς σφάλματος μπορούμε να διαβάσουμε εδώ. Για να μπορείτε να τα εντοπίσετε ευκολότερα, μπορείτε να:

Ουσιαστικά, για να σημειώσουμε ένα bug ως Triaged, όπου αυτός είναι και ο σκοπός της διαδικασίας του Bug Triaging, πρέπει να ελέγξουμε τις παρακάτω συνθήκες και να επιβεβαιώσουμε πως ΟΛΕΣ έχουν ικανοποιηθεί:
  • Περιγράφει η αναφορά ένα έγκυρο σφάλμα (bug);
  • Περιέχει η αναφορά αρκετές πληροφορίες;
  • Αν το bug μπορεί να διορθωθεί σε μία ημέρα, έχει σημειωθεί πως επηρεάζει το One Hundred Papercuts Project;
  • Αν το σφάλμα αφορά ένα πακέτο του οποίου η διαχείριση γίνεται αλλού, έχει προωθεί το bug εκεί (upstream);
  • Είναι η αναφορά του σφάλματος έτοιμη για να εξεταστεί από κάποιον προγραμματιστή;
Τότε, αλλάζουμε το Status του bug σε "Triaged" και αν δεν έχει γίνει ήδη, ορίζουμε το Importance (σημασία) του bug και αποθηκεύουμε τις αλλαγές ("Save changes").
Προκειμένου να μπορούμε να αλλάξουμε την κατάσταση ενός bug σε Triaged, πρέπει να είμαστε μέλη της ομάδας Ubuntu Bug Control. Αν δεν είστε μέλος και βρείτε μία αναφορά η οποία είναι έτοιμη να σημειωθεί ως Triaged μπορείτε να μπείτε στο κανάλι IRC #ubuntu-bugs στον Freenode και να παραθέσετε τον σύνδεσμο της αναφοράς. Ένα μέλος της ομάδας θα εξετάσει την αναφορά και αν όντως είναι έτοιμη, θα την σημειώσει ως Triaged.

Οι ενέργειες που πραγματοποιούνται από έναν Bug Triager είναι οι εξής:
  • Αλλαγή της κατάστασης (Status) μίας αναφοράς σφάλματος: Σημειώνεται ένα bug ως:
    • New
      • Αυτόματα όταν υποβάλλεται μία αναφορά.
      • Όταν λείπουν πληροφορίες.
      • Πριν αρχίσει το triaging.
    • Incomplete
      • Αν χρειαστεί να ζητήσουμε από τον συγγραφέα επιπλέον πληροφορίες.
    • Opinion
      • Όταν υπάρχει διαφορά απόψεων σχετικά με την αναφορά και συνεχίζονται οι συζητήσεις, αλλά το project ή οι maintainers του πακέτου χρειάζεται να ασχοληθούν με άλλα πιο επείγοντα θέματα και θεωρούν το θέμα λήξαν.
    • Invalid
      • Όταν δεν υπάρχουν αρκετές πληροφορίες για να επιβεβαιωθεί πως πρόκειται για bug.
      • Όταν το πρόβλημα είναι κάτι που προκλήθηκε με ευθύνη του συγγραφέα (πχ φθορά υλικού, κακή χρήση).
      Αυτή η κατάσταση ολοκληρώνει τον κύκλο ζωής της αναφοράς, πράγμα που σημαίνει πως οποιαδήποτε συζήτηση ή δοκιμές από τους προγραμματιστές έχουν σταματήσει να λαμβάνουν μέρος και η αναφορά δεν εμφανίζεται πλέον στις αναζητήσεις, οπότε πρέπει να είμαστε προσεκτικοί και σίγουροι πριν σημειώσουμε ένα bug ως Invalid.
    • Won't Fix
      • Όταν η διόρθωση είναι περίπλοκη ή αμφιλεγόμενη.
      • Όταν οι προγραμματιστές δεν σκοπεύουν να το διορθώσουν προς το παρόν, αλλά ίσως στο μέλλον.
      • Όταν η διόρθωση περιλαμβάνει στοιχεία τα οποία οι προγραμματιστές δεν θέλουν να προσθέσουν.
    • Confirmed
      • Όταν οποιαδήποτε από τις ακόλουθες συνθήκες ικανοποιείται:
        • Υπάρχει κάποιο patch που υποστηρίζεται ότι διορθώνει το σφάλμα.
        • Υπάρχουν αρκετά αρχεία logs και crash dumbs, όπως ορίζονται εδώ.
        • Μπορούμε να αναπαράγουμε το σφάλμα στον υπολογιστή μας.
        • Κάποια άλλη διανομή έχει επιβεβαιώσει το σφάλμα.
        • Ο συγγραφέας του προγράμματος έχει επιβεβαιώσει το σφάλμα.
    • Triaged
      • Όταν ΟΛΕΣ οι συνθήκες που ακολουθούν ικανοποιούνται:
        • Περιγράφει η αναφορά ένα έγκυρο σφάλμα (bug);
        • Περιέχει η αναφορά αρκετές πληροφορίες;
        • Αν το bug μπορεί να διορθωθεί σε μία ημέρα, έχει σημειωθεί πως επηρεάζει το One Hundred Papercuts Project;
        • Αν το σφάλμα αφορά ένα πακέτο του οποίου η διαχείριση γίνεται αλλού, έχει προωθεί το bug εκεί (upstream);
        • Είναι η αναφορά του σφάλματος έτοιμη για να εξεταστεί από κάποιον προγραμματιστή;
    • In Progress
      • Όταν έχετε αναθέσει το bug στον εαυτό σας και πρόκειται να υποβάλετε κάποιο patch για την διόρθωσή του αμέσως.
    • Fix Committed
      • Όταν έχει γίνει η διόρθωση και οι διαδικασίες έχουν δρομολογηθεί για την ενημέρωση του πακέτου.
    • Fix Released
      • Όταν η διορθωμένη έκδοση δημοσιευθεί στο αποθετήριο.
  • Προώθηση αναφοράς σφάλματος upstream: H προώθηση μίας αναφοράς σφάλματος upstream είναι πολύ σημαντική προκειμένου να φέρουμε το σφάλμα στην προσοχή των αρχικών προγραμματιστών του, διαφορετικά ίσως να μην ενημερωθούν για αυτό. Μία αναφορά πρέπει να προωθείται upstream όταν:
    • Η ανάπτυξη του πακέτου που επηρεάζεται από το σφάλμα γίνεται κάπου αλλού και απλά έχει υιοθετηθεί από το Ubuntu.
    • Όταν η αναφορά (στο Ubuntu) έχει γίνει Confirmed ή Triaged.
    • Όταν το πρόβλημα δεν οφείλεται σε πακετάρισμα του προγράμματος στο Debian/Ubuntu.
    Ο Triager που προωθεί μία αναφορά upstream εκπροσωπεί το Ubuntu εκεί. Πρέπει να αναφέρει ποιος είναι ο αρχικός συγγραφέας της αναφοράς και να παραθέσει έναν σύνδεσμο με την αρχική αναφορά του σφάλματος. Είναι χρήσιμο να παρατεθούν σύνδεσμοι με τις πιο σημαντικές επισυνάψεις της αναφοράς και να εξηγηθεί τι είναι αυτές.
    Πριν ο Triager συντάξει μία νέα αναφορά upstream θα πρέπει να ψάξει μήπως το πρόβλημα έχει ήδη αναφερθεί εκεί, ώστε να μην δημιουργήσει κάποιο αντίγραφο. Αν βρεθεί αντίγραφο, τότε πρέπει να δημοσιευθεί ένα σχόλιο με τα στοιχεία της αναφοράς στο Ubuntu.
    Αφού δημιουργηθεί η αναφορά upstream, τότε πρέπει να συνδέσουμε την αναφορά upstream με αυτή στο Ubuntu. Για γίνει αυτό:
    • Κλικ στο "Also affects project".
    • Αναζήτηση και επιλογή του project από την λίστα.
    • Επιλογή του "I have the URL for the upstream bug:" και επικόλληση του συνδέσμου της αναφοράς upstream στο πεδίο.
    • Κλικ "Add to Bug Report".
    Έτσι το Launchpad θα παρακολουθεί την αναφορά upstream και θα ενημερώνει όσους έχουν κάνει subscribe στην αναφορά για αλλαγές στην κατάσταση της upstream αναφοράς.
    Launchpad tracks the upstream bug and warns the subscribers to the Ubuntu bug when the status upstream has been changed.
    Στους παρακάτω συνδέσμους βλέπουμε που γίνονται οι αναφορές σφαλμάτων upstream για τα πιο δημοφιλή projects:
    Αξίζει να σημειωθεί πως αναφορές σφαλμάτων που αποτελούν αιτήματα/προτάσεις για προσθήκη νέων στοιχείων δεν πρέπει να προωθούνται upstream.
    Όταν μία αναφορά χρειάζεται προώθηση upstream καλό είναι να γίνει η προώθηση το συντομότερο δυνατόν. Αν για οποιονδήποτε λόγο αυτό δεν είναι εφικτό, πρέπει να σημειωθεί πως η αναφορά χρειάζεται προώθηση. Για να γίνει αυτό:
    • Κλικ στο "Also affects project".
    • Επιλογή του "I just want to register that it is upstream right now; I don't have any way to link it.".
    • Κλικ στο "Add to Bug Report".
    Οι αναφορές που χρειάζεται να προωθηθούν upstream αλλά ακόμα δεν έχουν προωθηθεί, βρίσκονται εδώ.
  • Σημείωση ως αντίγραφο (duplicate): Αρκετές από τις αναφορές αφορούν σφάλματα τα οποία έχουν ήδη αναφερθεί. Αυτό συνήθως συμβαίνει όταν υπάρχει ένα σφάλμα σε ένα δημοφιλές πακέτο που επηρεάζει πολλούς χρήστες και οι χρήστες που το αναφέρουν δεν έχουν ελέγξει αν έχει ήδη γίνει αναφορά, ή είναι δύσκοΛο να διαπιστωθεί αν το σφάλμα είναι το ίδιο με αυτό μίας άλλης αναφοράς. Είναι σημαντικό να βρίσκονται αναφορές που αφορούν το ίδιο σφάλμα για να υπάρχουν όλες οι πληροφορίες συγκεντρωμένες. Τα σφάλματα είναι ίδια όταν η αιτία που τα προκαλεί είναι η ίδια. Η εύρεσή τους είναι θέμα εμπειρίας σε ένα συγκεκριμένο πακέτο ή σύστημα, διότι τα σφάλματα δεν είναι απαραίτητα ίδια όταν έχουν τις ίδιες συνέπειες. Η αναγνώριση ίδιων σφαλμάτων σε διαφορετικές αναφορές είναι κάτι που πρέπει να γίνεται από τον Triager, ο οποίος πρέπει να ζητά βοήθεια αν έχει αμφιβολίες. Έτσι, όταν ένας Triager εξετάζει μία νέα αναφορά, ψάχνει να βρει αντίγραφα του σφάλματος ακολουθώντας τα εξής βήματα:
    • Κλικ στο "List open bugs" στο κάτω μέρος της σελίδας μίας αναφοράς ή κλικ στην καρτέλα "Bugs" στο πάνω μέρος της σελίδας, ώστε να ανοίξει μία λίστα με αναφορές σφαλμάτων που αφορούν το συγκεκριμένο πακέτο.
    • Αναζήτηση για αναφορές με παρόμοιο τίτλο ή παρόμοια περιγραφή με την αρχική.
    • Αν περιγράφεται η ίδια αιτία για το σφάλμα, αποφασίστε ποια αναφορά θα θέλετε να είναι ως κεντρική για το σφάλμα, κρίνοντας ποια περιέχει τις περισσότερες πληροφορίες και την πιο κατανοητή περιγραφή, και όχι απαραίτητα την παλιότερη.
    • Για την άλλη αναφορά που θα σημειωθεί ως αντίγραφο, πρέπει να γίνει προσθήκη σχολίου προς ενημέρωση των χρηστών.
    • Κλικ στο "Mark as duplicate" και εισαγωγή του αριθμού της αναφοράς που θα θεωρηθεί ως κεντρική για το σφάλμα.

Τύποι αναφορών σφαλμάτων και διαδικασία Bug Triaging:
  • Αναφορές Apport: Eίναι αναφορές που έχουν υποβληθεί με την χρήση του Apport. Αυτός είναι και ο προτεινόμενος τρόπος αναφοράς ενός σφάλματος γιατί συμπεριλαμβάνει στην αναφορά πάρα πολλές πληροφορίες χρήσιμες για τους προγραμματιστές σχετικά με το επηρεαζόμενο σύστημα.
    • Bug Triaging: Όταν έχει γίνει χρήση του Apport, χρειάζονται πολύ λιγότερες πρόσθετες πληροφορίες, πράγμα που σημαίνει πως η διαδικασία βελτίωσης επιταχύνεται σημαντικά. Μπορούμε να αναγνωρίσουμε αυτές τις αναφορές από την λίστα πληροφοριών που συμπεριλαμβάνεται στην περιγραφή του αναφερθέντος σφάλματος ή στις επισυνάψεις.
  • Αναφορές Crash μέσω του Apport: Ένα μεγάλο ποσοστό των αναφορών σφαλμάτων που γίνονται μέσω του Apport αφορούν μη αναμενόμενο τερματισμό (Crash) προγραμμάτων. Αυτά τα σφάλματα αναφέρονται σχεδόν αυτόματα και επεξεργάζονται αυτόματα από bots στο κέντρο δεδομένων της Canonical. Αυτά τα bots δημιουργούν ένα συμβολικό stacktrace και ελέγχουν για αντίγραφα. Αυτά τα bugs σημειώνονται ως "private", δηλαδή μόνο ο συγγραφέας και όσοι έχουν εγγραφεί στις ενημερώσεις μπορούν να το δουν και αυτό γιατί δημιουργούν έναν μεγάλο όγκο ειδοποιήσεων (μέσω e-mail) λόγω της επεξεργασίας που δέχονται από τα bots. Αυτά τα bots εγγράφουν αυτόματα την ομάδα ubuntu-bugcontrol αλλά χωρίς να στέλνουν e-mail στα μέλη της ομάδας.
    • Bug Triaging: Aυτές οι αναφορές διαφέρουν από τις υπόλοιπες σε δύο σημαντικά σημεία:
      1. Πρέπει να ελεγχθούν για το αν περιέχουν ευαίσθητα προσωπικά στοιχεία.
      2. Δεν θα υπάρχει αρχικά ενημέρωση με e-mail μέχρι να σημειωθούν ως "public", ώστε να είναι διαθέσιμα για προβολή σε όλους.
      Ο Triager θα πρέπει να ελέγξει τα παρακάτω:
      • Αν η αναφορά περιέχει επισύναψη του CoreDump.gz τότε είναι αδύνατον να δημιουργηθεί αυτόματα το συμβολικό stack trace και να γίνει έλεγχος για αντίγραφα (duplicates). Σε αυτή την περίπτωση το bug θα έχει tag: apport-failed-retrace. Αν το stack trace έχει δημιουργηθεί σωστά, τότε πρέπει να αφαιρεθεί η επισύναψη CoreDump.gz. Αν το stacktrace έχει αποτύχει να δημιουργηθεί εντελώς, τότε σημειώνουμε το bug ως "Invalid" και ζητάμε από τον συγγραφέα της αναφοράς να αναφέρει ξανά το bug αν μπορεί να αναπαράγει τον μη αναμενόμενο τερματισμό του προγράμματος. Δεν σημειώνουμε ποτέ ένα bug που περιέχει το Coredump.gz ως "Public".
      • Αν δεν υπάρχει καθόλου το Stacktrace.txt στις επισυνάψεις, τότε ο πιο πιθανός λόγος είναι πως η επισύναψη CoreDump.gz είναι χαλασμένη. Σε αυτή την περίπτωση επικοινωνούμε με τον Martin Pitt (pitti στο IRC / e-mail: martin.pitt@ubuntu.com) για τον λόγο επειδή εκείνος μπορεί να ελέγξει τα logs. Ελέγχουμε τα αρχεία stack trace (original stacktraces, Stacktrace.txt (retraced) and ThreadStacktrace.txt (retraced)) για το αν περιέχουν ευαίσθητα προσωπικά δεδομένα. Τέτοια δεδομένα είναι κωδικοί, οτιδήποτε μοιάζει με αριθμούς λογαριασμού τράπεζας, κλειδιά CSS, usernames, ονόματα server κλπ. Αν δεν βρεθεί τίποτα, τότε μπορούμε να σημειώσουμε το bug ως "Public", αν και αυτό δεν απαιτείται, δηλαδή μπορούμε να κρατήσουμε την αναφορά ως "Private" κατά την διάρκεια του κύκλου ζωής του. This is not required though, it is fine to keep the bug private throughout its lifetime. Εκτός από θέματα ιδιωτικότητας, τέτοιες αναφορές πρέπει να θεωρούνται ως κανονικά bugs σε περιπτώσεις αναζήτησης αντιγράφων, προώθηση Upstream κλπ.
  • Επιβεβαιωμένα (Confirmed) bugs: Όταν ένα bug σημειωθεί ως "Confirmed", η διαδικασία της βελτίωσης δεν έχει ολοκληρωθεί πλήρως. Αυτή η αναφορά είναι πολύ κοντά στο να σημειωθεί ως "Triaged", αλλά χρειάζεται να επιβεβαιώσουμε πως είναι έτοιμο για έλεγχο από τους προγραμματιστές.
    • Bug Triaging: Ελέγχουμε τις συνθήκες που αναφέρθηκαν παραπάνω.
  • Αναφορές για προσθήκη στοιχείων (Feature requests): Πρόκειται για αναφορές-αιτήματα-προτάσεις για την δημιουργία νέων στοιχείων σε κάποιο πρόγραμμα.
    • Bug Triaging: Αν μία αναφορά αποτελεί αίτημα για προσθήκη νέων στοιχείων, υπάρχουν δύο πιθανότητες:
      1. Αν η εν λόγω προσθήκη είναι μικρή και περιγράφεται με ακρίβεια ή αυτή η πρόταση αφορά ένα project upstream, η σημασία της αναφοράς (Importance) πρέπει να οριστεί ως "Wishlist". Αν η αναφορά είναι ολοκληρωμένη θα πρέπει να αλλάξουμε και την κατάστασή της (Status) σε "Triaged", όμως όπως είπαμε παραπάνω, μόνο τα μέλη της ομάδας Ubuntu Bug Control μπορούν να το κάνουν αυτό. Έτσι λοιπόν, δίνουμε στο κανάλι #ubuntu-bugs στο IRC τον αριθμό του bug και ενημερώνουμε πως το bug πρέπει να σημειωθεί ως "Wishlist", ώστε κάποιος να το δει και να το σημειώσει. Αν αυτό το αίτημα για προσθήκη νέου στοιχείου αφορά κάποιο upstream project τότε πρέπει να το [url]προωθήσουμε Upstream[/url].
      2. Αν όμως αυτό το αίτημα είναι αόριστο ή απαιτεί μία μεγάλη αλλαγή για να εφαρμοστεί, τότε κλείνουμε το bug σημειώνοντάς το ως "Invalid" δημοσιεύοντας ένα σχόλιο στον συγγραφέα του που τον προωθεί σε κάποιο forum ή upstream. Ένα τέτοιο σχόλιο είναι αυτό:
        Thank you for taking the time to make Ubuntu better. Since what you submitted is not really a bug, or a problem, but rather an idea to improve Ubuntu, you are invited discuss the idea with other Ubuntu community members in the many public forums. Public discussion of ideas improves the likelihood of adoption. Thanks for taking the time to share your opinion!
  • Regressions: Ένα τέτοιο bug δημιουργείται μετά από ενημέρωση ενός πακέτου. Αυτά τα bugs είναι ιδιαίτερα σημαντικά επειδή αν χαλάσει κάτι μετά από αναβάθμιση ενώ λειτουργούσε προηγουμένως, επηρεάζει σημαντικά τους χρήστες του πακέτου. Αυτού του είδους οι αναφορές είναι περισσότερο εμφανείς από τις υπόλοιπες.
    • Bug Triaging: Για να μπορούμε να παρακολουθούμε τέτοιες αναφορές χρησιμοποιούμε tags. Οπότε σιγουρευόμαστε πως χρησιμοποιούμε κάποιο από τα ακόλουθα tags όταν κάνουμε triaging:
      • regression-release: Χρησιμοποιούμε αυτό το tag όταν το bug επηρεάζει την νεότερη σταθερή έκδοση ή την έκδοση υπό ανάπτυξη. Αυτό το bug μπορεί να αφορά ένα απλό πακέτο ή λειτουργία που χάθηκε σε κάποια εφαρμογή.
      • regression-update: Χρησιμοποιούμε αυτό το tag όταν το bug παρουσιάστηκε σε κάποιο ενημερωμένο πακέτο σε σταθερή έκδοση.
      • regression-proposed: Χρησιμοποιούμε αυτό το tag όταν το bug παρουσιάστηκε σε ένα πακέτο στα -proposed.
        Used by the retracer when it finds a bug that has a similar trace to a previously closed bug.
      • regression-retracer: Χρησιμοποιούμε αυτό το tag όταν το bug που παρουσιάστηκε είναι ίδιο με κάποια άλλη αναφορά που έχει κλείσει.
  • Αναφορές που δεν είναι στα Αγγλικά: Πρόκειται για αναφορές γραμμένες σε άλλες γλώσσες εκτός της Αγγλικής.
    • Bug Triaging: Αφού οι αναφορές σφαλμάτων πρέπει να είναι στα Αγγλικά καθώς αυτή είναι η γλώσσα που χρησιμοποιείται από την πλειοψηφία των προγραμματιστών του Ubuntu και των Bug Triagers, θα πρέπει να ζητήσουμε από τον συγγραφέα να την μεταφράσει στα Αγγλικά καθώς και οποιαδήποτε σφάλματα έχουν εμφανιστεί τα οποία δεν είναι στα Αγγλικά. Αν υπάρχει ανησυχία πως το εν λόγω bug είναι ιδιαίτερα κρίσιμο και πρέπει να αντιμετωπιστεί όσο το δυνατόν πιο σύντομα, στέλνουμε e-mail στην λίστα ηλεκτρονικού ταχυδρομείου των Ubuntu translators για να μεταφράσουν την αναφορά.
  • Ειδικές κατηγορίες bugs: Τα περισσότερα bugs αποτελούν ατέλειες στον κώδικα του λογισμικού ή στο πακετάρισμα, αλλά κάποιες ομάδες στο Ubuntu χρησιμοποιούν αναφορές σφαλμάτων και για άλλα πράγματα. Θα πρέπει να προσέχουμε ιδιαίτερα σε αυτές τις κατηγορίες σφαλμάτων για να μην επηρεάσουμε τις διαδικασίες λειτουργίας μίας ομάδας. Αυτές οι κατηγορίες σφαλμάτων έχουν ειδικούς κανόνες και οι καταστάσεις τους (Status) διαφορετικές ερμηνείες, αναλόγως σε ποιο στάδιο ανάπτυξης βρίσκεται η έκδοση.
    • Bugs στην διαδικασία ανάπτυξης: Πρόκειται για αναφορές που σχετίζονται με την διαδικασία ανάπτυξης ενός προγράμματος. Αυτά συνήθως περιέχουν στον τίτλο τους εκφράσεις όπως:
      • Please merge <package> from Debian unstable (main)
      • Please sync <package> from Debian unstable (main)
      • Please remove <package> from the Ubuntu archives
      • Please promote <package> to <component>
      • Please demote <package> to <component>
      • Main inclusion report (MIR)
      Ή έχουν κάποια από τις παρακάτω ομάδες στην λίστα ενημέρωσης:
      • Bug Triaging: Γενικότερα, δεν θα πρέπει να κάνουμε αλλαγές σε τέτοιες αναφορές εκτός αν συνεργαζόμαστε με κάποιον προγραμματιστή ή packager.
    • Αιτήματα δημιουργίας νέων πακέτων: Αυτή η κατηγορία αναφορών δεν πρόκειται για σφάλμα αλλά για αίτημα δημιουργίας νέου πακέτου στο Ubuntu.
      • Bug Triaging: Για τέτοιες αναφορές:
        • Ελέγχουμε αν υπάρχει ήδη το πακέτο στο Ubuntu και αν υπάρχει σημειώνουμε την αναφορά ως "Invalid" και προσθέτουμε σχόλιο εξηγώντας πως το πακέτο υπάρχει ήδη στα αποθετήρια.
        • Αν δεν υπάρχει, τότε ελέγχουμε τα πακέτα του Debian και αν υπάρχει τότε σημειώνουμε και σε αυτή την περίπτωση την αναφορά ως "Invalid" και προσθέτουμε σχόλιο του τύπου:
          Packages for this software appear to exist in Debian already. Ubuntu has semi-automatic tools to sync new packages from Debian so it will most likely appear in the next Ubuntu release.
        • Ελέγχουμε στο Debian bug tracker ή στο Work-Needing and Prospective Packages για αναφορά ITP (Intent To Package) ή RFP (Request For Package) για το πακέτο. Αν βρεθεί τέτοια αναφορά, τότε προσθέτουμε ένα upstream bug προς παρακολούθηση.
        • Στη συνέχεια ελέγχουμε τις άδειες χρήσης upstream. Αν οι πληροφορίες για την άδεια και ο σύνδεσμος για το project (upstream) έχουν συμπεριληφθεί στην αναφορά, προσθέτουμε upstream ένα σχόλιο με τους τύπους των αδειών, αλλιώς αν δεν μπορούμε να βρούμε αυτές τις πληροφορίες, ζητάμε από τον συγγραφέα της αναφοράς να τις προσθέσει.
        • Αφού γίνουν όλα αυτά, σημειώνουμε την αναφορά ως "Triaged" και προσθέτουμε το tag "needs-packaging".
        Μερικές παρατηρήσεις:
        • Η ονομασία ενός πακέτου δεν είναι πάντα ίδια. Μπορούμε να δούμε αν πρόκειται για το ίδιο πακέτο από την περιγραφή του.
        • Ποτέ δεν σημειώνουμε τέτοιες αναφορές ως "Confirmed", εκτός αν μας το έχει ζητήσει κάποιος package maintainer.
        • Τέτοιες αναφορές πρέπει να έχουν κατάσταση "New" ή "Incomplete" μέχρι να ολοκληρωθούν όλα τα προαπαιτούμενα παραπάνω.
        Αν υπάρχουν αμφιβολίας για το αν μία αναφορά ταιριάζει σε κάποια από αυτές τις κατηγορίες, ζητήστε βοήθεια από τα κανάλια IRC #ubuntu-bugs ή #ubuntu-motu.
    • Κενά ασφαλείας: Πρόκειται για bugs που επηρεάζουν την ασφάλεια της έκδοσης. Οι υπεύθυνες ομάδες για τέτοια σφάλματα είναι οι Ubuntu Security και MOTU SWAT και χρησιμοποιούν περίπου ίδιους κανόνες για την διαδικασία του Bug Triaging. If you think a bug may be a security issue or are triaging a bug flagged as a security issue, please be sure to read SecurityTeam/BugTriage before proceeding.
      • Bug Triaging: Αν νομίζετε πως μία αναφορά αποτελεί σφάλμα αυτής της κατηγορίας, δηλαδή πρόκειται για κενό ασφαλείας τότε σημειώνουμε την κατάστασή της (Status) ως εξής:
        • New: όταν πρόκειται για νέα αναφορά.
        • Incomplete: όταν χρειάζονται περισσότερες πληροφορίες από τον συγγραφέα.
        • Confirmed: όταν το bug αποτελεί κενό ασφαλείας. Τέτοια bugs φέρουν συνήθως έναν σύνδεσμο CVE.
        • Triaged: όταν το κενό ασφαλείας είναι κατανοητό και χρειάζεται να εφαρμοστεί κάποιο patch για να το καλύψει. Συνήθως για bugs που βρίσκονται σε αυτή την κατάσταση, υπάρχει κάποιος σύνδεσμος upstream.
        • In Progress: όταν κάποιο patch έχει επισυναφθεί στην αναφορά. Αν οι προγραμματιστές χρειάζονται περισσότερο χρόνο για να αξιολογήσουν το patch, τότε η κατάσταση του bug υποβαθμίζεται σε Triaged και αναβαθμίζεται ξανά σε In Progress όταν το patch αξιολογηθεί.
        • Fix Committed: όταν η διόρθωση βρίσκεται στο αποθετήριο Ubuntu Security ή σε οποιοδήποτε άλλο επίσημο αποθετήριο, σε αναμονή για δημοσίευση.
        • Fix Released: όταν η διόρθωση έχει δημοσιευθεί στο αποθετήριο Ubuntu Security. Τα πακέτα στο main θα έχουν μία σημείωση USN. Συμπεριλαμβάνοντας τον αριθμό της αναφοράς στο αρχείο changelog του κώδικα, αυτόματα η κατάσταση του bug θα σημειωθεί ως Fix Released σε όλες τις εκδόσεις του Ubuntu, εκτός από την υπό ανάπτυξη που θα σημειωθεί ως Fix Released όταν κάποιος από την κοινότητα διορθώσει το πρόβλημα με κάποιο patch.
        • Invalid: όταν το bug δεν επηρεάζει την έκδοση, με την προσθήκη ενός σχολίου του τύπου:
          Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.
    • Αναφορές για σφάλματα στη μετάφραση: Υπάρχει ένα συγκεκριμένο project υπό το οποίο πρέπει αναφέρονται τέτοια σφάλματα, είναι το Ubuntu Translations.
      • Bug Triaging: Τέτοιες αναφορές τις αντιμετωπίζουμε όπως κάθε άλλη αναφορά, ελέγχοντας τις συνθήκες που αναφέρθηκαν παραπάνω. Επίσης προσέχουμε να συμπεριλάβουμε την αναφορά υπό το Ubuntu Translations project και να το αναθέσουμε στη σωστή ομάδα μετάφρασης, το όνομα της οποίας έχεις την μορφή ubuntu-l10n-LC, όπου LC βάζουμε την συντόμευση της γλώσσας (πχ el).
Αν και υπάρχουν αρκετές περισσότερες λεπτομέρειες που αφορούν το Bug Triaging, είναι κυρίως πράγματά που μαθαίνει ένας Bug Triager ξεκινώντας από τα βασικά και αποκτώντας εμπειρία στην συνέχεια.



Αναφορά σφαλμάτων
Οδηγίες στα ελληνικά για το πως κάνουμε αναφορές σφαλμάτων στο Launchpad μπορούμε να διαβάσουμε εδώ.



Χρήσιμοι σύνδεσμοι και πηγές

Ακολουθεί μία λίστα με χρήσιμους συνδέσμους που αφορούν διαδικασίες Testing και Bug Triaging:


Πηγή: https://wiki.ubuntu.com/QATeam



Creative Commons License
Η εργασία υπάγεται στην άδεια Creative Commons Αναφορά-Μη εμπορική χρήση-Παρόμοια διανομή 3.0 Ελλάδα