memorandum.txt (~15kB)

Śro, 18 Lip 2001, 21:39:20 CEST

Marcin Bohosiewicz <marcus w venus.wis.pk.edu.pl> writes:

> > - HOWTO in english. Otherwise it does not have a sense.
> Instalator - w porzadku, jeszcze przydalaby sie mozliwosc
> wsadowej instalacji (cos co by zastapilo moje cp -av)
> Co do HOWTO - jako ze jest to PLD a nie ELD, opisy powinny byc
> jednak rowniez w polskim jezyku. 
Tak, _również_, a nie _wyłącznie_. Moim zdaniem lepiej było by mieć
wersję angielską jako podstawową i na jej podstawie tłumaczyć na
polski (w końcu tłumaczenie eng->pl jest o niebo prostrze dla pl
ludzi niż w drugą stronę)

> > - name:
> > 	1) Polished
> Polish! w ostatecznosci Polish(ed) jako forma zartobliwa
Protestuję. Każdy osobnik != Polak, któremu powiedziało się o ,,Polish
Linux Distribution'' od razu mówił, że nie zna polskiego. Taka nazwa
(częściowo) błędnie sugeruje zawartość. Najprościej będzie po prostu
,,PLD'', a rozwijać skrót będzie sobie każdy sam, a jeśli już ma być
to Polish(ed).

> > - nie posunęliśmy się z pracami, od niemal dwóch lat
> >   stąpamy w miejscu, przybywa tylko speców, których
> >   konsystencji i jakości nikt nie pilnuje.
> Specow przybywa, jakosc specow jednak wzrasta, problemem jest
> jedynie zbyt usilne dazenie do uzywania najnowszych wersji wszystkiego
> co sie da, co czasem owocuje tzw. burakami.
Dla mnie to (najnowsze wersje) nie jest problemem. Wręcz przeciwnie -
to zaleta.. Jeśli jakieś grono osób chce w końcu stable to należy po
kolei przeglądać pakiety i branchować je (np. branch PLD_1_0), a potem
dopieścić ów branch i zrobić release. Na HEAD sytuacja ma zostać tak
jak do tej pory. Jednak mimo powstania listy beta-testerów i tego typu
rzeczy nie widzę żadnego ruchu w kierunku wydania stable.

Moim zdaniem należy wybrać spośród chętnych (są tacy?) release
managera i niech on zaproponuje pełen dokument (a może nawet narzuci o
ile dokument będzie sensowny) dotyczący harmonogramu, sposóbu
wprowadzania poprawek do brancha PLD_1_0 i zajmuje się pełną
koordynacją.

Tak to się odbywa przy projektach typu gcc i myślę, że jest to dobry
sposób (polecam przeczytać maile puszczane przez release managerów
gcca - zawierają dobre wskazówki i przykłady).

> > - kończy się miejsce na użyczonych przez dziekana MIMUW
> >   komputerach - builderach.
Z tego co wiem to dyski były niemal w drodze (ale ostatnio nie jestem
na bierząco).

> Wczoraj na #pld padlo z mej strony pytanie: 
> Czego potrzeba na maszyne, ktora mialaby pelnic funkcje buildera
> na ix86. Poprosze parametry techniczne na marcus w kernel.pl.
Bardziej by się przydały dyski do serwera u Janka :)

> Jak mam do wyboru: oddac kase fiskusowi lub ja zainwestowac
> wole wybrac to drugie!, szczegolnie ze kasa powstaje z komercyjnego
> wykorzystania PLD..... wiec inwestycja ta jest dla mnie poprostu
> inwestycja w warsztat.
O ile stable wypali i znajdzie się ktoś typu release manager to będzie
potrzebny builder na x86 (btw. wydaje mi się, że pierwsze PLD-1.0
będzie tylko na x86 bo pozostałe porty są unstable i wybrakowane
nieco). Aktualnie to jest z tego co pamiętam (a moge pamiętać źle)
2xPIII 700MHz z 1GB ramu + kilka GB HDD. 

> > - nie rozpoczęliśmy operacji planowania przejścia na
> >   jądro 2.4, które jest oficjalnym jądrem linuksa,
> >   i niebawem stanie się powszechnym standardem.
> Z tego co wiem pakiety sa do tego juz dawno przystosowane.
> Gorzej sam kernel, ktory IMHO nie powinien sie jeszcze 2.4.x
> nazywac, bo jest jeszcze zbyt niedopracowany. I to ze podstawowa
> wersja to 2.2.19 w tej chwili to dobrze, bo na srodowiskach produkcyjnych
> powinnismy uzywac _stabilnego_ a nie najnowszego oprogramowania.
Gry (i o ile) wystartuje branch stable to będziesz miał środowisko
stabilne :) Tylko skąd znów miejsce na ftpie na drzewo stable?

