Stable, was Re: okolo cwierci tysiaca zmian w cvs w ciagu 48h

Witold Filipczyk juandon w poczta.onet.pl
Pon, 3 Gru 2001, 19:49:09 CET


On Mon, Dec 03, 2001 at 02:31:47PM +0100, --s+ wrote:
> --->[Quoting Witold Filipczyk <juandon w poczta.onet.pl>:]
> 
> > Co dla Ciebie oznacza stable?
> > Czy w związku z wydaniem stable będziesz jeszcze atrakcyjniejszy dla kobiet?
> 
> Dokładnie! Wszystkie panny na to lecą, bracie.
Tak, żeby jeszcze wiedziały co to komputer, to może i tak.
[...]
> Zarabiasz na administracji serwerami? Czy wolisz przygody?
> A może jesteś naukowcem-teoretykiem?
Wiecznym studentem.

Zauważyłem, że działa się tu na zasadzie pospolitego ruszenia a nastroje są coraz
gorsze.  Więc jeśli się czegoś nie zmieni to zima nas zastanie, a będzie ona
sroga (Indianie już od trzech lat chrust zbierają).
A najgorsze jest to, że nie ma tu żadnych reguł a nawet jeśli jakieś są, to
i tak nie są znane ogółowi.
Proponuję, żeby na spokojnie ustalić reguły, standardy.
Jeśli są tu tacy, którzy już pięć lat wojują z PLD to te kilka dni na ustalenia
ich nie zbawi.
Ciężko jest gdziekolwiek dojść, jeśli nie wiadomo gdzie się chce dojść.   

> > Robimy najstabilniejszego nest-a, tzn. to co jest na FTPie zawsze się daje
> > zainstalować bez problemów.  Powiedzmy raz na miesiąc robi się snapshoty
> > .iso.
> 
> Hehe, zainstalować <> używać. Snapshoty robiliśmy dotychczas niemal
> codziennie, niestety żaden z nich nie nadawał się do użycia.
> To tak, jakbyś zamroził zgniłą fasolkę, jak już tłumaczyć poglądowo.

Mam to rozpracowane teoretycznie.  Kwestia implementacji i wdrożenia. 

> > Nawyk developera PLD jest taki, że każdego .spec-a którego robi (lub
> > cokolwiek innego), robi tak jakby miałby to być najlepiej zrobiony przez
> > niego .spec (lub cokolwiek innego).
> 
> Niestety bujasz w obłokach idealizmu, niewielu z nas jest w stanie
> zrobić rzecz obiektywnie bezbłędną. Gdyby tak było, to nie zmagalibyśmy
> się od pięciu(!) lat z PLD. Nie ukrywam, jest coraz lepiej, ale
> to są naprawdę zbyt małe kroki, wynikające z ciągłych eksperymentów.
> Nie mam nic przeciw temu, byśmy się bawili, ale razna jakiś czas
> zróbmy coś porządnego.

Oczywiście jestem idealistą, a idea jest taka, żeby nic nie robić i jeszcze
brać za to pieniądze.
Ale są przypadki perfekcjonizmu (patrz: Mały Szadam), a to znaczy, że to jest
możliwe i to nawet u Nas.

[...]
> > Po przebudowaniu pakietu 'release' jest podbijane w .spec-u.  Nie robi się
> > tego ręcznie, żeby nie mieszać.
> 
> Tak chyba robione jest... window$, hehe. Build 1451.
Oczywiście z Windows powinniśmy brać najlepsze wzorce.  Tam zrobili Windows-y
raz, żeby ładnie wyglądały, a potem tylko podbijali release.
Też moglibyśmy zrobić raz a porządnie, później to by była już tylko
konserwacja, a nie co pół roku from scratch.

> 
> > Jeśli pakiet się przebudował i nie jest w konflikcie z nikim trafia
> > na kwarantannę do test.  Po jej przebyciu zostaje dorzucony do głównej gałęzi
> > po jeszcze jednym sprawdzeniu czy nie bruździ nikomu.
> 
> Rozumiem, że masz jakiś pomysł na automatyczne testowanie pakietów?
> Możesz podesłać na listę swoje skrypciki?
Tu akurat chodzi o spójność.  Żeby nie było tak, że są pakiety na FTPie, które
wymagają bibliotek, których już nie ma albo jeszcze nie ma.

Jeśli chodzi o testowanie pakietów to też mam dużo pomysłów, np.
Każdy developer ma u siebie przynajmniej kawałek speców i źródeł z CVSa
wystarczającą do zbudowania pakietu.
Jeśli pakiet się nie buduje, to dalej myśli co zrobić.
Jeśli się buduje (od razu budujemy dla kilku architektur) to robi commita do CVSu,
a podpisane elektronicznie przebudowane pakiety przesyła mailem do robota od FTP.
Oczywiście ujednolicona konfiguracja u wszystkich.

A BuildRequires znajduje się tak:
Najpierw kompiluje się na gołym systemie i jeśli czegoś brakuje doinstalowuje
się potrzebnego devela i dopisuje go do BuildRequires, aż się uda.
Albo zaczyna od pełnego systemu (wszystkie devele) i wyrzuca co niepotrzebne. 

 
> > Nawyk developera-programisty jest taki, że na bieżąco utrzymuje dokumentację
> > do tego co robi.  Jeśli przyswoimy sobie te nawyki to pełen sukces.
> 
> W świecie idealnym.
> 
> > Robienie snapshotów .iso to mniej więcej tak jak granie koncertów (zespół
> > jest w formie i gra coraz lepiej).  Wydanie płyty koncertowej (STABLE)
> > niewiele by się różniło od ostatniego snapshotu, ale co wrażliwsi słuchacze
> > mogą wybrać THE BEST OF - najstabilniejsze release'y z koncertów i prób
> > (prawie zawsze będzie to pakiety z ostatniego snapshotu, może kilka o rel
> > wcześniejsze).
> 
> Koncert robotów. Słyszałem, że komputery potrafią grać już w szachy
> i pisać wiersze. Czemu nie mają nam zrobić PLD, co nie.

Jeśli to co jest dotychczas nie wszystkich zadowala, a często się zdarzają
działania developerów nieprzewidywalne (raz tak, raz inaczej), więc wprowadzenie
automatów dałoby przynajmniej tyle, że byłaby jakaś stabilizacja,
przewidywalność.  Bo czy tu trzeba dużo główkować, żeby określić czy dany pakiet
może wejść/wyjść z test (1bit tak/nie).

A wygrasz z komputerem w szachy? :)

WF



Więcej informacji o liście dyskusyjnej pld-devel-pl