Testowa gałąź Debiana jest miejscem, w którym deweloperzy przygotowują kolejne stabilne wydanie. Choć to jest nadal jej główny cel, wielu użytkowników wybrało właśnie tę wersję Debiana, ponieważ oferuje dobry kompromis pomiędzy stabilnością a świeżością. Nadal jednak używanie właśnie jej ma pewne minusy, które Ciągle Używalny Testing (Constantly Usable Testing, CUT) zamierza usunąć. Poniższy artykuł prezentuje ów projekt oraz wyzwania jakie on przedstawia.

O niestabilnej i testowej gałęzi Debiana

Debian unstable jest tą gałęzią, do której deweloperzy dodają nowe wersje pakietów. Co jakiś czas zdarza się, że jakiś pakietów nie da się zainstalować, z powodu zmian w innych pakietów lub niezakończone większe migracje.

Debian testing, w przeciwieństwie do unstable, zarządzany jest przez narzędzie, które dba o spójność całej gałęzi: wybiera aktualizacje z unstable tylko wtedy, gdy pakiet zostanie należycie przetestowany (zazwyczaj po 10 dniach), jest wolny od błędów krytycznych dla wydania, jest dostępny dla wszystkich obsługiwanych architektur oraz nie psuje innych pakietów dostępnych już w testowej gałęzi. Zespół ds. Wydań sprawuje nad owym narzędziem kontrolę oraz udostępnia „wskazówki”, które pozwalają mu znaleźć zestawy pakietów, które mogą zostać przeniesione z unstable do testinga.

Powyższe zasady ponadto zapewniają, że pakiety, które przechodzą do testinga, są raczej wolne od poważnych problemów (takich jak niemożność uruchomienia systemu lub X). To czyni testową gałąź bardzo atrakcyjną dla tych użytkowników, którzy pragną używać nowych wersji oprogramowania bez konieczności użerania się z większymi problemami z nimi związanymi. To wszystko bardzo pociagające, jednak część Deweloperów Debiana zaleca nie używanie testinga. Dlaczego?

Znane problemy testinga

Znikające oprogramowanie

Zespół ds. Wydań używa tej gałęzi do przygotowania kolejnego stabilnego wydania, dlatego od czasu do czasu usuwa z niej pakety. Czasami aby upewnić się, że inne pakiety mogą zmigrować z unstable do testinga, czasami ponieważ posiadają one przez długi czas błędy krytyczne dla wydania i nie zanosi się, aby miały one zostać naprawione. Ponadto czasami opiekunowie pakietów proszą o ich usunięcie, ponieważ dana wersja nie będzie mogła być wspierana pod względem bezpieczeństwa przez 2 lub więcej lat. Również Zespół ds. Bezpieczeństwa regularnie prosi o usuwanie pakietów z podobnych powodów.

Długie oczekiwanie na poprawki błędów bezpieczeństwa oraz ważnych

Pomimo dziesięciodniowego opóźnienia w unstable, nadal trafiają się uporczywe błędy (w tym bezpieczeństwa), które zostają odkryte dopiero po zmigrowaniu pakietu do testinga. Nawet jeśli opiekun szybko doda poprawiony pakiet w unstable, i podniesie poziom ważności aby pakiet szybciej przeszedł do gałęzi testowej, jego migracji może przeszkodzić akurat trwająca większa migracja. Takie dodatkowe opóźnienie może trwać czasami nawet kilka tygodni.

Owe opóźnienie może zostać pominięte poprzez dodanie pakietu bezpośrednio do testing (za pomocą testing-proposed-updates), jednak niemal nigdy nie korzysta się z tej możliwości, poza okresem zamrożenia gałęzi testowej, kiedy to owe poprawki są normą.

Nie zawsze da się zainstalować

