openSUSE:KDE Maintainers Cheat Sheet
Περιεχόμενα
- 1 Πως να γίνετε μέλος της ομάδας KDE του openSUSE
- 1.1 Ασφάλεια
- 1.2 Σφάλματα L3
- 1.3 Ενημερώσεις Έκδοσης
- 1.4 Δοκιμαστική μεταφορά μεταξύ κυρίως εκδόσεων
- 1.5 Χαρακτηριστικά
- 1.6 Μεταφράσεις
- 1.7 Σφάλματα
- 1.8 Πακετάρισμα
- 1.9 Community Building
- 1.10 Testing Builds
- 1.11 Υποστήριξη Χρήστη
- 1.12 Υποστήριξη Προγραμματιστή
- 2 Putting it all together
Πως να γίνετε μέλος της ομάδας KDE του openSUSE
Υπάρχει εδώ μια λίστα από πράγματα που κάνουμε και πηγές σχετικά με το πως τα κάνουμε:
Ασφάλεια
Τα σφάλματα ασφαλείας είναι υψηλής προτεραιότητας για τους υπαλλήλους. Χρησιμοποιήστε το Bugzilla και SWAMP (μόνο εσωτερικά).
Σφάλματα L3
Τα σφάλματα L3 είναι αυτά για τα οποία πληρώνουν οι πελάτες και πρέπει να έχουν γρήγορη αντίδραση. Οι υπάλληλοι χρησιμοποιούν το Bugzilla και προσέχουν για το πρόθεμα "L3". Μέλη της κοινότητας κάνουν πιο ευχάριστα πράγματα.
Ενημερώσεις Έκδοσης
Εκδόσεις KDE
Το openSUSE έχει μια καλή φήμη για την ταχεία παροχή του KDE. Μικρές και μεγάλες εκδόσεις του KDE διαχειρίζονται από ένα μέλος της ομάδας για την αποδοτικότητά τους. Εάν κάνετε αναβαθμίσεις ολόκληρης της έκδοσης KDE (4.5, 4.6 κλπ) βεβαιωθείτε ότι το upstream KDE γνωρίζει για εσάς, έχετε εγγραφεί στη λίστα kde-packager@kde.org και έχετε πρόσβαση στα tarballs για πακετάρισμα. Υποβάλετε σφάλμα sysadmin στο http://bugs.kde.org για να αποκτήσετε αυτή την πρόσβαση. Χρειάζεστε συστάσεις πριν αποκτήσετε πρόσβαση.
Εκδόσεις Εφαρμογών
Οι εφαρμογές εκτός αρθρωμάτων KDE μπορούν να εκδοθούν οποτεδήποτε. Να έχετε το νου σας στις ειδοποιήσεις του Package Warrior για νέες εκδόσεις μέσω ηλεκτρονικής αλληλογραφίας. Νέα πακέτα πρέπει να δημιουργούνται για δημοφιλείς νέες εφαρμογές, παρακολουθείτε την λίστα επιθυμιών πακέτων KDE.
Δοκιμαστική μεταφορά μεταξύ κυρίως εκδόσεων
Το kde4-migrate είναι ένα εργαλείο για αντιγραφή ρυθμίσεων του KDE 3 στο KDE 4. Η μεταφορά ρυθμίσεων απαιτεί δοκιμή επειδή οι εφαρμογές μπορεί να μην υποστηρίζουν κατάλληλα την εισαγωγή των ρυθμίσεων από το KDE 3 (kmail).
Χαρακτηριστικά
Η λίστα των χαρακτηριστικών μπορεί να βρίσκονται στο FATE (εσωτερικό) και στο openFATE. Επίσης να παρακολουθείτε την σελίδα openSUSE Idea Pool.
Μεταφράσεις
Προσπαθούμε να λαμβάνουμε μεταφράσεις upstream. Χαρακτηριστικά που αναπτύσσουμε όπου δεν εφαρμόζονται σε έκδοση upstream μπορεί να απαιτούν μεταφράσεις από το openSUSE. Για να συμβεί αυτό χρειαζόμαστε 1) να κάνουμε μεταφράσιμη τη νέα δουλειά 2) να αντιγράψουμε στην ώρα τους, τα αρχεία .pot στο αποθετήριο προς μετάφραση και 3) να επιστρέψουμε τις αντιγραμμένες μεταφράσεις στο κατάλληλο πακέτο γλώσσας.
Σφάλματα
Το Bugzilla είναι το κύριο εργαλείο σας. Individual team members' reports are easily accessible at hall. Pay attention to bugs.kde.org for applications you specialise in for upstream fixes, and significant bug reports that aren't reported at bnc.
Ταξινόμηση
Εισερχόμενα σφάλματα στο kde-maintainers@suse.de πρέπει να ταξινομούνται. Μπορείτε να παρακολουθείτε οποιονδήποτε λογαριασμό bugzilla στο Novell bugzilla με προσθήκη του στην λίστα στο μενού Ρυθμίσεις->Ρυθμίσεις Ηλεκτρονικής Αλληλογραφίας, στο κάτω μέρος της σελίδας. Για παρακολούθηση αλλαγών στις κοινόχρηστες αναφορές σφαλμάτων, μαζί με όλες τις νέες αναφορές σφαλμάτων του KDE, προσθέστε την λίστα 'kde-maintainers@suse.de'. Για περισσότερες πληροφορίες δείτε openSUSE:Bug_Screening_KDE
Παρακολούθηση
Προσπαθούμε να απαντήσουμε γρήγορα όταν οι χρήστες παρέχουν πληροφορίες που τους ζητήσαμε σε μια αναφορά σφάλματος. Μπορείτε να χρησιμοποιήσετε τις προηγμένες αναζητήσεις στο bugzilla ώστε να αναζητήσετε σφάλματα που υπάρχουν αρκετό καιρό.
Διορθώσεις
Αυτό παίρνει την περισσότερη ώρα μας.
Μείωση Σφαλμάτων
Προσπαθούμε να κάνουμε τακτικές Συνεδρίες Μείωσης Σφαλμάτων ώστε να έχουμε μικρό τον αριθμό σφαλμάτων. Αυτό είναι πάντα καλή ευκαιρία για να βοηθήσετε νέα άτομα να εμπλακούν. Για περισσότερες πληροφορίες δείτε την σελίδα openSUSE:Bug_Squashing_KDE
Πακετάρισμα
Το πακετάρισμα είναι αυτό που κάνει την διανομή.
Συγκεκριμένα χαρακτηριστικά μερικών πακέτων του KDE
Υπάρχουν κάποια πακέτα του KDE, ιδιαίτερα τα kde4-l10n, όπου τα πηγαία αρχεία περιέχουν ένα script με όνομα pre_checkin.sh. Αυτό το script πρέπει να εκτελείται πριν την υποβολή αλλαγών στο OBS. Στην περίπτωση του αρχείου kde4-l10n, το αρχείο kde4-l10n.spec δημιουργείται αυτόματα από το αρχείο kde4-l10n.spec.in .
Ενημερώσεις πακέτων των Patterns
Τα Patterns είναι ομάδες πακέτων που ελέγχουν τι έχει εγκατασταθεί ως προεπιλογή και ποιες ποικίλες επιλογές 'Ανάπτυξης' συμπεριλαμβάνονται.
Αποτυχία Κατασκευής
Τα πακέτα αποτυχαίνουν να κατασκευαστούν για διάφορους λόγους - αλλαγή εξαρτήσεων, αλλαγής μέσα στις εξαρτήσεις, προβληματικοί διακομιστές κατασκευής και αλυσίδας εργαλείων, προβλήματα κατασκευής ιδιαίτερα στις εξωτικές αρχιτεκτονικές. Διαβάστε την αλληλογραφία ειδοποιήσεων αποτυχίας κατασκευής που στάλθηκε προσωπικά σε εσάς και στην ομάδα. Παρακολουθήστε το openSUSE Build Service για αστοχίες στα έργα που συντηρούμε.
Ενημερώσεις από το δίκτυο
Οι κρίσιμες διορθώσεις και οι διορθώσεις ασφαλείας πρέπει να παρέχονται στις εκδόσεις διανομών που κυκλοφορούν. Χρησιμοποιήστε [Fix_Is_Ready:<distro>,...] στο θέμα σφάλματος για να υποδείξετε ότι η διόρθωση εκκρεμεί. Χρησιμοποιήστε SWAMP (εσωτερικό) για να παρακολουθείστε την ροή εργασίας ενός σφάλματος που έχει διορθωθεί μέσω μιας ενημέρωσης από το δίκτυο.
Integration work
Big changes in the distribution platform require adaptation in our packages. These can include things like PackageKit, NetworkManager, ConsoleKit, X, multimedia subsystems. Keep your ear to the ground on opensuse-factory@opensuse.org, research, listen to project managers, and browse FATE so you are not surprised.
Απαιτήσεις πακέτων
Packages often require their build or runtime requirements amending, as the upstream software evolves. Look for build system output warnings that optional dependencies were not found, and add them to the BuildRequires: packages. New runtime requirements are usually expressed as Requires: lines in the specfile for the sub-package containing the code that has the requirement. Eg libbluedevil1 Requires: bluez.
Configuring software
The default configuration for software from upstream may require modifications to meet our needs. For example, by default it may load a plugin that is known to be buggy. We do this by including default configuration in the openSUSE branding package kdebase4-workspace-branding-openSUSE, derived from kdebase4-openSUSE. Note that upstream default configs are in /usr/share/kde4/config/, distribution-added default configs (most of our changes) are in /etc/kde4/share/config and Live media specific configs are in /usr/share/kde4/config/SuSE/default/<filename>.live and are copied into the Live user's .kde4 on login by scripts like /usr/share/opensuse-kiwi/live_user_scripts/kde4.sh.
Updating Visual Identity
Visual Identity refers to the customised look and feel of the distribution, and also to configuration changes.
- kdebase4-openSUSE contains our visual identity
- http://gitorious.org/opensuse/kdebase4-opensuse is the repository
- Do not make changes only to the kdebase4-openSUSE-<version.tar.bz2 in the package, commit them to the git repository then run "sh update_rpm" there to generate the tarball. Otherwise your changes to the tarball will be removed by the next run of the script.
- Remember to update metadata (descriptions, preview images) as well as screenshots. Incomplete list:
- kdm theming: branding/root/usr/share/kde4/apps/kdm/themes/SUSE/
- kde login splash: ksplash/ksplashx-suse/
- default wallpaper: branding/root/usr/share/wallpapers/openSUSEdefault/
- kwin decoration: branding/root/usr/share/kde4/apps/kwin
- plasma theme: branding/root/usr/share/kde4/apps/desktoptheme (as this includes some modifications of upstream default plasma theme files, check for bugfixes to these and apply them to our version)
Licensing and Crypto
As a software distributor, we have to make sure that we follow the licenses and crypto export requirements of the software we distribute and that we declare these licenses correctly in our packages. Expect nastymail if you don't.
Πακετάρισμα άλλων διανομών
Τα πακέτα άλλων διανομών μπορούν να μας εξοικονομήσουν πολύ χρόνο κατά την μεταφορά χαρακτηριστικών ή διορθώσεις σφαλμάτων. Σωστά, Kubuntu; ;)
Pre-release versioning
It is sometimes necessary to change the package version from that provided by upstream. Usually this is because a pre-release tarball is made available named something like kfoobar-4.8.0beta1.tar.bz2. It is a mistake to package this as "kfoobar-4.8.0beta1.rpm" because RPM sees "4.8.0beta1" as newer than "4.8.0", making it impossible to automatically update to the release. We conventionally assign such packages a lower version number as follows:
- x.(y-1).6n - pre-alpha snapshots where n starts at 0 and increases monotonically
- x.(y-1).7n - alpha releases
- x.(y-1).8n - beta releases
- x.(y-1).9n - release candidates
The correct Version for kfoobar above would be 4.7.80. In the specfile, define %rversion for the "real version" given by the tarball:
%define rversion 4.8.0beta1 Name: kfoobar Version: 4.7.80 Source0: %{name}-%{rversion}.tar.bz2
Community Building
Put the 'open' in openSUSE. Befriend a user today, tomorrow she might help triage some bugs, package something in the openSUSE Build Service, or tell you something that will help you find the cause of a bug.
Testing Builds
Both for ourselves and for the rest of the distribution's developers, we try out the latest builds and report the things that don't work.
Υποστήριξη Χρήστη
Ως πεπειραμένοι χρήστες KDE μπορούμε να εντοπίσουμε τις αιτίες του προβλήματος σχετικά εύκολα. Μοιραστείτε την εμπειρία σας στο κανάλι #opensuse-kde.
Υποστήριξη Προγραμματιστή
Υπάρχουν σε διάφορα γραφεία αρκετοί χρήστες KDE με openSUSE, και μερικές φορές αντιμετωπίζουν προβλήματα. Δεν μπορούμε να τους αμελήσουμε αλλά πρέπει να τους βοηθήσουμε.
Putting it all together
Our goal with this page is to make it possible to fulfil the regular tasks as efficiently as possible, leaving as much time for doing amazing new stuff. We have defined the following desirable qualities to do this.
Awareness
It helps if we're all aware of what we're working on despite being in different locations. We are suggesting to send around a weekly mail summarising our activities under the above headings
Fairness
So that all team members get a crack at the fun stuff
Responsiveness
This is only fair to our users who take the time to report things and customers who've paid for it.
Optimisation
Tricks and scripts that you've developed to make things happen quickly deserve to be shared.