dwuliterowe nazwy na kolejne dwie wersje PLD

[Tomasz Kłoczko]

Dlaczego dwuliterowa ?

Chodzi o to że potencjalnie dawałoby to możliwość wrzucania tej nazwy do
etykiet w cvs.
Dotychchaswe Ra wiadomo jakie miało podteksty .. pierwiastek, egipki bóg
słońca :)
Potencjalnie pierwiastów jest na tyle dużo jeszcze do wykorzystania, że
możnaby się trzymać tego schematu. Prawie każdy z sybboli perwiastków ma 
dodatrkwe pdteksty symbliczne wec w tej kwesti byłoby gucio :)
Kwestia co najwyżekj które teraz wybrać ? :)

Jeżlie ktoś miałby pomysł na jakieś inny schemat na krótkie nazwy to 
proszę :)

Dalej .. dlaczego dwie wersje PLD ?

Ab ovo: wygląda na to, że pracę nad PLD rozwidlą się nieco. Jedena linnia
to będzie dalsze dopracowywanie obecnego PLD 1.0 i tu dobrze żeby wyszła
dość szybko kolejna wersja 1.0.1. Myślę że za dwa, trzy moze cztery
miesięce wydanie takiej wersji poprawionej byłoby możliwe i miałoby sens.
Wyglada na to że także port na PPC mógłby już wyjść jako oficjalny w
1.0.1. Tą częścią zajmowałby się dzimi. To jak będzie wyglądać technicznie
współpraca między dzimim, a mną to że tak powiem proszę już pozwlić nam
dogadać się we dwójkę :). Potencjalnie może na dniach nawet wypuścimy tu
jakieś kawałek tekstu opisujący pewne wypracowane szczegóły (ale tu
chciałbym poczekać na wnioski płynące z dyskusji nad tym listem).
Potencjalnie zmieni się przynajmniej jedno i tu właśnie Marcin
przygotowuje zmiany na ftp. Chodzi o to że do obu linni PLD dojdą katalogu
updates. W przpadku wersji rozwojowej niewątpliwie znaczenie tego
kataklogu będzie takie że to pakeity po pzryjści do /test pakiety już
gortowe do użytku beda się kumulowac w tym katalogu i ca~ raz na tydzień
bendą przewędrowywać w kupie do podstawowej hierarhii. Przed skończeniem
1.0 też wejda jeszcze apt, poldek wuch które bendą operować dodatkowo na
katalogu updates i po za wykończeniem dwuch pakietów pod kontem security
to to już jest osdtania rzecz która musi wejść do 1.0. To jak będzie w
szczegółach wyglądać stabilizacja 1.0 to to jest w gestii dzimiego któremu
chciałbym pozostawić pełną swobodę co wypracowywanai sobie metod 
działania.

I teraz drugie odgałęzienie PLD. Nie wiem jeszcze jaką wersję temu nadać
choć pewne przemyślenia są.
Czy 1.2.x czy 1.1.x (?). Potencjalnie ze względu na to że chciałbym żeby
pierwsza wersja rozwojowa PLD pokazała się róznolegle z 1.0.1 ale 
potencjalnie nei bezie to nadal nowa wersja stabilna to wydaje mi się że 
równolegne z 1.0.1 powinno wyjść 1.1.0. Apo wyjściu kilku 1.1.x całosć 
możnaby zamknać 1.2.0 albo 2.0.0.

Ważne sa dwa założenia które mają przyświecać temu wszystkiemu:

- dystans miedzy 1.0.x i 1.[12].x dobrze jeżeli dałoby się utrzymać na
  stossunkowo minimalnym poziomie,

- wersje zamknietych dystrybucji powinny wychodzić częściej niż do tej 
  pory żeby nie było niepotrzebnego kumulowania się duzej ilosci 
  zmian w relatywnie duże zbiory.

Drugie ma umożliwiać o wiele płynniejsze konserwowanie systemów.
Za pierwszym kryć się może to że przykładowo do 1.0.1 wejdą nie tylko
poprawki ale także częsciowo aktualizacje pakietów ale takie które nie
bandą destabilizować całości/opierać się bendą o pewien 
nienaruszalny trzon pakietów bibliotecznych, kernel i kilka innych
(np. wersja rpm-a).
Także linni 1.0.x ma być dla tych którzy na duze zmiany nie chą czy nie 
mogą sobie pozowolić.

Co do przykładow zmian jakei jednak mogłby sie pziawić w 1.0.1 to na pewno
w międzyczasie pojawi się kilka wersji fetchmaila inie widze powodu dla
którego świeża wersja tego programu nie miałaby równolegle trafić do obu
linni. Takiech "miękkich" przykładłów zmian można by wymienić więcej i
miałoby to mniej więcej czegoś takiego dotyczyć. Służyć miałoby to
zmniejszaniu dystansu między obecją wersja stabilna 1.0.x a wesja
rozwojową po to żeby ewentualne przejście było poprostu łatwiejasze.

Tak czy inaczje z tych przemnyśleń wyłania się powoli schemat pracy nad
kolejnymi wersjami który posiada zaporzyczenia cech z różnych innych 
dystrybucji ale z pominięciem pewnychy wad. To jeszcze i tak tylko nadal 
zarys ale za kawąłek powinno się to już zestalić. Tak czy inaczje chodzi o 
to żeby podporządkować to wszystko pewnym wadom jakie są znane z metod 
pracy w RH, Debianie czy innych i żeby dołożyć do tego pewne dodatkowe 
cechy które byłyby suma wszystkich w tej chwili dosępnych doświadczeń. W 
tym sensie jeżeli ktoś widzi w tym (nadal jeszcze) zarysie pewne luki czy 
jeszcze braki, a co wiecej potrafi je nazwać, potrafi pokazać ich 
konsekwencje to prosze o komentarze.

Tak czy inaczje to dopiero medotologia na tym poziomie będzie miała wpływ 
na bezpostrednie zmiany w zarżadaniu zasobami w cvs, interakcję między
dzimim i mną (tutaj nie mam wątpliwiości że uda nam się dogadać). Niemniej 
decydujący głos co do konkretnych szczeółów chciałbym żeby należał do 
dzimiego i mnie jak osób bezpostrenio operujących na tym/jako tych którzy 
swój własny warsztat pracy bendą musieli adaptować do ogólnych założeń.

Oprócz w zasadzie tego co się z powyższego wyłania powinna dość jeszcze 
jedna rzecz. Mianowicie to co w tej chwili robi Arek z nest. Chodzi o to
żeby istniała strefa bardzo dużych eksperymentów. I tutaj co do
metodologii i reszty nie mam zamiaru się wtrącać jak bezie to sterefa 
eksperymentów a nie robienie czegoś zupełnie nie tzryma się reszty ściany.
Przykładowo uważam że nawet na wesję rozwojową PLD jeszcze nadal jest za
wcześnie na gcc 3.x na x86 (nie mówię tu w tym momencie jeszcze nic o axp, 
sparc czy ppc). Poprostu kod 3.x jest mnie optymalny niż kod
generowany przez 2.95.x i nadal jest jeszcze sens zostać przy tej wersji 
kompilatora.

Prosiłbym o przemyślenie tego najpierw nieco głębiej i zgłaszanie jakieś 
komentarzy po takim zastanowieniu.

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*