Branch 1.0

[Tomasz Kłoczko]

On Sat, 24 Nov 2001, --s+ wrote:

> --->[Quoting Jacek Konieczny <jajcus w pld.org.pl>:]
> 
> > Podbijanie release swoją drogą, ale przede wszystkim _trzeba_ oddzielić
> > rozwój PLD taki jaki był dotychczas od tego co ma być PLD-1.0.
> > I do tego jest potrzebny branch.
> 
> Tomasz, konkretnie, kiedy będzie ten branch?

Dopiero po wypuszczeniu 1.0.

Zapewne jeszcze nie tylko do Ciebie dotarło więć jeszcze raz powtórzę.
Wszystkie zmiany jakie możemy robimy nadal na HEAD. Po zamknięciu 1.0 i
*rozpoczęciu prac nad kolenją wersją* żeby wiedzieć gdzie byliśmy wszystko
zostanie oetykietowane. W tym momencie o ile jakiś pakiet będzie wymagał
poprawki np. ze względu na wykryty jakiś błąd który bezie powodował że coś
jest nie do użytku czy ma błąd klasy sec to w miejscu gdzie został dany
*pakiet* otagowany postanie branch ale tylko o ile powyżej etykiety
pojawiła sie zmiana która nie powinna już wejść do 1.0. W pzreciwynym
wypadku zamiast brancha poprostu etykieta do 1.0 zostanie poprosty
pzresunięta. Inaczej: branche bea ale tylko w pojedynczych pakietach i tam 
gdzie bendą konieczne. Taki sposób traktowanai całosci daje nam to że 
żadna zmiana która bezie musiałą być wprowadzona po wypuszczeniu 1.0 a 
która będzie musiała wejść do updateów do 1.0 nie będzie powielana w 
branchu i na HEAD.

Jeżeli tego typu zmian nazbiera się więcej to może będzie za jakis czas po
tym wypuścić 1.0.1. Tu lepiej bezie zamiast wyznaczać sobie terminy,
wczłniej sztywne sposoby postępowania lepiej dać sobie swobodę reagowanai
na bierzaco zaleznie od okoliczności. Wtedy znowu całość zostanie
oetykietowana. Tak czy inaczej nie bedziemy się raczje bawuić w rózne RC i
inne tego typu bo tego typu wersjionowanie jest niejako zawsze trobione
pod marketing. My marketingu nie mamy więc możemy zajać się rzeczywistą
pracą nad zasobami.

Kiedy to konkretnie będzie (data) tego nie wiem. Podałem jak można
próbować oszacować ten czas bo wszystko wskazuje na to że jesst on już w
tej chwili do oszacowanai z dość duzym prawdopodobieństwem. Takie rzeczy
trzeba określić funkcjonalnie, a nie jako punkt w czasprzestrzeni. Możemy
dyskutować nadal na temat takich warunków jakie musza spełnić zasoby żeby
mogły zostać nazwane 1.0. jednym z takich warunków już padł. Chodzi o to
żeby po instalacji całości na świerzym systemie w pełni udała się
rekompilacja wszystkich src.rpm-ów jakie zedecydujemy się wrzucić do 1.0.
Mówiąc inaczej określenie momentu wejścia 1.0 opisujemy *wyłącznie*
funkcjonalnie a nie za pomocą konkretnych dat. Określamy to poprzez
warunków czysto technicznych jakie zasoby muszą spełnaić żeby
można było zacząć prace nad kolejna wersją które każdy z nas może 
weryfikować.

Taki sposób określenia kiedy ma wyjść kolejna wersja daje nam gwarację 
tego że zdążymy poprawić wszystkie szczegóły które znajdą się na różnych
listach tego co należy poprawić. Nie mamy etatowych pracowników i 
tymbardzoej juz tylko z tego powodu nie ma sensu sie katować żeby zdążyć 
na określona chwilę nie majac pewnosci na dobrą sparwę czy wszystko co 
było mozliwe, a co *było wcześniej namierzone* zostało poprawione. Nie 
powodować też to bezie że robota pzreciagąć sie bezie w nieskończoność. 
Powyzsze podejście daje nam też furtkę że beziemy mogli wypuścić 1.0 o ile 
beziemy zdawać sobie sprawę że kilka rzeczy jednak nie jest 
poprawionych/dokończonych. Mówiąc inaczje mamy przy takim podejsciu 
znacznie szersze pole manewru bez narażania sie na stersy wynikające z 
tego że konkretne terminy nas gonią i potem wyrzucania sobie że ktoś 
czegoś nie zrobił. W takim wypadku nawet oficjalnie mozemy próbować 
dołączyć lisę oficjanie znanych błedów co powinno także wpłynąć juz nie 
tylko na nasze samopoczucie ale takze osób ktrtóre uzywając PLD nie biorą 
udziału bezpośrednio w parcach.

Poowtórzę się jeszcze w innej kwestii. Zapewne w tym co mamy na ftp mamy
troche śmiecia który nie koniecznie z takich czy innych powodów możnaby
wyrzucić. I tu o ile ktoś dostrzega takie pakiety które możnaby tak
potraktować to proszę o propozycje. Np. ja widzę conajmniej jeden taki
pakiet: fetchpop (pierwowzór fetchmaila od dłuższego czasu raczej nie
rozwijany). Nie wiem czy podobnie ni powinniśmy potraktować 2UTF bo w
zasadzie jego funkcje prawidłowo powinien spełniać iconv a i tu ze względu
na dosć juz długi okres nie rozwijania programu istnieje *ryzyko, że
dostarczamy program z dużą ilościa błędów po mimo tego że pakiet się
kompiluje*. To może być niejako kryterium decydujace o tym czy coś usunać
czy nie. Jest to niemniej kryterium dość płynne/niejedoznacznie określone
wiec takie rzeczy poprostu bendą wymagać omówienia sztuka po sztuce.

> Dlaczego uniemożliwiasz nam pracę sabotując jego powstanie?

Nic nie sabotuje. Masz nadal pełne możliwości pracy :)

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*