έχει νόημα να κάνουμε bug report στην διανομή μας αντί για upstream? [was: καλύτερο bug report για δύσκολο πρόβλημα]

[DJ Art]

On Wednesday 18 June 2008, Nick Demou wrote:

> όπως ανάφερα, δυστυχώς δεν έχω αρκετή εμπειρία για να επικοινωνήσω
> απευθείας με τους developers (ή είμαι υπερβολικά απαιτητικός απο τον
> εαυτό μου). 

Δεν αλλάζει κάτι, bugzilla κι εδώ, bugzilla κι εκεί, τα ίδια πράγματα θα 
αναφέρεις. Ναι, συνήθως είναι χρονοβόρο (αν θες να το κάνεις πραγματικά 
σωστά), αλλά για ένα άρπα κόλα bug report, είναι το ίδιο πράγμα.

> Επιπλέον, ακόμα και αν είμαι τυχερός και οι developers 
> έχουν την διάθεση να με πάρουν απο το χεράκι και να με καθοδηγήσουν,

Αυτό δεν έχει καθόλου πιθανότητες να γίνει. Οι developers συνήθως έχουν 
τόσα πολλά πράγματα να κάνουν που δεν προλαβαίνουν να κάνουν ΚΑΙ 
εκμάθηση στους χρήστες του bugzilla.

> αν το bug είναι στο pidgin γιατί να μην γίνει αυτό που έχω δει σε
> άλλα bugs τα οποία "ανηφορίζουν" upstream μετά απο λίγο χρόνο στο
> launchpad και εν τέλη λύνονται?

Ε, αυτό που λέω λές. Γιατί εξαρχής δεν είχε νόημα να καταχωρηθεί το bug 
στο bugzilla της διανομής, οπότε κάααααποια στιγμή λογικά θα κατέληγε 
upstream.

> Γενικά το downstream bug tracking (μιας διανομής δηλαδή) είναι, από
> όσα καταλαβαίνω, ένα καθαρτήριο/screaning για να μην φτάνουν στους
> developers όλα μα όλα τα bug reports και σε μορφή row material. Μου

όχι, καθόλου. Καθαρτήριο και screaning κάνουν πάντα οι upstream 
developers. Αν γράψεις βλακεία στο bugzilla τους, απλά θα το μαρκάρουν 
invalid και θα προχωρήσουν.

Ούτε χρειαζόμαστε καθαρτήρια γενικά. Το bug reporting μέσω bugzilla 
είναι μια τέτοια διαδικασία που γενικά δε θα κάτσει να την κάνει 
κάποιος που δεν ενδιαφέρεται πραγματικά να βοηθήσει το project. Ή 
κάποιος που δεν αντέχει άλλο με το πρόβλημα, οπότε αποφασίζει να το 
πεί. Αλλά κι αυτή η περίπτωση ανάγεται στην 1η, γιατί όλοι 
αντιλαμβάνονται πως για να λυθεί το πρόβλημά τους θα πρέπει να 
απευθυνθούν ευγενικά και με όσες περισσότερες πληροφορίες γίνεται προς 
τους developers.

> φαίνεται απολύτως λογική προσέγγιση για μια εποχή που οι χρήστες
> linux είναι περισσότεροι αριθμητικά και λιγότερο hackers. Αν δεν

Αυτό δεν αλλάζει καθόλου κάποια κατάσταση. Και πάλι ο αριθμός των 
ανθρώπων που έχει το μεράκι να κάτσει να γράψει ένα bug report 
παραμένει ο ίδιος.

> υπήρχε αυτό η η συνολική ποσότητα των bug reports που φτάνουν στους
> developers θα ήταν πολύ υψηλή ενώ η μέση ποιότητα θα ήταν πολύ
> χαμηλή.

Για κάποιο λόγο, αυτό το φαινόμενο νομίζω πως δεν έχει παρατηρηθεί.

