openSUSE:Build Service Collaboration

Μετάβαση σε: πλοήγηση, αναζήτηση

Εισαγωγή

Το Open Build Service προσφέρει πολλούς τρόπους συνεργασίας. Ο ευκολότερος είναι να παραχωρήσετε δικαίωμα εγγραφής σε περισσότερους ανθρώπους για ένα πακέτο ή ένα έργο. Αυτός ο τρόπος επιτρέπει σε μια μικρή ομάδα να δουλέψει σε στενή συνεργασία πολύ γρήγορα.

Ωστόσο, αυτή η προσέγγιση δε δουλεύει σε μια σειρά από περιπτώσεις:

  • Άγνωστοι συνεισφέροντες δεν έχουν δικαίωμα εγγραφής και επομένως δεν μπορούν να υποβάλλουν αλλαγές.
  • Η εμπιστοσύνη σε ένα έργο μειώνεται με τον αριθμό των ατόμων που έχουν δικαίωμα εγγραφής.
  • Ακόμα και άτομα με δικαίωμα εγγραφής μπορεί να θέλουν να αναθεωρήσουν τις αλλαγές τους, πριν γίνουν ενεργοί σε ένα έργο.
  • Συνεχείς αλλαγές σε ένα μεγάλο έργο οδηγούν σε καταστάσεις όπου το έργο ποτέ δεν ολοκληρώνει την κατασκευή. Αλλαγές σε βασικά πακέτα μπορούν να εμποδίζουν άλλα πακέτα επ-αόριστον.

Έτσι λοιπόν, το Open Build Service προσφέρει έναν άλλο τρόπο για να γίνονται συνεισφορές. Μπορείτε να ετοιμάσετε αλλαγές σε ένα διακλαδωμένο έργο και μετά να ζητήσετε οι αλλαγές σας να αναμειχθούν με το αρχικό έργο.

Τεράστια έργα, όπως τα KDE, GNOME, Apache, και YaST, συχνά χρειάζονται ένα άλλο στρώμα αναθεώρησης, όπου οι υποβολές μπορούν να περάσουν από κάποια στάδια πριν ενσωματωθούν στο κυρίως έργο. Αυτό εφαρμόζεται και στην περίπτωση του openSUSE:Factory, για παράδειγμα. Αυτό το έργο ορίζει ένα έργο ανάπτυξης για κάθε πακέτο. Το Build Service βοηθά τον χρήστη να αναπτύξει για αυτά τα έργα και να υποβάλλει τις συνεισφορές του εκεί. Οι ιδιοκτήτες έργων των υπό ανάπτυξη έργων μπορούν στη συνέχεια να υποβάλλουν όλες τις συνεισφορές στο openSUSE:Factory. Αυτή η διαδικασία οπτικοποιείται σε αυτές τις διαφάνειες.

Παράδειγμα με το CLI

Το CLI μας (Command Line Client) ονομάζεται "osc". Μπορείτε πάντα να βρείτε μια τωρινή έκδοση στο έργο openSUSE:Tools.

Προσοχή Αυτή η σελίδα περιγράφει το osc UI από την έκδοση 0.119. Παλιότερες εκδόσεις είχαν ελαφρώς διαφορετικές εντολές.

Εδώ είναι ένα άλλο παράδειγμα που αναφέρει τη χρήση του πελάτη ιστού για διαστρωμάτωση, σύνδεση, και aggregating για ένα έργο (PackageKit):


Πως συνεισφέρω τις αλλαγές μου σε κάποιου άλλου τα πακέτα;

Ας πούμε ότι θέλετε να δουλέψετε στο πακέτο openSUSE:Factory/initviocons, και αργότερα να υποβάλετε τη δουλειά σας πίσω στο έργο openSUSE:Factory.

Τα ακόλουθα δείχνουν τι πρέπει να κάνετε, βήμα βήμα.

Δημιουργήστε ένα (Branch) Πακέτο Κλαδί

Πρώτα, δημιουργούμε ένα branch του πακέτου (και του έργου του) που θέλουμε να δουλέψουμε στο προσωπικό μας έργο.

# osc branch <source project> <source package>
osc branch openSUSE:Factory initviocons

Αυτή η εντολή δημιουργεί ένα νέο έργο κάτω από το home:$yourself:branches, το 'έργο branch'. Αυτό το branch έργο έχει την ίδια ρύθμιση κατασκευής με το αρχικό έργο. Η εντολή επίσης δημιουργεί το πακέτο μέσα στο branch ως σύνδεσμο με την πηγή.

Πολλά πακέτα έχουν ορισμένο ένα 'Devel Project'. Σε αυτή την κοινή περίπτωση, ο εξυπηρετητής δημιουργεί ένα σύνδεσμο σε αυτό το devel project αντί για το source project. Το βλέπετε αυτό στην έξοδο της εντολής 'osc branch', κάπως έτσι:

