openSUSE:Build Service Współpraca

Skocz do: nawigacja, szukaj

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).

Uwaga: Ta strona opisuje interfejs użytkownika osc od wersji 0.119. Starsze wersje miały nieco inne polecenia.

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

Uwaga: Ta funkcja nie jest obecnie zaimplementowana w przypadku zamrożonych projektów, takich jak openSUSE: 11.0, Fedora: 9 lub :Update . Wymaga to zmian w naszej obsłudze technicznej, które pojawią się później : :)

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)

  1. osc branch openSUSE:Factory <package>
  2. osc submitrequest (wysyła zapytanie do projektu deweloperskiego)
  3. Opiekun projektu rozwojowego (Devel) akceptuje poprzez osc sr accept <id>
  4. Opiekun projektu rozwojowego (Devel) tworzy nowe żądanie wysyłania do Factory
  5. Ludzie z zespołu Autobuild akceptują zmianę

Przepływ pracy opiekuna projektu rozwojowego (Devel)

  1. Opiekun projektu rozwojowego (Devel) tworzy nowe żądanie wysyłania do fabryki
  2. Ludzie z zespołu Autobuild (openSUSE:Factory) akceptują zmianę
Dlatego dla opiekunów projektu rozwojowego (Devel) zawsze dobrym pomysłem jest skonfigurowanie powiadomień Hermes, aby otrzymywać informacje o żądaniach wysyłania w stosunku do ich projektu i/lub sprawdzać żądania wysyłania w stosunku do ich projektu za pośrednictwem
osc request list <devel:project>