Ponieważ testing zmienia się każdego dnia, aktualizacje czasami psują ostatnie nośniki instalacyjne (szczególnie obrazy typu netboot, ktore wszystko pobierają z sieci). Pakiety instalatora Debiana (D-I) zazwyczaj szybko są naprawiane, jednak nie są automatycznie przenoszone do testinga, ponieważ nowa kombinacja pakietów D-I niekoniecznie została jeszcze sprawdzona. Ów problem podsumował Colin Watson: — Przenoszenie kodu nowego instalatora do testinga zajmuje zbyt wiele czasu, przez co problemy pozostają nierozwiązane w testowej gałęzi nazbyt długo. — pisze na liście dyskusyjnej CUT-a — Problem z rozwojem D-I jest bardziej skomplikowany niż wolne tempo przygotowywania nowych *wydań* D-I. (...) Możemy wybierać między stable (zbyt stary), testingiem (byłby dobry, tylko czasami psuje się i naprawa zajmuje kilka tygodni) oraz unstable (psuje się nieustannie).

Historia CUT-a

Korzenie CUT-a sięgają starej propozycji Joey'a Hessa, w której zauważył, iż stabilne wydanie nie jest jedynym wytworem Debiana, oraz że testing może — przy pewnym nakładzie pracy — nadawać się dla końcowych użytkowników. Nikt owej pracy się nie podjął i przez ostatnie trzy lata nic się w tej kwestii nie zmieniło.

Jednak ostatnio Hess ponownie podjął dyskusję na temat CUT-a na liście dyskusyjnej debian-devel, a Stefano Zacchiroli (Lider Projektu Debian) poprosił go o poprowadzenie dyskusji na temat CUT-a na konferencji DebConf10. Dyskusja ta okazała się najpopularniejszą (nagranie wideo), oczywistym jest, że istnieje duże zainteresowanie tym tematem.

Obecnie założona została dedykowana wiki oraz projekt na Alioth i lista dyskusyjna. Ten artykuł w dalszej części podsumowuje różne przedyskutowane propozycje oraz sposoby na rozwiązanie zidentyfikowanych problemów.

Cel CUT-a

Spośród wszystkich celów, wyraźnie zarysowują się dwa podejścia, które zostały przedyskutowane. Pierwszym z nich są regularnie wykonywane migawki testinga w momentach, w których wiadomo, iż działa on względnie dobrze (owe migawki otrzymywałyby nazwę „cut”). Drugie to stworzenie usprawnionej gałęzi testowej dostosowanej do potrzeb użytkowników, którzy chcą działającej gałęzi z codziennymi aktualizacjami, jej nazwą byłoby „rolling”.

Regularne migawki testinga

Uzgodniono, iż regularne migawki testinga są wymagane: to jedyny sposób aby się upewnić, że stworzone nośniki instalacyjne będą działać do czasu utworzenia kolejnej migawki. Jeśli testy migawki nie ujawnią żadnego większego problemu, zostanie ona najnowszym „cutem”. Dla jasności, oficjalna nazwa kodowa będzie oparta o datę, np.: „cut-2010-09” będzie „cutem” wykonanym we wrześniu 2010 r.

Choć częstotliwość wykonywania migawek nie została jeszcze ustalona, zakłada się, że będą one tworzone dość często — przynajmniej raz na pół roku, przy czym zaproponowano nawet cykl miesięczny. Aby osiągnąć konsensus musi zostać rozważonych wiele aspektów.

Jednym z nich (i przypuszczalnie najbardziej istotnym) jest wsparcie bezpieczeństwa. Biorąc pod uwagę, że Zespół ds. Bezpieczeństwa już obecnie jest przepracowany, ciężko będzie dodać im roboty przez zadeklarowanie, że „cuty” będą posiadać takie wsparcie jak stabilne wydanie. Brak wsparcia wydaje się być kiepskim pomysłem, jednak niekoniecznie jest tak problematyczny jak by się wydawać mogło. Sytuacja pod względem bezpieczeństwa w testingu jest ogólnie lepsza niż w stable (szczegółowe dane), ponieważ poprawki w naturalny sposób wpływają razem z nowymi wersjami pakietów. Stable nadal otrzymuje poprawki ważnych błędów bezpieczeństwa szybciej niż testing, jednak ogólnie mniej znanych problemów z bezpieczeństwem jest w testingu.

