openSUSE:Build Service Współpraca
Spis treści
Wprowadzenie
Usługa Open Build oferuje różne sposoby współpracy. Najprostszym sposobem jest przyznanie dostępu do zapisu większej liczbie osób w pakiecie lub projekcie. W ten sposób niewielki zespół blisko współpracujący może bardzo szybko współpracować.
Jednak takie podejście nie działa w wielu przypadkach:
- Nieznani współtwórcy nie mają dostępu do zapisu i dlatego nie mogą przesyłać zmian.
- Zaufanie do projektu zmniejsza się wraz z liczbą osób, które mają dostęp do zapisu.
- Nawet osoby z dostępem do zapisu mogą chcieć zapoznać się ze swoimi zmianami, zanim staną się aktywne w projekcie.
- Ciągłe zmiany w dużym projekcie prowadzą do sytuacji, w której projekt nigdy się nie kończy. Zmiany w pakietach podstawowych mogą blokować inne pakiety na czas nieokreślony.
Dlatego usługa Open Build oferuje inny sposób wnoszenia wkładów. Możesz przygotować zmiany w rozgałęzionym projekcie, a następnie poprosić o scalenie zmian.
Duże projekty, takie jak KDE, GNOME, Apache i YaST, często wymagają kolejnej warstwy recenzji, w której zgłoszenia można przesuwać przed zalogowaniem do głównego projektu. Tak jest na przykład w przypadku openSUSE: Factory. Ten projekt definiuje projekt rozwoju dla każdego pakietu. Usługa Open Build pomaga użytkownikowi opracowywać projekty w oparciu o te projekty i przesyłać tam swoje uwagi. Właściciele projektu deweloperskiego mogą następnie przesłać wszystkie wkłady do openSUSE: Factory. Ten proces jest wizualizowany na tych slajdach.
Przykład z CLI
Nasz CLI (klient wiersza poleceń) nosi nazwę osc (zainstaluj go za pomocą sudo zypper install osc).
Oto kolejny przykład wzmianka o korzystaniu z klienta WWW, warstwowaniu, łączeniu, łataniu i agregowaniu dla jednego projektu (PackageKit):
Jak mogę dodać swoje zmiany do pakietów innej osoby?
Powiedzmy, że chcesz pracować nad pakietem openSUSE: Factory / initviocons, a później prześlij swoją pracę z powrotem do projektu openSUSE: Factory.
Poniżej pokazano, co robić krok po kroku.
Utwórz gałąź pakietu
Najpierw tworzymy gałąź pakietu, nad którym chcemy pracować w naszym projekcie domowym.
# gałąź osc <projekt źródłowy> <pakiet źródłowy> osc branch openSUSE:Factory initviocons
To polecenie najpierw tworzy nową osobistą 'gałąź projektu' w folderze home:$yourself:branches, jeśli jeszcze nie istnieje. Ta gałąź projektu ma taką samą konfigurację kompilacji jak oryginalny projekt źródłowy. Następnie polecenie tworzy również pakiet wewnątrz gałęzi jako łącze źródłowe.
Wiele pakietów ma zdefiniowany 'Projekt Devel (Devel Project)'. W takim typowym przypadku serwer tworzy link do tego projektu deweloperskiego zamiast projektu źródłowego. Widać to w danych wyjściowych 'gałęzi osc', takich jak to:
# tworzenie gałęzi paczki z factory, ale która została opracowana w innym projekcie osc branch openSUSE:Factory glib2
stworzy home:$yourself:branches:GNOME:UNSTABLE/glib2.
To gwarantuje, że twoje zmiany będą zgodne z istniejącym przepływem zmian do prawdziwego domu pakietu.
Praca nad zmianami
Teraz, gdy masz już rozgałęziony pakiet, możesz zacząć nad nim pracować. Następujące polecenia:
osc checkout home:$yourself:branches:openSUSE:Factory initviocons cd home:$yourself:branches:openSUSE:Factory/initviocons
pobierze pakiet do lokalnego systemu plików. Link źródłowy jest rozwinięty. Podczas tworzenia gałęzi paczki zamiast kopiowania wszystkiego tworzony jest link do oryginału. Dzięki temu linkowi nasza gałąź będzie aktualizowana na bieżąco, jeśli zmieni się oryginał. Aby pracować w gałęzi, potrzebujesz prawdziwych źródeł pakietów, a nie pliku _link XML . Tak więc domyślnie sprawdzenie połączonego pakietu rozszerza link do zawartości oryginalnego pakietu. Otrzymujesz zatem oryginalne źródła/pliki oraz wszelkie istniejące zmiany w czsie sprawdzania.
Teraz przygotuj zmiany. Jeśli pliki źródłowe nie znajdują się w archiwum .tar.gz, po prostu edytuj je:
vim <ścieżka/do/pliku> ... osc diff ...
Jeśli pliki źródłowe znajdują się w archiwum .tar.gz, musisz zrobić to nieco inaczej. Przygotuj łatkę za pomocą quilt (zainstaluj ją za pomocą polecennia sudo zypper install quilt):
# Rozpakuj archiwum .tar.gz quilt setup <nazwa pakietu>.spec cd <nazwa numeru wersji pakietu> # Utwórz plik łatki, aby zachować zmiany quilt new <żądana nazwa twojej łatki>.patch # Edytuj pliki # Opcja 1: quilt edit <ścieżka/do/pliku> # Opcja 2: quilt add <ścieżka/do/pliku> <edytuj plik w wybranym edytorze> # Podaj jasny opis łatki quilt header -e # Uzupełnij plik łatki, gdy skończysz edytować wszystko quilt refresh # Zintegruj łatkę w pakiecie cp patches/<nazwa twojek łatki>.patch .. cd .. /usr/lib/build/spec_add_patch <nazwa twojek łatki>.patch # Dodaj swoją łatkę do repozytorium osc add <nazwa twojek łatki>.patch
Teraz podaj jasny opis zmiany, wspominając o błędzie w tym formacie: "(bsc#<numer błędu>)"
osc vc
Wykonaj lokalnie testową kompilację, aby upewnić się, że wszystko działa:
osc build
Lokalne kompilacje pomagają skrócić czas realizacji podczas rozwoju; nie trzeba czekać, aż usługa Open Build Service zakończy budowanie (lub niepowodzenia kompilacji) pakietu za każdym razem, gdy wprowadzasz zmiany.
Po skompilowaniu pakietu zmian lokalnie nadszedł czas, aby poinformować usługę Open Build Service o swoich zmianach:
# zatwierdzić zmiany (commit) osc commit -m "zmieniłem to i tamto"
Zmiany zostaną wprowadzone na serwer i zaplanowana jest kompilacja.
Mimo że sprawdziłeś rozszerzone źródła, nie musisz samodzielnie tworzyć łatek dla pakietu podstawowego. Usługa Open Build zajmuje się tym wszystkim, porównując twoją gałąź i oryginał oraz tworząc różnice w (nierozwiniętej) w Open Build Service.
Po chwili możesz sprawdzić, czy wszystko się udało:
# sprawdź, czy się buduje osc results
Czasami będziesz chciał zobaczyć, jak Twoja praca różni się od oryginalnego pakietu. Możesz na przykład omówić swoje zmiany z kimś innym lub po prostu zobaczyć, co robią inni programiści w tym samym czasie. Aby to zrobić, użyj:
# pokaż różnice między wersją a wersją w openSUSE:Factory osc rdiff home:yourself:branches:openSUSE:Factory initviocons
Debugowanie kompilacji
osc build pozostawia niektóre pliki w katalogu kompilacji, które mogą pomóc w zdiagnozowaniu problemu. Ostatnia instrukcja wyrażona przez osc build to:
The buildroot was: /var/tmp/build-root
Jeśli tam przejdziesz, możesz sprawdzić następujące interesujące pliki:
| nazwa | znaczenie |
|---|---|
| .build.log | Sprawdź kompilację i zidentyfikuj błąd |
| .build.command | Komenda która służyła do aktualnej kompilacji |
| .build.packages | Katalog, w którym znajdują się pliki obiektowe |
Jeśli kompilacja się nie powiedzie, może pojawić się pokusa, aby spróbować naprawić coś w katalogu kompilacji; zazwyczaj nie jest to dobry pomysł, ponieważ polecenie osc build zwykle odrzuca wszystko ( rm -rf ) i uruchamia się od nowa. Ta strategia niestety nie jest wykonalna w przypadku zmian przyrostowych: jeśli kompilacja zajmuje dużo czasu, co jest całkiem prawdopodobne w przypadku dużych projektów. Aby obejść ten problem, spójrz na plik .build.command; zwykle zawiera wiersz w formie
rpmbuild -ba package.spec
To polecenie odrzuci wszystko, co zbudowałeś, więc nie ma sensu. Jednak to polecenie prawdopodobnie wznowi kompilację:
rpmbuild -bc --short-circuit package.spec #kompilacja rpmbuild -bi --short-circuit package.spec #instalacja
Opcje te zostały szczegółowo wyjaśnione w Fedora RPM Guide.
Prześlij zmiany do scalenia
Once you are satisfied and believe that your changes have a good chance of being accepted by the maintainers of the upstream project -- that is, if you are using the examples elsewhere in this document, by the maintainers of the openSUSE:Factory project -- you can go ahead and request a submit.
Gdy będziesz zadowolony i wierzysz, że Twoje zmiany mają duże szanse na zaakceptowanie przez opiekunów projektu głównego - to znaczy, jeśli korzystasz z przykładów w innym miejscu tego dokumentu, przez opiekunów projektu openSUSE:Factory - możesz śmiało poprosić o przesłanie.
osc submitrequest -m 'akatualizacja do wersji 3.3'
Spowoduje to przesłanie zmian pakietu w lokalnej kopii roboczej do projektu zdefiniowanego w łączu źródłowym.
Możesz to również zrobić bez sprawdzonej kopii roboczej, wykonując
osc submitrequest home:$yourself:branches:openSUSE:Factory initviocons openSUSE:Factory -m 'akatualizacja do wersji 3.3'
Spowoduje to utworzenie żądania wskazującego, że oferujesz coś wspaniałego dla Factory. :-) Opiekunowie projektu szybko to sprawdzą. Jeśli zmiana jest akceptowalna, mogą połączyć ją ze swoim projektem. Jeśli potrzebuje więcej pracy, mogą przesłać dodatkowe informacje.
Jak obsługiwany jest mój wkład?
The maintainer of a project (like openSUSE:Factory) is supposed to check for contributions (i.e. for submit requests) like this: Opiekun projektu (np. OpenSUSE:Factory) powinien sprawdzać wkład (np. składanie żądań) w następujący sposób:
% lista żądań osc openSUSE:Factory 37 nowy home:poeml/initviocons -> openSUSE:Factory/initviocons 'akatualizacja do wersji 3.3'
Opiekun przyjrzy się zmianie, porównując ją z bieżącym źródłem pakietu i albo ją zaakceptuje, albo odrzuci i poda powód.
% osc request show -d 37
Prośba o przesłanie (id 37):
home:poeml/initviocons -> openSUSE:Factory/initviocons
Wersja źródłowa MD5:
f839321325a0b5582def283c3520bf13
Wiadomość:
'akatualizacja do wersji 3.3'
Status: nowy 2008-03-20T19:57:02 poeml
zmienia pliki:
--------------
--- initviocons.changes
--- initviocons.changes
@@ -20 +20 @@
- który wysyła charakterystyczny pierwotny da
+ który wysyła charakterystyczny pierwotny DA
[...]
Następnie opiekun może zaakceptować zgłoszenie:
osc request accept 37
Lub odrzuć to z powodu:
osc request decline -m "brak dziennika zmian, ale wymagany przez zasady" 37
Przykład z interfejsem internetowym
Opisuje jak zmieniać źródła przez interfejs sieciowy, możesz go znaleźć dla openSUSE na http://build.opensuse.org.
Interfejs internetowy jest przyjemny, aby uzyskać przegląd i zmienić proste rzeczy, takie jak oczywiste błędy lub opisy pakietów. W przypadku bardziej złożonych zmian, takich jak rozwiązywanie konfliktów scalania, zaleca się użycie interfejsu CLI.
Jak mogę dodać swoje zmiany do pakietów innej osoby?
Powiedzmy, że chcesz pracować nad pakietem openSUSE:Factory/initviocons, a później prześlij swoją pracę z powrotem do projektu openSUSE:Factory.
Poniżej pokazano, co robić krok po kroku.
Utwórz pakiet oddziału
Musisz utworzyć gałąź, która jest w zasadzie kopią oryginalnego pakietu, ponieważ zwykle nie masz dostępu do zapisu w miejscu docelowym. Lub najpierw chcesz poeksperymentować, zanim wyślesz kod do wszystkich użytkowników.
Gałąź zawsze domyślnie się łączy ze zmianami z pakietu rozgałęzionego.
W przypadku openSUSE:Factory przejdź do listy pakietów i znajdź swój pakiet.
Utwórz galąź projektu
Po pierwsze, tworzymy gałąź pakietu (i jego projekt), nad którą chcemy pracować w naszym projekcie domowym. Kliknij menu "Actions", a następnie "Branch package".
Serwer ten tworzy nowy projekt poniżej home:$yourself:branches, gałęzi projektu. Ta galąź projektu ma taką samą konfigurację kompilacji jak oryginalny projekt źródłowy. Polecenie tworzy również pakiet wewnątrz gałęzi jako łącze źródłowe.
Wiele pakietów ma zdefiniowany 'Devel Project'. W takim typowym przypadku serwer tworzy link do tego projektu deweloperskiego zamiast projektu źródłowego. Widać to w danych wyjściowych 'osc branch', takich jak to:
Praca nad zmianami
Kliknij kartę "source files" i edytuj źródła według potrzeb. Powinieneś poczekać i zobaczyć, czy naprawdę się budują.
Możesz także pobrać pakiety i wypróbować, czy Twoje zmiany naprawdę wpływają na wykonanie.
Prześlij zmiany do scalenia
Gdy będziesz zadowolony i uwierzysz, że Twoje zmiany mają duże szanse na zaakceptowanie przez opiekunów projektu głównego - to znaczy, jeśli korzystasz z przykładów w innym miejscu tego dokumentu, przez opiekunów projektu openSUSE: Factory - możesz śmiało poprosić o przesłanie.
You can either create a submit request via the "Actions" menu or find the link "show diff and submit these changes back" on the "Source Files" page.
Możesz utworzyć prośbę o przesłanie za pomocą menu "Actions" lub znaleźć link "show diff and submit these changes back" na stronie "Source Files".
This will create a request for the target author, who will review your change and usually accept it. Your branched package is usually remove after merging back (except you denied this).
Spowoduje to utworzenie prośby do autora docelowego, który sprawdzi Twoją zmianę i zwykle ją zaakceptuje. Twój pakiet rozgałęziony jest zwykle usuwany po ponownym połączeniu (z wyjątkiem tego, że tego odmówiłeś).
Specjalna obsługa dla openSUSE:Factory
Każdy pakiet w openSUSE: Factory ma "repozytorium rozwojowe" (development repository). Te repozytoria są używane do programowania samego pakietu. (Możesz "zobaczyć" projekt pakietu za pomocą osc meta pkg openSUSE:Factory <pakiet> | grep devel lub prościej z osc dp openSUSE:Factory <pakiet>.) Jeśli wykonasz: osc branch openSUSE:Factory <package> nie zdziw się, jeśli otrzymasz pakiet z innej lokalizacji, jeśli chcesz wprowadzić zmiany w pakiecie w openSUSE:Factory.
Aby wykonać zgłoszenie do openSUSE Factory (uwaga: zaakceptowanie zgłoszenia w projekcie deweloperskim nie powoduje automatycznego zgłoszenia do fabryki!), Opiekun projektu Devel musi zrobić coś takiego:
osc sr -m "- updated package, thanks to foo bar" <devel:project> <package> openSUSE:Factory
Mamy więc dwa scenariusze:
Gałąź, nieoficjalny obieg pracy opiekuna projektu rozwojowego (Devel)
- osc branch openSUSE:Factory <package>
- osc submitrequest (wysyła zapytanie do projektu deweloperskiego)
- Opiekun projektu rozwojowego (Devel) akceptuje poprzez osc sr accept <id>
- Opiekun projektu rozwojowego (Devel) tworzy nowe żądanie wysyłania do Factory
- Ludzie z zespołu Autobuild akceptują zmianę
Przepływ pracy opiekuna projektu rozwojowego (Devel)
- Opiekun projektu rozwojowego (Devel) tworzy nowe żądanie wysyłania do fabryki
- Ludzie z zespołu Autobuild (openSUSE:Factory) akceptują zmianę
osc request list <devel:project>