2011/4/19 Konstantinos Margaritis <markos [ at ] codex [ dot ] gr>: > On Tuesday 19 April 2011 17:38:54 Pantelis Koukousoulas wrote: >> Συγνώμη εκ των προτέρων για το cross-post αλλά το θέμα είναι σχετικό >> και με τις 2 λίστες. > > (ποιες δύο λίστες; :) open-source-el και LGU > πρώτο σχόλιο, καλύτερα να τα διαχωρίσεις αυτά, είναι εντελώς μα εντελώς > άσχετα μεταξύ τους. Η ιδέα είναι να μαζέψω bugs τα οποία έχουν impact σε έλληνες χρήστες αλλά όχι αυτά που είναι γενικά (και άρα έχουν περισσότερες πιθανότητες να διορθωθούν). Επίσης δε με ενδιαφέρουν οι μεταφράσεις και το περιεχόμενο (manpages, tutorials, μαθήματα κλπ) για τη συγκεκριμένη λίστα, μια και γι αυτά υπάρχει πολύ περισσότερος κόσμος που μπορεί να ασχοληθεί. Όταν λες άσχετα μεταξύ τους, σύμφωνα με ποιά κριτήρια; >> Η λίστα αυτή μπορεί να χρησιμοποιείται π.χ., σαν πηγή ιδεών για το με τι >> να ασχοληθεί κανείς σε ένα ελληνικό hackfest, ιδιαίτερα για σχετικά αρχά- >> ριους μια και τα περισσότερα είναι στην κατηγορία των "Easy Hacks". >> >> Προτίθεμαι να ασχοληθώ με την ιεράρχηση / ταξινόμηση, το status tracking >> και τη δημοσίευση ανά μήνα των 10 πιο σημαντικών και των 10 πιο "εύκολων" >> στην επίλυση από αυτά τα bugs. Η "δημοσίευση" θα είναι μέσω του blog >> μου (και κατά συνέπεια μέσω των πλανητών ΕΛΛΑΚ κ Hellug) και μέσω email >> στην LGU ή στην open-source-el εφόσον το να υπάρχει 1 thread ανά μήνα >> αφιερωμένο σε αυτό το σκοπό θεωρείται αποδεκτό. > > δεύτερο σχόλιο, είναι πολύ ασαφές αυτό όπως το διατυπώνεις έτσι. Τι θα πει, > σημαντικά και εύκολα; Ένα πολύ σημαντικό bug, μπορεί να είναι πανεύκολο να > διορθωθεί, ενώ ένα άλλο λιγότερο σημαντικό να θέλει σημαντική εργασία σε > κώδικα. Αναφέρω 3 παραδείγματα: Γι αυτό το λόγο είπα ότι από το σύνολο των bugs που θα λάβω θα ξεχωρίζω 1. Μια λίστα με τα πιο σημαντικά 2. Μια λίστα με τα πιο εύκολα Η ιδέα είναι ότι κάποιος πιο "προχωρημένος" που έχει λίγο χρόνο θα διαλέξει από τη λίστα 1 (με βάση το impact) ενώ ένας πιο αρχάριος από τη λίστα 2 (με βάση την ευκολία υλοποίησης). > 1. προκαθορισμένη επιλογή ελληνικού πληκτρολογίου στα X αναλόγως με το locale, > πανεύκολο -πλέον- απαιτεί 1-2 γραμμές σε κάποιο config file του installer. Αυτό δε μου φαίνεται greek-specific (φαντάζομαι αναφέρεσαι στο debian installer). Φαντάζομαι ότι αν υλοποιηθεί τέτοιος μηχανισμός θα είναι για όλες τις χώρες (locale -> keyboard mapping) έτσι δεν είναι; > 2. Ελληνικά UTF-8 manpages, παλούκι, για πολύ καιρό ήταν αδύνατο, τώρα πλέον > υπάρχει ευτυχώς το groff-utf8, οπότε είναι κάπως πιο εύκολο, αλλά πήρε πολλά > χρόνια να λυθεί το θέμα -δεν ήμασταν οι μόνοι που το ζητούσαμε, και ως συνήθως > δεν ήμασταν εμείς που το λύσαμε. Χεχε, ναι το θυμάμαι από το 2002 περίπου αυτό το θέμα όταν ακόμα χρησιμοποιούσα LFS και είχε κάνει κάποια δουλειά σε αυτό ο Alexander Patrakov. Και πάλι πάντως δε νομίζω ότι θα το συμπεριλάμβανα σε αυτή τη λίστα αφενός γιατί δε νομίζω ότι υπάρχει ιδιαίτερο impact από την έλλειψη ελληνικών manpages και αφετέρου γιατί είναι θέμα περιεχομένου, όχι συγγραφής κώδικα. > 3. Πολύ σημαντικά και ταυτόχρονα πολύ δύσκολο μέχρι πρότινος, σωστά UTF-8 > ελληνικά σε LaTeX. Πλέον το texlive τα υποστηρίζει, αλλά πόσα χρόνια περάσαν > για να γίνει αυτό; Χρειάστηκε να γραφτεί νέο TeX engine (xetex) και αυτό μετά την "αποτυχία" του άλλου TeX engine (omega) αλλά και αυτό θα το ταξινομούσα σαν (major) feature, όχι bug. Το νόημα της συγκεκριμένης λίστας είναι κομμάτια δουλειάς που να μπορούν να χωρέσουν σε 1-3 μέρες δουλειάς με 1-2 ώρες τη μέρα ενασχόληση το πολύ. (Για να έχουμε ένα "working definition" της διαφοράς μεταξύ "bug" και "feature"). Το να γραφτεί ένα καινούργιο tex engine είναι κάτι που απαιτεί χρόνια :) > Τρίτον, είσαι ασαφής στο τι στοχεύεις να καταλογογραφήσεις, ποια διανομή > ακριβώς; Μόνο Linux; Τα *BSD; Άλλα ελεύθερα λειτουργικά (Haiku, κλπ); Ελεύθερο > λογισμικό για MacOS/Windows; Προφανώς δεν σου ζητώ κάτι τέτοιο, αλλά θα πρέπει > να γίνεις λίγο πιο συγκεκριμένος στο τι ζητάς, πχ. να αρχίσεις με > Ubuntu/Debian/Fedora/OpenSUSE και μερικά ακόμη. Και επίσης, ποια έκδοση; > Προφανώς την τελευταία stable, αλλά γιατί όχι και unstable/testing εκδόσεις; Πολύ καλή παρατήρηση. Λοιπόν, σκοπεύω να επικεντρωθώ στο Linux σε πρώτη φάση. Επίσης τα bugs των διανομών καθεαυτών (δηλαδή στα tools της διανομής όπως ο installer ή package manager) δε με απασχολούν. Αν όμως π.χ., το Libreoffice της OpenSuSE έχει ένα patch για καλύτερο conversion των documents με ελληνικούς χαρακτήρες (τυχαίο παράδειγμα, δεν ισχύει κάτι τέτοιο) που το LibreOffice της debian δεν το έχει, αυτό είναι χρήσιμη πληροφορία και θα το συμπεριλάμβανα. Αν κάποια διανομή (π.χ., στυλ Slackware) δεν υποστηρίζει κάποια λειτουργία λόγω "αρχαίας" έκδοσης κάποιου πακέτου αυτό επίσης δεν απασχολεί τη λίστα. Ας αναβαθμίσουν. > Τέταρτον, ένα blog δεν είναι κατάλληλος χώρος για κάτι τέτοιο, imho. Σαν > πρόταση, θα έλεγα ότι ίσως ένας aggregator που να παίρνει bug tracker feeds - > όταν αυτά υπάρχουν- ίσως να είναι καλύτερο, ώστε να έχεις και άμεση ενημέρωση > όταν υπάρχει πρόοδος σε κάποιο bug. Η αξιολόγηση και ιεράρχηση (ώστε να βγουν τα "10 πιο σημαντικά" και τα "10 πιο εύκολα") είναι αναγκαστικά manual και υποκειμενική δουλειά οπότε δε βλέπω πώς θα μπορούσε να γίνει αυτοματοποιημένα όπως προτείνεις. Στα περισσότερα από τα bugs που αφορούν τη λίστα αυτή δεν έχει υπάρξει πρόοδος για χρόνια οπότε το να μην είναι αυτοματοποιημένο το status tracking δεν είναι τόσο σημαντικό πιστεύω (σκέψου ότι θα ασχολούμαι με 20 μόνο κάθε μήνα). Επειδή πιστεύω όμως ότι κάποιοι δε διαβάζουν τους πλανήτες ellak και hellug είπα ότι μπορώ να στέλνω και mail στα σχετικά mailing lists (αν αυτό δεν είναι πρόβλημα για τους διαχειριστές, που δεν πιστεύω να είναι). > Ακόμη ένα σχόλιο, IMHO, θα έπρεπε πρώτα να κάνεις κάποια έρευνα και να πεις > "παιδιά, σκέφτομαι αυτό... και για ξεκίνημα έχω αυτήν την πρώτη λίστα των Χ > bugs για Ubuntu, Y bugs για Debian, κλπ.". Αν υπάρχει ήδη μια βάση, θα δεις > ότι είναι πολύ πιο εύκολο για τους υπόλοιπους να προσθέσουν κάτι -ίσως και μια > online φόρμα να είναι πιο εύκολη λύση από το email. Το "παιδιά σκέφτομαι αυτό..." είναι ακριβώς ο σκοπός του προηγούμενου e-mail. Την αρχική λίστα που λες, πώς θα τη συνέλεγα μόνος μου; Το θέμα είναι να μαζέψω bugs που ενοχλούν "πραγματικούς χρήστες" όχι μόνο εμένα :P Δεν είναι ανάγκη να έχω όλα τα σημαντικά/εύκολα bugs από την πρώτη φορά. Κάποιοι θα στείλουν τώρα, κάποιοι θα προσθέσουν μόλις δουν τα πρώτα αποτελέσματα τον Ιούνιο. Simple as that, δεν υπάρχει βιασύνη :) Νομίζω ότι το email είναι εξίσου ή πιο εύκολο από μια απρόσωπη online φόρμα. Στο κάτω-κάτω τα bugs που έχουν ήδη αρχίσει να μου αποστέλλονται έχουν links σε bugtrackers και αυτή είναι η σωστή "online φόρμα" που πρέπει να χρησιμοποιηθεί. > Όλα τα σχόλια ήταν καλοπροαίρετα και χωρίς πρόθεση να υποβαθμίσω αυτό που > κάνεις. Εννοείται, δεν κατάλαβα κάτι διαφορετικό. Ευχαριστώ πολύ που αφιέρωσες χρόνο για τα σχόλια αυτά :) > Τέλος, θα ήθελα να σου πω ότι η όλη αυτή η ενέργεια που σκοπεύεις να > αφιερώσεις σε αυτό το εγχείρημα, θα ήταν *πολύ* πιο χρήσιμη αν πήγαινε σε > actual bug fixing, αντί δηλαδή για απλή καταγραφή. Προσωπικά δεν το θεωρώ "απλή καταγραφή" από την άποψη ότι θα προσπαθήσω για κάθε bug που θα επιλέξω να προσφέρω και μία "στρατηγική επίλυσης" και κάποια (γιατί όχι) να τα διορθώσω και ο ίδιος. Σκέψου το ως κάτι σαν τη λίστα με τα regressions που στέλνεται κάθε τόσο στο LKML. Είναι κάτι πολύ απλό, το οποίο όμως έχει οδηγήσει σε αρκετά μικρότερο αριθμό σημαντικών regressions από τότε που εφαρμόζεται. Επίσης δες το σαν ένα πείραμα. Μπορεί να δουλέψει μπορεί και όχι, αλλά σίγουρα τουλάχιστον δε βλάπτει κανέναν :) Το actual bug fixing είναι λίγο δύσκολο αν δε γνωρίζουμε το ποια είναι τα "πραγματικά" προβλήματα :) Χαιρετισμούς, Παντελής