# διακλάδωση ενός πακέτο από το factory το οποίο όμως αναπτύσσεται σε ένα διαφορετικό έργο
osc branch openSUSE:Factory glib2

θα δημιουργήσει το home:$yourself:branches:GNOME:UNSTABLE/glib2.

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

Δουλέψτε σε Αλλαγές

Τώρα που έχετε διακλαδώσει ένα πακέτο, μπορείτε να αρχίσετε να δουλεύετε πάνω του. Οι ακόλουθες εντολές:

osc checkout home:$yourself:branches:openSUSE:Factory/initviocons
cd home:$yourself:branches:openSUSE:Factory/initviocons

κατεβάζουν το πακέτο στο τοπικό σας σύστημα αρχείων. Ο πηγαίος σύνδεσμος επεκτείνεται. Όταν κάνετε branch ένα πακέτο, ένας σύνδεσμος προς το αρχικό δημιουργείται αντί να αντιγράφονται τα πάντα. Με αυτό το σύνδεσμο, το δικό μας branch μένει ενήμερο αν το αρχικό αλλάξει. Για να δουλέψετε πάνω στο branch σας, θέλετε να έχετε πραγματικά πηγαία του πακέτου, όχι ένα απλό _link XML αρχείο. Έτσι εξ ορισμού, το checking out ενός συνδεδεμένου πακέτου /επεκτείνει/ το σύνδεσμο στα περιεχόμενα του αρχικού πακέτου. Συνεπώς παίρνετε τα αρχικά πηγαία συν τις οποιεσδήποτε υπάρχουσες αλλαγές στο checkout.

# τώρα δουλέψτε πάνω σε αυτό
vi ...
osc status
vi ...
osc vc

Οι αλλαγές σας μπορούν να είναι νέα χαρακτηριστικά, διορθώσεις, βελτιώσεις κλπ.

# κατασκευάστε το τοπικά
osc build

Τοπικές κατασκευές βοηθούν στη μείωση των χρόνων απόκρισης καθώς αναπτύσσετε: δε χρειάζεται να περιμένετε το build service να τελειώσει την κατασκευή (ή να αποτύχει την κατασκευή) του πακέτου σας κάθε φορά που κάνετε μια αλλαγή.

Μόλις τελειώσετε, είναι ώρα να ενημερώσετε το Build Service με τις αλλαγές σας:

# υποβάλετε τις αλλαγές
osc commit -m "changed this and that"

Οι αλλαγές σας πηγαίνουν στον εξυπηρετητή, και μια κατασκευή προγραμματίζεται.

Παρόλο που κατεβάσατε επεκταμένες πηγές, δεν υπάρχει ανάγκη να δημιουργήσετε patches για το βασικό πακέτο οι ίδιοι. Το Build Service αναλαμβάνει να τακτοποιήσει το ζήτημα, συγκρίνοντας το δικό σας branch και το αρχικό και δημιουργώντας diffs στο δικό σας (μη επεκταμένο) στο Build Service.


Ύστερα από λίγο μπορείτε να δείτε αν όλα πήγαν καλά με την:

# ελέγξτε αν κατασκευτάζεται
osc results

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

# εμφανίστε διαφορές μεταξύ της δικής σας έκδοσης και του πακέτου στο openSUSE:Factory
osc rdiff home:yourself:branches:openSUSE:Factory initviocons

Αποσφαλματώνοντας την κατασκευή

Το osc build αφήνει κάποια αρχεία στον κατάλογο κατασκευής, κάτι που μπορεί να σας βοηθήσει να διαγνώσετε το πρόβλημα. Η τελευταία δήλωση στην έξοδο από το osc build είναι:

The buildroot was: /var/tmp/build-root

Αν πάτε εκεί, μπορείτε να εξετάσετε τα ακόλουθα αρχεία που μπορεί να σας ενδιαφέρουν:

name meaning
.build.log Εξετάστε την κατασκευή και αναγνωρίστε το σφάλμα
.build.command Η εντολή που χρησιμοποιήθηκε για την πραγματική κατασκευή
.build.packages Ο κατάλογος όπου βρίσκονται τα αντικείμενα αρχεία

Αν η κατασκευή αποτύχει, μπορεί να μπείτε στον πειρασμό να φτιάξετε κάτι στον κατάλογο κατασκευής αυτό στην πραγματικότητα δεν είναι καλή ιδέα γιατί η εντολή osc build συνήθως διαγράφει τα πάντα εκεί μέσα ( rm -rf ) και επανεκκινεί από το μηδέν. Αυτή η στρατηγική δυστυχώς δεν είναι βιώσιμη για αυξανόμενες αλλαγές: αν η κατασκευή απαιτεί πολύ χρόνο, που μάλλον είναι και το πιο πιθανό για μεγάλα έργα. Για να αντιμετωπίσετε αυτό το πρόβλημα, δείτε στο αρχείο .build.command: συνήθως περιέχει μια γραμμή του τύπου

