przyszlosc PLD

[Mariusz Mazur]

On pon 7. czerwca 2004 12:22, Andrzej Krzysztofowicz wrote:
> Mysle, ze najwyzszy czas na rozpoczecie dyskusji nad przyszloscia PLD.

Miałem akurat taki mail wysyłać dzisiaj/jutro, ale mnie ubiegłeś :)

> Jezeli Ac nie ma byc ostatnim wydaniem tej dystrybucji (jesli w ogole
> wyjdzie), to najwyzszy czas na rozpoczecie prac nad nowa wersja (Th? inna
> nazwa?). Widze tu na dzien dobry takie zagadnienia:
>
> 1. Jak sie ma ta linia PLD nazywac?

Imho może być pierwiastek. Byle by był wymawialny. Wybór nazwy przywilejem 
RMa, jak dotychczas? :)

> 2. Kto bedzie RM-em (brak chetnych oznacza, ze na Ac zakonczymy prace)

Jeśli ktoś ma ochotę (i jakiś większy staż w pld), to proszę bardzo. Jeśli 
nie, to ja się znowu biorę do roboty.

> 3. Jakie architektury wspierac (builder dla -alpha moge udostepnic)

To jest już tylko kwestia dostępnego sprzętu. Jak udowodnił jajcuś, nie jest 
niemożliwe dodanie architektury w trakcie rozwoju nowej linii.
A - *musimy* zrezygnować z przynajmniej jednego x86. Będzie to 386/586 (ja bym 
wolał to pierwsze), ale decyzja na 100% będzie należeć do cdg, żeby nie było 
jednego winnego (rma).

> 4. i nastepne: szczegoly techniczne, propozycje kierunkow, sugerowane
>    szacunkowe harmonogramy, warianty, ...

"Będzie jak będzie". Przy czym będzie mniej roboty, niż z Ac z racji tego, że 
będzie to zdecydowanie mniejsza przepaść czasowa (Ac póki co jest mniej 
więcej na fali, a nie skansenem, jakim już rok temu było Ra).
Póki co 'technologicznie' to nie ma co do tego 3.0 właściwie włożyć (nowe gcc 
i nptl). Tylko chyba jakieś przymiarki i miejsce na nowe rzeczy.
Za to organizacyjnie - i owszem.
Osobiście bardzo bardzo chętnie bym wykorzystał możliwość trzymania paczek w 
różnych katalogach. Skróciło by to generowanie indeksów i pozwoliło łatwiej 
zapanować nad głównym imo problemem z trzymaniem tego wszystkiego - popsutymi 
zależnościami. 
Na początek pochlastać całość na przynajmniej dwa kawałki. Oczywiście 
najmilsze byłoby jakieś core(server)/desktop, ale to fajnie brzmi, tylko 
gorzej wymyślić jak to przeprowadzić. Imho najlepiej po prostu przeciąć po 
linii X/non X. I tak robiąc spece mamy zasadę, że rzeczy nadmiarowo 
generujące zależności od xów dostają osobne podpakiety, więc nie powinien być 
to aż taki problem.
Poza tym wydzieliłbym kernel do osobnego podkatalogu (marzyłyby mi się trzy 
kernele: server, desktop i vanilla... ten ostatni jako sposób na 
diagnozowanie problemów, bo jak coś nie działa, to jedną komendą można by 
zainstalować czyste jądro; inne kernele wedle potrzeb, jak ktoś ma czas, to 
żaden problem udostępnić infrastrukturę).

Do tego przydałby się jakiś system oznaczania pakietów do przenoszenia z 
ready. Ale na to nie mam na razie pomysłów.


> I jesli uda nam sie na te pytania choc czasciowo odpowiedziec, to mysle, ze
> najwyzszy czas na uruchamianie odpowiedniej infrastruktury (znajac zycie
> moge powiedziec, ze potrwa to _minimum_ kilka miesiecy.

Z tą infrastrukturą to jest właśnie problem. Osobiście nie podoba mi się 
trzymanie builderów poza maszynami starych deweloperów (preferowane maszyny 
uniwersyteckie), no ale z braku laku. Ktoś ma jakieś sugestie gdzie co można 
dawać?
Na razie plan minimum to jest builder 686, builder src (za który teoretycznie 
może robić już istniejący, chociaż wolałbym nie, bo się nie wyrobi z 
miejscem) no i miejsce na ftpie. Ty mówisz, że masz alphę.
Imo główny problem to builder src i miejsce na ftpie. Postawienie builderów to 
dla mnie chwila moment. Ale gdzie wysyłać paczki :) 
Propozycje? Deklaracje? (preferowane ufundowanie jakiegoś budynku z dużą 
ilością sprzętu w środku, żeby można wreszcie to pld scentralizować :)

-- 
Każdy człowiek, który naprawdę żyje, nie ma charakteru, nie może go mieć.
Charakter jest zawsze martwy, otacza cię zgniła struktura przeniesiona z 
przeszłości. Jeżeli działasz zgodnie z charakterem wtedy nie działasz w ogóle
- jedynie mechanicznie reagujesz.                 { Osho }