CVS znowu.

[Tomasz Kłoczko]

On Wed, 20 Jan 1999, Grzegorz Stanislawski wrote:

> On Wed, 20 Jan 1999, Tomasz Kłoczko wrote:
> 
> > Każde repozytorium CVS ma pewien moduł który nie musi być nigdzie
> OK, dzieki ;-)
> 
> > >   Znowu wracam do tematu zrodel w cvs'e. IMHO trzymanie samych patch'ow,
> > > jak jest teraz, jest (bez obrazy) idiotyczne. Patche sa sprawa wtorna w
> > 
> > Nie sugeruj się tym, że to są patche. Traktuj to tak samo jak inne zasoby.
> > Patche też z wersji na wersję źródeł będą mogły ulegać zmianom i te zmiany
> > miałyby być rejestrowane w CVS.
> > 
> > Tak jak to widzę. Jeżeli masz alternatywny pomysł ..
> > 
>  Troche mi to sobie trudno wyobrazic. Zalozmy ze ktos zechce wprowadzic
> jakies zmiany do zrodel. Wyglada na to ze musi po tych zmianach
> wyprodukowac diffa i wyslac go na cvs. Moze to zrobic na dwa sposoby albo
> nazwac swojego diffa tak samo jak poprzedniego i wtedy po commit cvs
> zapisze sobie te dane o wersjach, albo pod nowa nazwa dodajac odpowiednie
> PatchN: XXXX.diff do speca.
>  W obu przypadkach (tak mi sie przynajmniej wydaje) nie mamy zielonego
> pojecia kto jest odpowiedzialny za konkretna linijke w zrodlach. Trzeba
> przegladac wszystkie przyslane diffy recznie albo w najlepszym przypadku
> grepem. 
>  Zwroc uwage, ze cvs, bezmyslny przeciez program, bedzie rejestrowal
> jako "zmiany" dane produkowane przez diffa, np takie cos:
> --- modules/pam_mail/pam_mail.c.BAK     Wed Jan 14 22:58:30 1998
> +++ modules/pam_mail/pam_mail.c Thu Nov 19 04:52:36 1998
> @@ -35,6 +35,7 @@
> Nie jestem przekonany czy takie cos jest komukolwiek poza programem patch
> potrzebne.
>  Pozostali ludzie, beda musieli po zrobieniu update'a spatchowac swoje
> katalogi i o ile przy drugim rozwiazaniu da sie to jakos przezyc, to
> pierwsze z nich jakos czarno widze.

Załómy, że mamy pakiet XX i w kolejnych trzech wersjach mia on trzy wersje
speców w CVS oznaczoe rewizjami (kolejno) 1.1, 1.2, 1.3. Tu trzeba
zaznaczyć, ze rewizje te to tylko oznaczenia wewnętrzne w CVS i nie mają
one nic wspólnego z wersjami pakiety XX. Załóżmy, e te kolejne trzy werje
pakietu to 0.1, 0.2 i powiedzmy 1.0. Jednoczęśnie w trakcie preparowania
kolejnych wersjio speców okazało się, że werje 0.1 i 0.2 miały jakiś tmp
race, którego w 1.0 nie było ale w 1.0 pojawia się konieczniość
patchowania makefile. Jak po tym wszystkim będą wygladać drzewka źródeł w
SOURCES i SPECS:

plik SPECS/XX.spec
	\
	 rev: 1.1, Tags: XX-0.1-1
	 - wypuszczo wersję 0.1
	 - dodano patcha do tmprace.
	 |
	 rev: 1.1, Tags: XX-0.2-1
	 - update do 0.2
	 |
	 rev: 1.3, Tags: XX-1.0-1, STABLE, DEVEL
	 - update do 1.0
	 - usuniecie patcha XX-tmprace.patch i dodanie XX-makefile.patch.