rpmbuild -ba package.spec

Αυτή η εντολή θα πετάξει όλα όσα έχετε κατασκευάσει, έτσι δεν είναι ούτε αυτή χρήσιμη. Ωστόσο, αυτή η εντολή είναι πιθανόν να συνεχίσει την κατασκευή:

rpmbuild -bc --short-circuit package.spec #compile
rpmbuild -bi --short-circuit package.spec #install

Αυτές οι επιλογές εξηγούνται λεπτομερώς στον Fedora RPM Guide.

Υποβάλετε τις αλλαγές σας για να αναμειχθούν

Προσοχή Αυτό το χαρακτηριστικό δεν είναι προς το παρόν υλοποιημένο για παγωμένα έργα όπως τα openSUSE:11.0, Fedora:9 ή το :Update. Αυτό απαιτεί αλλαγές στο χειρισμό της συντήρησης που θα έρθουν αργότερα :)

Μόλις είστε ικανοποιημένοι και πιστεύετε ότι οι αλλαγές σας έχουν μια καλή πιθανότητα να γίνουν αποδεκτές από τους συντηρητές του upstream έργου – αυτό είναι, αν χρησιμοποιείτε τα παραδείγματα οπουδήποτε σε αυτό το έγγραφο, από τους συντηρητές του openSUSE:Factory έργου -- μπορείτε να προχωρήσετε και να ζητήσετε μια υποβολή.

osc submitrequest -m 'version update to 3.3'

Αυτό υποβάλλει τις αλλαγές του πακέτου στο τοπικό αντίγραφο του έργου που ορίζεται στο σύνδεσμο της πηγής.

Μπορείτε επίσης να το κάνετε χωρίς ένα κατεβασμένο αντίγραφο καλώντας

osc submitrequest home:$yourself:branches:openSUSE:Factory initviocons openSUSE:Factory -m 'version update to 3.3'

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

Πως διαχειρίζεται η συνεισφορά μου;

Ο συντηρητής ενός έργου (όπως το openSUSE:Factory) υποτίθεται ότι ψάχνει για συνεισφορές (π.χ. Για αιτήσεις υποβολής) κάπως έτσι:


 % osc request list openSUSE:Factory
37   new         home:poeml/initviocons  ->  openSUSE:Factory/initviocons    'version update to 3.3'


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

 % osc request show -d 37
Request to submit (id 37): 

    home:poeml/initviocons  ->  openSUSE:Factory/initviocons

Source revision MD5:
    f839321325a0b5582def283c3520bf13

Message:
    'version update to 3.3'

State:   new          2008-03-20T19:57:02 poeml



changes files:
--------------
--- initviocons.changes
--- initviocons.changes
@@ -20 +20 @@
-    which sends a characteristic primary da
+    which sends a characteristic primary DA
[...]


Μετά από αυτό, ο συντηρητής μπορεί να αποδεχθεί την υποβολή:

osc request accept 37

Ή να την απορρίψει, με κάποια αιτιολόγηση:

osc request decline -m "changelog missing, but required by policy" 37

Παράδειγμα με τη διεπαφή ιστού

Αυτό περιγράφει πως να αλλάξετε πηγαία μέσω της διεπαφής ιστού, μπορείτε να τα βρείτε για το openSUSE στο http://build.opensuse.org.

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

Πως συνεισφέρω τις αλλαγές μου στο πακέτο κάποιου άλλου;

Έστω ότι θέλετε να δουλέψετε στο πακέτο openSUSE:Factory/initviocons, και αργότερα να υποβάλετε τη δουλειά σας πίσω στο έργο openSUSE:Factory.

Τα ακόλουθα δείχνουν τι πρέπει να κάνετε, βήμα βήμα.

Δημιουργήστε ένα (Branch) Πακέτο Κλαδί

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

Το branch πάντα ενημερώνεται με αλλαγές από το αρχικό πακέτο, από όπου προήλθε..

Για το openSUSE:Factory πηγαίνετε στη λίστα με τα πακέτα και βρείτε το πακέτο σας.

Δημιουργήστε ένα Branch Έργο

Πρώτα, δημιουργούμε ένα branch του πακέτου (και του έργου στο οποίο ανήκει) στο οποίο θέλουμε να δουλέψουμε στο προσωπικό μας έργο. Κλικ στο μενού "Actions" και μετά στο "Branch package".