Εξάλλου, σκέψου το από την ανάποδη. Αν ήσουν developer που ασχολείσαι 
(σχεδόν ή εξ ολοκλήρου) full time, θα ήθελες όσο το δυνατόν 
περισσότερος κόσμος να γράφει στο bugzilla σου για να σε βοηθήσει να 
βελτιώσεις την εφαρμογή σου, επωφελούνται και οι 2. Αν τώρα ξαφνικά 
δεχθείς μια πληθώρα από bug reports, αυτό είναι ένα "ευχάριστο" 
πρόβλημα που θα κληθείς ως open source developer να αντιμετωπίσεις (και 
υπάρχουν διάφοροι τρόποι, μην ανησυχείς).

> Πιθανόν να κάνω κάπου λάθος όμως οπότε θα εκτιμήσω πολύ κάθε διόρθωση
> που γίνεται με καλή διάθεση (και κάμποσες που ίσως γίνουν με κακή)

Εν πάσει περιπτώσει. Κάθομαι και τα γράφω όλα αυτά μόνο και μόνο επειδή 
στο subject ζητάς να σου προτείνει κάποιος το βέλτιστο τρόπο να κάνεις 
όσο γίνεται καλύτερο bug report. Και ίσως δεν σου έδωσα μια πλήρη 
εικόνα. Αν εγώ είχα το πρόβλημα που αναφέρεις με την ίδια διανομή, τότε 
θα ακολουθούσα τα εξής βήματα:

1) Για να σιγουρευτώ πως δεν είναι bug που έχει εισάγει ο ubuntu ή ο 
debian packager στο pidgin, θα έκανα compile την τελευταία έκδοση του 
vanilla pidgin. Vanilla σημαίνει πως θα έπαιρνα τον κώδικα από το site 
του pidgin και αυτό θα έκανα compile χωρίς να το patchάρω με τα debian 
specific patches.

2) Θα έτρεχα με το vanilla pidgin για κανα μήνα.

3) Αν τελικά είχα το ίδιο πρόβλημα:

για ποιό λόγο να έχει performance πρόβλημα μια τέτοια χαζούλα εφαρμογή, 
δεν είναι πυρήνας δα. Προφανώς κάπου θα υπάρχει memory leak. Έλα όμως 
που και πάλι, η εφαρμογή δεν είναι και τόσο memory intensive. Εδώ 
υπάρχουν οι εξής περιπτώσεις: 

1) ο αριθμός των protocols.

2) το logging και το history: αυτό είναι πολύ ύποπτο καθώς μετά από 
χρόνια χρήση των chats, τα logs θα παραφουσκώσουν σε μέγεθος και μπορεί 
κάλιστα να μην το έχει προσέξει ο pidgin developer και να παίζει κάποιο 
memory leak

3) Πιθανά άλλα ενεργοποιημένα plugins

Επίσης, θα επαναλάμβανα όλη τη διαδικασία με το latest vanilla Pidgin 
source από το SVN του pidgin.


Αν δεν είχα τελικά το πρόβλημα με το vanilla pidgin:

Εκεί φταίει είτε το ubuntu είτε το debian. Οπότε θα ξεκινούσα από τo 
changelog τους. Αυτό βρίσκεται μέσω του packages.debian.org και το 
packages.ubuntu.com. Μια άλλη καλή ενέργεια είναι και η σύγκριση μεταξύ 
debian pidgin και ubuntu pidgin.

Μια άλλη ύστατη δοκιμή είναι να πάρεις και να βάλεις το pidgin από το 
debian unstable ή από το τρέχον development tree του ubuntu 8.10.
(compile το deb-src πακέτο φυσικά)

Αυτά όλα μπορεί να τείνουν στο να κάνεις τέλεια bug reports, αλλά φυσικά 
απαιτούν πολύ περισσότερο χρόνο, αλλά και τί να κάνουμε, έτσι είναι 
ο "μαγικός" κόσμος του open source .... 

-- 
Thanos Kyritsis <djart at linux.gr>
Q: Εθελοντής ή θεατής ?
A: Ιδιοκτήτης! ;-)