> > - decyzja o dopuszczaniu każdego pakietu musi zostac podejmowana 
> >   tylko wtedy, kiedy znajdzie się dla niego opiekun, i to
> >   jasno określony z imienia i nazwiska,
> I co ? Bedzie jak w Debianie ze jak komus sie odechce to pakiet bedzie
> bezpanski? CVS zapenia identyfikacje kto co zrobil. Rozne osoby
> maja rozne podejscie do tych samych spraw i "burza mozgow" przynosi wiele
> dobrego. 
Zgadzam się. Nie ma sensu przyjmowanie modelu Debiana, a nasz model
jest IMHO o niebo lepszy.

> > - podzielić dystrybucję na część stabilną i rozwojową,
> >   aby coś przetestować, trzeba mieć pewność, że to,
> >   co się testuje, nie jest codziennie inne,
> OK. Ale widzialbym to raczej jako "zamrazanie" dystrybucji np raz na pol
> roku, poprawienie bledow, wypuszczenie iso i biezace poprawianie
> pakietow, w ktorych odkryto bugi (szczegolnie security).
> Do takiej zamrozonej wersji przez czas jej supportowania powinny lezec
> srodowiska builderowe by mozna bylo szybko sporzadzac poprawki.
Powinny być osobne buildery bo pewne osoby (w tym ja) będą chciały
dalej działać na HEAD, a do tego są potrzebne buildery.

> Moznaby przestawac poprawiac stare wersje dystrybucji po wypuszczeniu nowej
> stabilnej wersji, albo po 2 nowych wersjach (np 1.0 idzie w odstawke jak
> pojawia sie 3.0) Wiem ze na to potrzeba mijsca na dyskach ale jw (dyski sa
> tanie!)
Znaczy się kupisz parę dysków do wstawienia do kennyego ? ;)

> > - poddać się rewizji podobnej do innych projektów opensource, 
> >   sourceforge.net jest dobrym wyjściem, na początek proponuję
> >   umieścić tam bugtracking (jak tylko będzie co trackować); 
> >   sourceforge ma również cenne szacowanie jakości i aktywności 
> >   projektu - mielibyśmy szanse naprawdę zaistnieć w światku linuxowym,
> Akurat sourceforge ostatnio mialo rozne dosyc kompromitujace wpadki :/
> To co mamy, po dodaniu BTS jest IMHO wystarczajace!
Też nie chcę sf.

> Serek, jakos Alan Cox nie chce pozbawiac Linusa prawa decydowania co jest w
> kernelu, mimo ze ze czasem maja odrebne zdania. Owszem, nalezy zwrocic uwage
> Tomkowi, by wiksza uwage przywiazywal do stabilnosci i spojnosci PLD, ale
> projekt powinien miec silnego lidera/koordynatora.
Najbardziej to trzeba mu (Tomkowi) wybić z głowy wrzucanie na niemal
ślepo wszystkich łatek jakie tylko znajdzie w rawhide, cookerze i tym
podobnych. (2x historia z secenhace do gpma, raz z fileutils
(paskudny przypadek mv)).

> Tworzenie wlasnych (PLD? w jakiej formie prawnej?) zasobow pozostawilbym
> na pozniej tj. moment kiedy PLD byloby juz liczaca sie marka na
> rynku.
Problem jest taki, że nie ma bardzo jak uzyskiwać sprzętu od firm
(np. od IBMa, dobrek robił wywiad) itp bo wszyscy chcą sporządzić
jakaś tam umowę, a tu PLD nie ma żadnej osobowości prawnej. Jakaś
osobowość była by przydatna. Tylko znów problemem tutaj jest brak
osoby chętnej się tym zajmować (stworzeniem osobowości prawnej).

> Ze swej strony oferuje w tej chwili 2xPIII 600 512MB RAM
> do dyspozycji, pojemnosc dysku zalezy od potrzeb. Wolne
> koncowki kabla Ultra160 SCSI czekaja.
> A ja zamiast placic podatek wole go w cos zainwestowac...
Builder x86 STABLE? :)

> Kasa powinna pochodzic z instalacji i supportu prowadzonego przez
> tych ktorzy sie na PLD znaja najlepiej. czyli NAS!
Była propozycja stworzenia firmy zajmującej się m.in. supportem, a
składającej się z developerów PLD, ale jak widać to tylko kolejna
rzecz z której nic nie wyszło. 

> -| == Marcin Bohosiewicz - MB8042-RIPE - marcus w venus.pk.edu.pl == |-

-- 
 Arkadiusz Miśkiewicz, AM2-6BONE, 1024/3DB19BBD
 IPv6 ready PLD Linux at http://www.pld.org.pl/
My jsme Borg. Odpor je marný, budete asimilováni