Αυτός ο εξυπηρετητής δημιουργεί ένα νέο έργο κάτω από το home:$yourself:branches, το branch έργο. Αυτό το branch έργο έχει το ίδιο στήσιμο κατασκευής με το αυθεντικό αρχικό έργο. Η εντολή επίσης δημιουργεί το πακέτο μέσα στο branch ως μια συνδεδεμένη πηγή.

Πολλά πακέτα έχουν ορισμένο ένα 'Devel Project'. Σε αυτή την κοινή περίπτωση, ο εξυπηρετητής δημιουργεί ένα σύνδεσμο σε αυτό το devel project αντί για το source project. Το βλέπετε αυτό στην έξοδο της εντολής 'osc branch', κάπως έτσι:

Δουλέψτε σε Αλλαγές

Κλικ στην καρτέλα "source files" και επεξεργαστείτε τα πηγαία σας κατά το δοκούν. Θα πρέπει να περιμένετε και να δείτε αν κατασκευάζονται πραγματικά.

Ενδεχομένως να θέλετε να κατεβάσετε τα πακέτα και να δοκιμάσατε αν οι αλλαγές σας πραγματικά κάνουν κάποια διαφορά κατά την εκτέλεση.

Υποβάλετε τις αλλαγές σας για να αναμειχθούν

Προσοχή Αυτό το χαρακτηριστικό δεν είναι προς το παρόν υλοποιημένο για παγωμένα έργα όπως τα openSUSE:11.0, Fedora:9 ή το :Update. Αυτό απαιτεί αλλαγές στο χειρισμό της συντήρησης που θα έρθουν αργότερα :)

Μόλις είστε ικανοποιημένοι και πιστεύετε ότι οι αλλαγές σας έχουν μια καλή πιθανότητα να γίνουν αποδεκτές από τους συντηρητές του upstream έργου – αυτό είναι, αν χρησιμοποιείτε τα παραδείγματα οπουδήποτε σε αυτό το έγγραφο, από τους συντηρητές του openSUSE:Factory έργου -- μπορείτε να προχωρήσετε και να ζητήσετε μια υποβολή.

Μπορείτε είτε να υποβάλετε μια αίτηση υποβολής μέσω του μενού "Actions" ή να βρείτε το σύνδεσμο "show diff and submit these changes back" στη σελίδα "Source Files".

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


Ειδικός χειρισμός για το openSUSE:Factory

Κάθε πακέτο στο openSUSE:Factory έχει ένα “αποθετήριο ανάπτυξης”. Αυτά τα αποθετήρια ανάπτυξης χρησιμοποιούνται για ανάπτυξη του ίδιου του πακέτου. (Μπορείτε να “δείτε” το develproject ενός πακέτου μέσω του osc meta pkg openSUSE:Factory <package> | grep devel.) Αν κάνετε ένα osc branch openSUSE:Factory <package> μην εκπλαγείτε αν πάρετε το πακέτο από κάποια άλλη τοποθεσία αν θελήσετε να κάνετε αλλαγές για ένα πακέτο στο openSUSE:Factory.

Για να κάνετε μια submitrequest στο openSUSE Factory (Σημείωση: η αποδοχή ενός submitrequest στο έργο ανάπτυξης δεν πυροδοτεί μια submitrequest για το Factory αυτόματα!), ένας συντηρητής του Devel-Project πρέπει να κάνει κάτι σαν:

       osc sr -m "- updated package, thanks to foo bar" <devel:project> <package> openSUSE:Factory

Έτσι έχουμε δυο σενάρια εδώ:

Το Branch, η ροή εργασιών ενός ανεπίσημου συντηρητή Έργου Ανάπτυξης

  1. osc branch openSUSE:Factory <package>
  2. osc submitrequest (στέλνει μια submitrequest στο devel project)
  3. Ο συντηρητής του Devel-Project αποδέχεται μέσω του osc sr accept <id>
  4. Ο συντηρητής του Devel-Project δημιουργεί μια νέα submitrequest στο Factory
  5. Οι άνθρωποι του Autobuild αποδέχονται την αλλαγή

Η ροή εργασιών ενός συντηρητής Έργου Ανάπτυξης

  1. Ο συντηρητής του Devel-Project δημιουργεί μια νέα submitrequest για το Factory
  2. Οι άνθρωποι του autobuild (openSUSE:Factory team) αποδέχονται την αλλαγή
Έτσι για συντηρητές Devel Project, είναι πάντα μια καλή ιδέα να ρυθμίσουν τις ειδοποιήσεις τους στον Ερμή για να ενημερώνονται σχετικά με με τα έργα τους και/ή να ελέγχουν για submitrequests στα δικά τους έργα μέσω του
osc request list <devel:project>