plik SOUURCES/XX-tmprace.patch
	 \ 
         rev: 1.1, Tags: XX-0.1-1, XX-0.2-1
         - pierwsza wersja patcha do tmprace do XX-0.1,

plik SOUURCES/XX-makefile.patch
         \
         rev: 1.1, Tags: XX-1.0-1, DEVEL, STABLE
         - pierwsza wersja patcha do tmprace do XX-0.1,

Zauważ że sciągająć wszystko z modułów SOURCES i SPECS z każdej z trzech
etykiet XX-0.1-1, XX-0.2-1 i XX-1.0-1 otzrzymasz źródła jakie Ci są
potrzebne do wygenerowania XX w wersjach 0.1, 0,2 i 1.0 i nic więcej.

Jednocześnie etykiety STABLE i DEVEL idą za czołem zmian i po każdej
zmianie przesuwają się.

Kolejna sprawa, to to, że etykiety <%name>-<%version>-<%revision> są
nakładane dopiero wtedey kiedy zapadnie decyzja o tym żeby pakiet
wypuścić. Taka decyzja może ona zapaść jednoosobowo lug geremialnie w
porozumieniu z osobami "maczającymi łapy" ostatnio w pakiecie. Właśnie
tutaj można IMHO odejść od sztywnego maintainingu pakietów jakie jest w
Debianie. Wiadomo, że za wersję pakietu są odpowiedzialni robiacy zmiany w
nim i osoba etykietująca. Moze sie zdażyć tak, że pakietów w przyszłości
bedzie na tyle dużo, że krąg ossób etykietujących trzeba bedzie zwiększyć
np. ktoś od TeXa czy CPANowych modułów perlowych, ktoś od KDE czy GNOME,
ktoś od Base, ktoś od kernela i okołokernelowych narzędzi czy jeszcze inne
możliwe działy (MTA .. może python, tcl/tk). Niemniej byłbym za tym żeby
takie powiązania miedzy ludźmi pełniacymi takie funkcje były w miarę luźne
bez zbędnego formalizowania kontaktów. Powód jest prosty dlaczego tak, a
nie inaczej: poprostu .. daje się tak pracować w sposób w miarę zgodny na
poziomie prac z CVS (GNOME i inne due projekty) to dlaczego i poziom wyżej
nie miałoby być to możliwe ? Moim zdaniem jest to możliwe no i będziemy
mogli się o tym przekonać sami. IMHO tak czy inaczej da się zaszczepić
bezpośrednio OSS na gruncie czysto polskim .. potem niech to sie już dalej
rozrasta ;)

Powyżsy przykład to jest taki przypadek w którym akurat nie ma różnic
między devel i stable co będzie miało np. obecnie miejsce w przypadku
pakietów noarch.

Dalsze założenie jakie już poczyniliśmy z Wojtkiem wyglądają tak, że
główny tor zmian jest zdecydowanie _zarezerwowany_ dla devel, a na
potrzeby stable w razie czego robi się odgałęzienie w drzewku zmian
(brach). Na razie takowe odgałezienia na pewno będą musiały istnieć gdyż
nie ma binarnej zgodności między devel i stable (różne glibc). Z czasem ta
zmiana zniknie i pojawić się może znowu o ile taka niekompatybilność
wystąpowa będą znowu. W tym wypadku w odgałęzieniu dla stable o ile to
tylko będzie możliwe będzie tylko jedna zmiana polegająca na usunięcu "d"
z rewizji i/lib usunięciem/dodaniem patchy wymaganych dla stable.

Taka "redukcja" stable pomoże nam łatwiej wykorzystać czas jaki poświęcamy
na PLD (sorki ale ja też z czasem chciałbym pracować na rzeczach
w miarę najświeższych ;)

