Category: mozilla

Ten wpis jest dedykowany tym wszystkim, którzy chcieliby zrozumieć czym jest “wydanie” produktu w świecie wolnego oprogramowania i czym różni się ono od tradycyjnego modelu.

Aby zrozumieć w całości model naszego postępowania, i jego przyczyny, warto przeczytać  esej Katedra i Bazar Erica S. Raymonda, ale w telegraficznym skrócie chodzi o zasadę “wydawaj wcześnie, wydawaj często“(ang. release early, release often).

Omówię teraz efekt zastosowania tej zasady na model wydawniczy na przykładzie Mozilli Corp. i przeglądarki Firefox.

W efekcie zastosowania modelu bazarowego, otwartego, nasze źródła są zawsze dostępne. Rozwój aplikacji opiera się na narzędziu zarządzania wersjami. To znaczy, że jest katalog, a w nim kod źródłowy aplikacji. Każdy na świecie ma do tego dostęp. Ma to ogromne implikacje w rozumieniu ideologii Wolnego Oprogramowania, gdyż gwarantuje użytkownikowi cztery fundamentalne prawa, co jest jednak tematem na osobny tekst. Na razie skupmy się na tym, że kod źródłowy ma swój numer.

W danym momencie jest to wersja, dajmy na to, 1 (pierwsza). W momencie gdy ktokolwiek, którykolwiek programista dokona jakiejkolwiek zmiany w kodzie źródłowym zmieniana jest wersja. Wersja kodu bez tej zmiany to wersja 1, a z tą zmiana to wersja 2. Każda następna wersja będzie nosiła następny numer.

Drugim ważnym elementem pozwalającym zrozumieć jak działa system wydań w wolnym oprogramowaniu jest kwestia linii rozwoju kodu.  Dwa podstawowe pojęcia związane są z analogią drzewa – to pień (trunk) i gałęzie (branches). Pień to główna linia rozwoju kodu, tam wchodzą wszystkie zmiany i z niego odłączają się gałęzie. Spójrzmy na obrazek:

To co widzimy na dole to właśnie “trunk”. Linia główna. Z niej odłączane są co pewien czas i numerowane, gałęzie stabilne. 1.7 (na nim bazował Firefox 1.0), potem 1.8 (na nim bazował Firefox 1.5 i Firefox 2.0), 1.9 (na nim będzie bazował Firefox 3.0) i następna będzie linia 2.0 (na niej będzie bazował Firefox 4.0).

Odłączenie gałęzi polega na wzięciu kodu z danego momentu w trunku i stworzeniu osobnej linii od tego momentu nazwanej gałęzią. Zmiany w gałęzi następują rzadziej, dotyczą tylko kwesti związanych z wydaniem danej wersji, są mniej eksperymentalne i mają na celu stabilizacje i przygotowanie wydania. W tym czasie w gałęzi głównej (trunk) mogą pojawiać się zmiany eksperymentalne, i inne nowości, które kiedyś stworzą następne wydanie.

Krytycznie ważne jest to, że nasze systemy automatyzacji co kilka godzin kompilują i umieszczają na serwerze tzw. nightly builds dzięki czemu można w każdej chwili pobrać i zobaczyć jak działa aktualna wersja ze źródeł sprzed godziny.Jak widać dla każdej gałęzi tworzone są osobne buildy.

Także wszystkie informacje na temat tego co planujemy dla Firefoksa 3 i silnika Gecko 1.9 są publicznie dostępne, wszystkie zmiany jakie nastąpiły, na przykład,  w ciągu ostatniego dnia można śledzić, a wszystkie zadania można przeglądać (tu na przykład zmiany blokujące wydanie Gecko 1.9).

Co to oznacza w zderzeniu z mediami? Problemy. Dziennikarze przyzwyczajeni, że znalezienie czegoś na serwerze oznacza wyciek wydania, przeszukują nasze serwery FTP, aby pochwalić się odnalezieniem na nich czegoś, a potem z stwierdzają, że zniknęło. W kontekście tego co pisałem powyżej powinno być to jasne, że na naszych serwerach są setki tzw. “kompilacji” robionych różnych gałęzi, które każdy może pobrać i przetestować. Jednak tylko niektóre z nich są wydaniami. Czymś co jest kierowane do odbiorców. I do mediów.

W kwestii wydań nie różnimy się w politce od innych firm. W momencie wydania piszemy o tym na serwisach informacyjnych typu DevNews, blogujemy, wysyłamy informacje do prasy, a samo wydanie ląduje w specjalnym katalogu o nazwie “releases” na serwerze.

