Status AC i TH

[Mariusz Mazur]

Dnia piątek, 27 lutego 2009, Patryk Zawadzki napisał:
> Jak to sobie wyobrażasz? Co miesiąc będziemy nowego RM wybierać dla
> jednego snapa?

Nie, raczej że byłby taki arekm od th i taki ktośtam&ktośtam od tych 
snapshotów (tak jak jest w kernelu).

> Bo mnie na przykład jako developera średnio interesuje, 
> kiedy jest ten "na tydzień przed" - wychodzi coś, co mi jest potrzebne
> w nowej wersji, to podbijam i ślę na buildery.

Raczej myślę o bardziej konserwatywnym przenoszeniu przez ów tydzień, 
niekoniecznie blokowaniu słania.

> Rozumiem więc, że main 
> byłby mrożony, tylko komu by się chciało wybierać te pakiety, jeśli
> już w tej chwili zdarza się, że nie ma komu przenosić.

To jest w teorii do rozwiązania infrastrukturalnie. Linus też był choke 
pointem, póki tak tego nie zrobili, że Linus prawie za nic nie odpowiada i 
tylko klika 'ok' oraz uczestniczy w dyskusjach, a poszczególne decyzje 
podejmują ludzie od konkretnych podsystemów.

Gdyby dało się to wykombinować analogicznie, to ludzie od kernela by sobie 
sami jakośtam odklikiwali 'przenieść kernel', analogicznie ludzie od kde i 
czego tam jeszcze, a arek by tylko na to patrzył i mówił, że ok, przenosimy 
kde *klik*, albo że nie, wygląda potencjalnie ryzykownie, zrobimy to po 
następnym snapshocie.

Pomysł w tym, żeby (a) infrastruktura ftpowa nie działała na poziomie 
pojedynczej paczki, tak jak jest teraz i (b) reszta deweloperów też miała 
możliwość wykonywania pewnych akcji w obrębie swoich obszarów zainteresowań.

Acz przyznam szczerze, że nie mam zielonego pojęcia jak to by musiało być 
zaprojektowane i napisane. Podejrzewam, że wymagany kod byłby monstrualnych 
rozmiarów.


-- 
Oceniaj innych po zamiarach, a siebie po wynikach.
                                                                 Guy Kawasaki
Wykształcenie jest rzeczą godną podziwu, acz dobrze czasem
pamiętać, że niczego, co warto wiedzieć, nie da się kogoś nauczyć.
                                                                  Oscar Wilde