kernel w ac

[Tomasz Kłoczko]

On Fri, 11 Apr 2003, Piotr Szymański wrote:

> Hi,
> Trzeba przedyskutowac sprawe jadra w ac.
> Do ac od poczatku duza czesc developerow proponowala 2.6, bo juz przestarzale 
> ra mamy i chyba ac nie ma takie byc, robienie 2 jader jest bez szans (nowe 
> watki w glibc i masa zmian w innych pakietach). Tym ktorzy chca miec w ac 2.4 
> polecam pozostanie na ra, chyba ze wydawanie dystrybucji w PLD jest 
> podporzakowane grupie uzytkownikow ktorzy laduja je na serwery, mnie to 
> obojetne bo ac i tak pewnie nie bede instalowal, ale mam troche dosc 
> sluchania prosb o nowe pakiety.
> Poza tym nie chcialbym zeby nadal trwala taka sytuacja:
> ---
> Po paru godzinach przekonalem qmpla ze PLD jest dobrze zaprojektowane i dziala 
> naprawde sprawnie, na co on
> - Spoko, skad sciagnac jakas porzadna wersje PLD?
> - Nie da sie
> - He?
> - Porzadnej wersji jeszcze nie wydano.
> ---
> Ale w takim razie co z serwerami?
> Tutaj proponowalbym takie rozwiazanie, niestety wiazaloby sie ono ze zlamaniem 
> dobrej filozofii dzimiego, ktora mialaby polegac na nierozwijaniu Ra.
> Chodzi o to zeby wydac Ra 1.1, w ktorym zawarlo by sie wszystkie tam smieci 
> ktore blues i rmf wymysla i do nieego jako _alternatywne_ jadro dodaloby sie 
> 2.4. (Tak robi debian ze swoim stable, w 3.0 jest 2.2, a 2.4 jako opcja). I 
> potem ra byloby utrzymywane przez dlugi czas tylko wsecurity (bo na serwerach 
> nikt nie potrzebuje nowosci) a gdy 2.6 sie ustabilizuje to wtedy ci co chca 
> to przejda ci co nie, to niech siedza na ra.

Może na sam początek kilka rzeczy w formie wstępu:
- pakietów zależnych fizycznie od qwersji kernela jest tylko kilka (w 
  sumie narzedzia do modułów, zapewne może mocniej przebudowane 
  rc-skrypty i kilka innych pakietów).
  Resta rzecz ymogłaby być spokojnie z produkcji jaka by wychodziła z Ac.
- sporo rzeczy obecnie w 2.5 nie działa i to szczególnie o ile jest w 
  modułach.
  To może powodować że w duzych ilosciach przypadków 2.5 nie bezie jeszcze 
  przez jakis czas nadawało się do użytku.
- tetmin wypuszczenia 2.6.0 w czerwcu jak to zapowiadał kilk miesięcy temu 
  w NBS Linus wydaje sie nadal dość pradopodobny choć IMHO 
  prawdopodobieństwo poślizgu dzisiaj oceniłbym na nieco większe niż wtedy 
  (niektóre zmiany poszły dość błęboko).
- niewątpliwie trzeba pogodzić jakoś możliwie szybkie osiągnięcie 
  stabilnej formy Ac z ewentualnością przejścia na 2.6 czy nawet końcowe 
  2.5 zanim jeszcze owe prace się skończą (musimy mieć taka furtkę .. 
  poprostu).

Co jest potrzebne do tego żeby powyższe uczynić łatwiejszym ? IMHO w  
sumie jedno, a mianowicie zredukować do neizbędnego minimum ilość pakwitów 
(źródłowych) zaleznych od wersji kernela. W tej chwili gro z tych pakietów 
to te które generują różne krenel-*. Tu będę upierdliwy i przypomnę że 
jakieś niecałe dwa lata temu walczyłem wrecz z resztą zespołu o to żeby 
wszystko zwinąć do jednego pakeitu kernel. Widać to w tej chwili do czego 
doprowadziło to zaglądając do updates/security/SRPMS w którym to ze 
wzgledu na brak takiej komasacji jest tam sporo pakeitów które w sumei 
żadnych zmian klady security nie posidają.

Jak to osiagnąć na 2.4 ? Ano dosć prosto. Należy skomasować rózne patche w 
kilka i konserwować je po za kernelem wystawiajac je takze na k-l żeby 
samemu za duzo na konserwacje tych zasobów nie poświęcać czasu.

Na decyzję czy Ac powinno być jeszcze na 2.4 czy juiz na 2.5 uważam że 
jeszcze jest za wcześnie. Niemniej należy robić możliwie wszystko żeby 
takia przejście było formalnością.
W razie przedłuzania się prac nad 2.5 bedziemy mieli furtkę w postaci 
zamkniecia prac nad Ac i rozpoczecia prac nad kolejna linią.

Jeszcze raz: w tej chwili jest za mało faktów które przeście na 2.5 już 
teraz czyniły by w pełni racjonalnym.

kloczek
PS. przyznam się że cała reszta wątku w której w większoći są prowadzone 
spory na temat tego co kiedy wyjdzie jest dość mało trzymajaca się ściany
:)
-- 
-----------------------------------------------------------
*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*