Problem polega na tym, że dziennikarze przywyczajeni do tradycyjnego modelu, łapią co tylko znajdą na serwerze, linkują do tego i ogłaszają to jako wydanie, myląc tym samym użytkowników i potencjalnie narażając ich na niebezpieczeństwo. Kiedy? Ano załóżmy, że tzw. wersja nocna na 2 dni przed wydaniem zawiera błąd, który podczas testów jakości uda nam się wyłapać i poprawić przed wydaniem. Jeśli dziennikarze zachęcili ludzi do pobrania wersji bez poprawki, stworzyli (gwarantując własnym autorytetem) iluzję, że dana osoba pobrała coś o jakości “wydania produktu Mozilli”. Tymczasem myśmy nic nie wydali, dziennikarz wprowadził odbiorców w błąd.

Drugim przykładem z ostatnich dni jest ogłoszenie wydania Firefoksa 4.0 alpha 1pre  przez innego dziennikarza skanującego nasze serwery. Na dodatek  ów dziennikarz napracował się, aby przetestować osobno wydajność tego z ostatnią betą Firefoksa 3 i porównać je.

Co dokładnie definiuje czy mamy doczynienia z Fx3.0beta3 czy Fx4.0alpha1? W katalogu browser/config istnieje plik version.txt, który zawiera jedną linię tekstu będącą numerem wydania.Jeśli spojrzymy w historię tego pliku, zobaczymy, że zawsze tuż po wydaniu, albo tuż po odłączeniu gałęzi jest ona podbijana do następnego numeru. Kilka godzin później pojawiają się pierwsze nocne kompilacje z tym numerkiem, ale nie oznacza to wydania, prawda?

Zatem w przypadku porównywania dwóch nocnych kompilacji możemy mieć doczynienia z czymś takim:

  Górne kółko oznacza wydanie z nowo utworzonej gałęzi 1.9 z której wyjdzie Firefox 3. Dolne to wydanie z tego samego dnia, ale z gałęzi głównej z której kiedyś powstanie gałąź 2.0 i Firefox 4. Oba są z tego samego dnia. Jak dużo zmian mogło się tam pojawić? Kilka… w tym ta która podniosła numerek w pliku version.txt do 4.0a1pre. Czy jest sens porównywać je dziś? Nie bardzo. W ciągu najbliższych miesięcy najpierw skupimy się na wydaniu Firefoksa 3, a potem zaczniemy prace nad poważnymi zmianami w głównej linii na drodze do Mozilli 2.0 i Firefoksa 4.

Wydanie Firefoksa 4.0alpha1 nastąpi nie wcześniej niż za pół roku. Co prawda trwają już eksperymentalne prace nad platformą Mozilla 2.0,  ale są one jeszcze w bardzo wczesnym stadium.

Nie istnieje żadne wydanie, które nie znajduje się w katalogu releases,  o którym nie napisaliśmy na DevNews, i o którym nie poinformowaliśmy dziennikarzy. Pisanie o takich wydaniach jest zwyczajnym wprowadzaniem użytkowników w błąd, narażaniem ich na używanie wersji nie certyfikowanej przez Mozillę jakościowo i narażanie wizerunku Mozilli na szwank w przypadku, gdyby takie niestabilne wydanie “polecone” przez dziennikarzy okazało się wadliwe.

Chcąc pisać o wolnym oprogramowaniu trzeba to wiedzieć. Bo nie tylko my tak robimy, można pobrać codzienne kompilacje Ubuntu,  KDE, WordPressa, WebKita, NetBeans, VLC i wielu innych.

Drodzy dziennikarze. Dziękujemy Wam za zainteresowanie naszymi pracami. Jesteście dla nas wspaniałymi partnerami i sprawiedliwymi krytkami, cenimy współpracę z Wami i staramy się dać Wam to czego potrzebujecie. Wasze zainteresowanie zbliżającym się Firefoksem 3 odbieramy z dumą i traktujemy jako dowód, że robimy coś ważnego.

Jednocześnie prosimy, zrozumcie nas. Nasz model rozwoju jest taki a nie inny z bardzo konkretnych powodów. Pragmatycznych. Wierzymy, że udostępnianie codziennych kompilacji pomaga naszej społeczności testować i współpracować z nami. Jesteśmy do bólu otwarci, możecie zajrzeć wszędzie, obejrzeć stan prac nad dowolnym zadaniem, przeczytać o wszystkich planach, uczestniczyć w naszych cotygodniowych konferencjach telefonicznych na temat Firefoksa 3 i Gecko 1.9, do których dołączyć może każdy. Piszemy blogi, jesteśmy dostępni na IRCu.

Jeśli będziecie obniżać bezpieczeństwo naszych użytkowników i mylić ich, jedyne co możemy zrobić aby się bronić, to zmniejszyć stopień naszej przejrzystości. Zacząć chować się z tym co robimy, aby unikać chaosu. Przecież nikt tego nie chce, prawda?