Może dopiero teraz widać jak ważne jest ujednolicenie spraw z "coding
style" i wielu innych drobiazgów, tego żeby nie używać numeru wersji w
nazwach plików patchy, bo będzie to za każdym razem pociągało za sobą
zmiany w specach (a tych oby jak najmniej przy robieniu stable).
Dopracowywanie wspólnej platformy dla obu odgałęzień PLD jest na jak
najlepszej drodze. Nie wszystko jeszcze zostało ustalone ale to tylko
dlatego że tych szczegółow jest "sporo" (różniących stable i devel) i
trzeba to _w tej chwili_ właśnie sformalizować. Po części opracowywanie
takich wspólnych zaleceń to jest ciąg różnych kompromisów na różne
szczególy dotyczące strony formalnej zapisu speca. W ramach tych zaleceń
już mniej wiecej np. zostyało ustalone, że np. many bedą gzipowane
Powódy: bzip2 musiałby wpaść do base, a zysk z bzipowania manów byłby
mniejszy niż dodanie bz2, przy okazji ilość pakietów w base zmniejszy się
o jeden (tutaj dobrze by było "walczyć" o każdą sztukę i jest to właśnie
element takiego sposobu rozumowania).

Do jutra mam nadzieję, że wyjdzie pierwszy zestaw speców jakie bedzie już
wynikiem takich wspólnych ustaleń. Wchodzić zapewne w ten zbiór będą mc,
autoconf, automake. Na ich przykładzie potem (post factum) opiszemy to w
miarę krótkim dokumencie.

> Powolywales sie na rpm'owe drzewko do robienia pakietow. Jest w nim
> katalog BUILD w ktorym sa zrodla programow. Moim zdaniem takie cos powinno
> sie znalezc w cvs'ie. Wstawi sie tam pakiet np takie rc-scripts i
> bedziemy go sobie obrabiac. W pewnym momencie oglosi sie "code freeze"
> wygeneruje sie diff'a, skopiuje do SOURCES, uzupelni speca o ten patch i
> powpisuje sie info do changeloga (to pewnie dalo by sie zautomatyzowac), i
> ewentualnie wywali z BUILD'a. Po jakims czasie pakiet sie zestarzeje i 
> ktos wpadnie ze jeszcze cos trzeba zmienic, i cala zabawa zacznie sie od
> poczatku. 

Moment BUILD to jest katalog roboczy w którym wszystko jest rozpakowywane
i budowane, a po wszystkim to co tam było utworzone powinno być
wykasowane. Patche i reszta archiwów źródłowych, ikonki pakietów są
przechowywane w SOURCE i dlatego też w ten katalog w CVS wpadają patche.

>  Przyjdzie ktos nowy i nie bedzie wiedzial za co sie "chycic", zciagnie
> sobie calego BUILD'a i przygladnie sie. Zdecyduje sie na jakis pakiet,
> reszte wywali i bedzie ciagnal i "commitowal" tylko to. 

Dla początkujacych trzeba będzie zrobić miedzymordzie www na CVS (skrypt
szkieletowy przychodzi z pservem). Po komentażach w kolejnych zmianach lub
brakach etykiet STABEL/DEVEL na czole zmian będzie mógł się najłatwiej
zorientować co jest obrabiane i co można jeszcze obrobić (bo nie ma tych
etykiet). Początkujący z czasm jak nabieże wprawy to dostanie prawa
zapisu (trzeba będzie opublikować część adresów kontaktowych na ludzi
mających prawa zapisu).

>  Mysle ze przy takim ulozeniu, PLD bedzie sie "samo robic". Bylbym nawet
> za tym, zeby na SOURCES dac readonly. Pliki w tym katalogu beda constans
> przez caly czas rozwijania wersji, a po "code freeze" "maintainer" (czyli
> ty ;-) doda recznie/lokalnie odpowiedniego patcha.