Ponieważ tylko kwestią czasu jest zanim poprawiona wersja zostanie udostępniona przez twórców danego oprogramowania, częstsze wydania „cuta” oznaczają, że użytkownicy otrzymają poprawki bezpieczeństwa wcześniej. Jednak Stefan Fritsch, który działał w Zespole ds. Bezpieczeństwa Testinga, również doświadczył problemów dotykających osoby, które publikują uaktualnienia bezpieczeństwa: — Aktualizacje w testing-security zazwyczaj są użyteczne tylko przez kilka tygodni, do kiedy poprawiona wersja zmigruje z unstable. — pisze na liście CUT-a — W stable aktualizacje pozostają przez kilka lat, co bardziej motywuje by spędzić czas nad ich przygotowaniem.

Dlatego trudno jest utworzyć pełny oddania zespół ds. bezpieczeństwa, praca nad udostępnianiem poprawek bezpieczeństwa spada na opiekuna pakietu. Zazwyczaj są oni dość szybcy w dodawaniu poprawionych pakietów do unstable, jednak rzadko sprawdzają czy pakiet migruje do testing. Nie można ich winić, ponieważ gałąź testowa powstała aby przygotowywać kolejne stabilne wydanie, dlatego nikogo nie niepokoi oczekiwanie na zmigrowanie pakietu, o ile nastąpi to przed wydaniem.

CUT może pomóc w tej kwestii, ponieważ zmienia podejście: użytkownicy będą używać pakietów z testinga, dlatego zasługują oni na pracę nad poprakami bezpieczeństwa, podobnie jak użytkownicy stable.

Podczas wybierania częstotliwości wydawania „cutów” należy też wziąć pod uwagę rozmiar pracy jaką należy wykonać w związku z oficjalnym wydaniem: testowe aktualizacje z poprzedniej wersji, napisanie informacji o wydaniu oraz przygotowanie nośników instalacyjnych. Wydaje się, iż ciężko będzie wykonywać ją co miesiąc. Przy takiej częstotliwości niemożliwym jest dostarczenie nowego wydania jądra dla każdego „cuta” (ponieważ te wychodzą co 2–3 miesiące) z obsługą nowego sprzętu jaką one przynoszą, co dla wielu użytkowników jest interesujące.

Podsumowując, regularne migawki rozwiązują problem nie zawsze instalowalnego testinga oraz zmieniają postrzeganie testinga przez opiekunów pakietów, tak aby — miejmy nadzieję — bardziej troszczyli się oni o poprawki bezpieczeństwa w tej gałęzi (oraz „cutach”). Jednakże nie rozwiązuje problemu znikających pakietów. Aby ów rozwiązać potrzeba czegoś innego.

Nowa gałąź „rolling”?

Lucas Nussbaum zauważył, że regularne migawki to niezupełnie nowy pomysł: — Czym by się to różniło od innych dystrybucji o 6–miesięcznym cyklu wydawniczym, a zwłaszcza Ubuntu — pisze — które obecnie mogą być postrzegane jako migawki Debiana (+ wartość dodana)?

Wg Nussbauma, CUT staje się interesujący, jeśli udostępni się gałąź rotacyjną (rolling release) (jak testing) z „nieustannym dopływem nowych wersji pakietów”. Uważa, że byłoby to „coś całkiem unikalnego w świecie Wolnego Oprogramowania”. Migawki używane byłyby jak punkt wyjściowy dla początkowej instalacji, jednak zainstalowany system wskazywałby na gałąź rotacyjną, a użytkownicy mogliby wykonywać aktualizację wg własnych potrzeb. Przy tym scenariuszu wsparcie bezpieczeństwa nie jest tak ważne, istotny jest stan gałęzi rotacyjnej.

Gdyby używać testinga jako gałęzi rotacyjnej, problem znikających pakietów nie zostałby rozwiązany. Dlatego dyskutowano nad wprowadzeniem nowej gałęzi o nazwie „rolling”, która działałaby podobnie jak testing, ale z odpowiednio przystosowanymi regułami, wtedy „cuty” byłyby migawkami rollinga, nie testinga.

