Co robimy z PLD?

[Sergiusz Pawłowicz]

Dnia 10-12-2004, pią o godzinie 16:32 +0100, Mariusz Mazur napisał(a):

> Propozycje są następujące:
> - zrobić do alphy listę pakietów, których nie budujemy

Propozycja jest pewną ewolucją do koncepcji, która od dłuższego czasu
pojawia się w rozmowach, które prowadzę na temat PLD.

Diagnoza jest dobra: brak zasobów.

Ponieważ jesteśmy technikami, to stękanie buildera alfy jest dla nas
jasnym objawem, że coś nie tak. Jednak to nie wszystko - przede
wszystkim brak specoklepaczy. 

Musimy się samoograniczyć i przygotować wspólnie listę paczek, które
będą utrzymywane w PLD i ich opiekunów, na ich wniosek. Oczywiście
repozytorium specy będzie nadal całkowicie otwarte dla wszystkich na
starych zasadach, jednak PLD zostanie zredukowane do paczek, które będą
miały opiekunów. Reszta może być kompilowana autorsko i wystawiana
oddzielnie pod autorskimi nazwami. Opiekun nie musi być jeden, może to
być kilka osób, ważne, by nastąpiła jasna deklaracja.

Model tym się różnił będzie od Debiana, że każdy naszą metodą grzebie
gdzie chce, natomiast jeśli jasno się nie określi, że zobowiązuje się
utrzymywać pakiet XXX na odpowiednim poziomie, pakietu nie ma na
publicznym FTP.

Oczywiście sub-projekty mogą być w tym samym repozytorium, chodzi o ich
oddzielenie formalne od PLD i nadanie im nazw oraz przede wszystkim o
samoznalezienie się liderów, którzy będą swe wózki pchali do przodu. 

Zaraz zaczną się krzyki, że w PLD znajdzie się pięć pakietów na krzyż,
bo nikomu się nie będzie chciało deklarować. Ale czy to nie byłoby
dla nas korzystne, gdyby jasno określić, jaki model dystrybucji
reprezntujemy? Czy to nie byłoby zdrowe, gdyby PLD było wysokiej jakości
dystrybucją serwerową, gwarantującą stabilne jądro ewentualnych wariacji
autorskich? Typu RescueCD, PLD Live - na tej bazie może powstać
dystrybucja Biurowa (tylko Xy, poczta, przeglądarka + OO), dystrybucja
Naukowa (obliczenia+kompilatory), etc itp.

Zalety większej koncentracji:

- zmniejszenie obciążenia builderów, 
- zmniejszenie zapotrzebowania na sieć i miejsce na FTP,
- szansa na stworzenie jądra dla projektów embedded, czyli takich, które
  na razie nie mogą wystartować, bo nie mają solidnej bazy w systemie
  operacyjnym.
 
Wady: 
- pożegnanie się z nadmiernymi ambicjami nie mającymi 
  odzwierciedlenia w rzeczywistości.

TO tak na szybko wszystko zapisałem, mam nadzieję, że nastąpi teraz
rzeczowa dyskusja :-)

S.