Zadaniem moim i Wojtka lub kogokolwiek innego kto będzie przejmował
pałeczkę będzie dodawanie przedewszystkim etykiet
<pakiet>-<wersja>-<rewizja> na konkretnych zasobach po to żeby zaznaczać
kolejne punkty rozwoju zasobów, któe są "używalne". Dodatkowo każdy z nas
po zdecydowaniu, że coś w konkretnej wertsji może juz wejść do zasobów
szerszych (jak dystrybucja), które można opublikować dalej będzie musiał
przesuwać lub też wogóle nawet przemieszczać między plikami etykiety
STABLE czy DEVEL po to żeby w łatwy sposób można było zassać ostanie w
przetestowane wersje zasobów. Pure developer bedą mogł ściągać z
samego szczytu zmian i w trakcie roboty jaką chce wykonywać tym całym
etykietowym bajzlem ma se głowy nie zawracać. Jego zadaniem jest
wprowadzać zmiany :) Jeżeli zauważy, że coś trzeba "odszczepić" na
potrzeby stable to bedzie mógł zrobić brancza dodatkowo ale wcale tego nie
będzie musiał robić.

Nawet gdyby zmiany między stable i devel były duże powodując, że zamianst
punktów powiązanych nitką otrzymywalibyśmuy choinkę z tych wszystkich
powiązań między zmianami to po dodaniu kolejnego punkuu na szczycie zmian
o ile zmiany dla stable bedą regularne to wykorzysać sie da merging z CVS
do tego żeby takie zmiany przenosić niemal automatycznie (po dodaniu nowej
ostatniej wersji devel zawsze można wygenerować patcha miedzy przed
ostatnim devel, a ostatnim stable i spróbować nanieść bo na ostanią wersję
devel).

Jak zwykle wszystko wyjdzie w praniu .. znaczy się jak rzeczywistość
będzie wyglądać naprawdę za jakieś dwa trzy miesiące to sie oczywiście
okaże. Powyższe o ile dobrze kalkuluję nie powinno jednak za bardzo
odbiegać od ostatecznych rozwiązań jakie wypracujemy ale zmiany o ile się
okażą konieczne przy jakioś szczegółach tak czy inaczej bedą wprowadzane.

Ważne są w tym wsztkim wszystkim pewne elementy porządku jak to, że devel
jest z ptrzodu lub to że stable może (ale nie musi) być w tym samym
miejscu co devel (może być nieco w tyle). Taki porządek nie powinien nam
mocno krępować tego co będziemy chcieli robić skracając jednocześnie do
minimum dystans miedzy pomysłem (devel), a przemysłem (stable). Stable
powinno być o krok lub pól do tyłu w stosunku do devel o ile to będzie
potrzebne w przypadku jakis nowych pomysłów. W innych miejscach pozycje
devel i stable powinny być pokrywające się (o ile rozwiazania są już
sprawdzone na wszystkie możliwe sposoby).

Myślę, ze właśnie to skrcenie dystansu w "myśleniu" o stable i devel
powinno być naszym podstawowym atutem. Linux zmienia się dość szybko
teraz. Sam w zauważam, że mam chęć na rzeczy bardzo świeże, bo nic temu
nie stoi na przeszkdzie po za tym że zasoby trzeba poprostu opracować do
formy używalnej. Brak widocznych efektów w wersjach produkcyjnych takich
dystrybucji jak RH, Slackware czy wiele innych to że nie są one "up to
date" tam gdzie to jest mozliwe bez narszania stabilności wersji
produkcyjnej powoduje to, że jest to często podstawowy bodziec do
wędrowania między rózmymi dystrybucjami. Jeżeli uda nam się dzięki właśnie
CVS i częściowej automatyzacji rónych prac skrócić ten dystans do minimum
bez naruszania stabilności i bezpieczeństwa całości to będzie to coś co
będzie PLD mocno odróżniało od reszty .. co da nam w efekcie końcowym
dalszych sprzymierzeńców .. dalsze zwiększanie tępa (dodatnie sprzężenie
zwrotne) i być może w przyszłości będzie kolejnym bodźcem do tego żeby
wprowadzać kolejne zmiany w schemacie organizacji obiegu informacji
itd. w samym PLD.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*