Podstawową propozycją jest wykonanie kopii testinga oraz ponowne dodanie pakietów, które zostały usunięte, ponieważ nie nadają się dla pełnego wydania, ale kwalifikują się dla stale uaktualnianego wydania (ostatnim przykładem [już nieaktualnym — przyp. tłum.]) jest Chromium).

Następnie będzie można pójść krok dalej: podczas zamrożenia testing przestaje być automatycznie uaktualniany, co czyni go nieodpowiednim źródłem dla gałęzi rotacyjnej. Dlatego zostanie ona przekonfigurowana aby pobierać aktualizacje z unstable (używając tych samych reguł co testing).

Biorąc pod uwagę częstotliwość wydań, prawdopodobnie jedynie część architektur będzie oficjalnie wspierana. To nie jest istotny problem, ponieważ użytkownicy, którzy pragną najnowszych wersji oprogramowania, najczęściej korzystają z systemów biurkowych głównie na architekturach i386 i amd64 (oraz prawdopodobnie armel w przypadku tabletów i podobnych urządzeń przenośnych). Ten wybór — jeśli zostanie powzięty — otwiera drogę na kolejne możliwości: jeśli rolling zostanie skonfigurowany dokładnie jak testing, tylko z mniejszym zestawem architektur, prawdopodobnie część pakietów będzie do niego migrować szybciej niż do testinga, kiedy pakiety na architektury spoza głównego nurtu będą opóźnione.

O ile wyprzedzanie testinga może być dobre dla użytkowników, jest również problematyczne z kilku względów. Po pierwsze, zarządzanie rollingiem stanie się dużo bardziej skomplikowane, ponieważ zarządzanie migracjami nie będzie mogło zostać zaadaptowane w obecnej postaci. Może to też wprowadzić rywalizację między obiema gałęziami, co z kolei utrudni wydanie stabilnej edycji, np. kiedy opiekunowie przestaną troszczyć się o migrację do testinga po zakończeniu migracji do rollinga.

Gałąź rotacyjna jest z pewnością dobrym pomysłem, jednak zasady nią rządzące muszą być tak zaprojektowane, aby uniknąć konfliktu przy wydawaniu stabilnego Debiana. Wreszcie, samo istnienie rollinga wreszcie naprawi marketingowy problem, który dotyka testing: nazwa „rolling” nie sugeruje, że dane oprogramowanie nie nadaje się do normalnego użycia.

Podsumowanie

To w jaki sposób CUT zostanie zaimplementowany pozostaje do rozpatrzenia, jednak początek jest pomyślny: FTPMaster Joerg Jaspert stwierdził, iż nowy serwer dla archiwów poradzi sobie z nową gałęzią, a propozycja nabiera już kształtów. Projekt może wystartować szybko: gotowy jest plan implementacji dla części projektu dotyczącej migawek. Gałąź rotacyjna zawsze może być wprowadzona później, kiedy będzie gotowa. Oba podejścia mogą wzajemnie się dopełniać i udostępniać coś przydatnego dla różnych rodzajów użytkowników.

Propozycja w całości jest zdecydowanie interesująca: uspokoi obawy o przestarzałość stabilnego wydania Debiana poprzez udostępnienie wydań pośrednich. Każdy kto wymaga czegoś bardziej na czasie ze względu na obsługę sprzętu może zacząć od instalacji „cuta”, a następnie kolejych jego wydania aż do stabilnej wersji. Zaś użytkownicy, którzy zawsze chcą mieć najnowsze wersje oprogramowania mogą po instalacji „cuta” używać gałęzi rotacyjnej. I Z punktu widzenia użytkownika, widać podobieństwa do zwykłych i długoterminowych wydań Ubuntu. Jednak z punktu widzenia deweloperów zauważyć można spore różnice, a ograniczenia nakładane przez ciągle używalną gałąź są wyraźniejsze: każda większa zmiana musi zostać zaprojektowana w sposób, który sprawi, że będzie ona stopniowa, w jasny dla użytkownika sposób.

Źródło: raphaelhertzog.com/2010/10/04/can-debian-offer-a-constantly-usable-testing-distribution/