Co by tu zmienic w PLD...

[Paweł Sikora]

On Wednesday 28 July 2010 15:17:22 Jacek Konieczny wrote:
> On Wed, Jul 28, 2010 at 02:33:03PM +0200, Bartosz Świątek wrote:
> > > Zapewne Pythona 2.6 doczeka się tam w roku przyszłym.
> > 
> > Jeśli ktoś w robocie nie ma nic innego do czynienia tylko upgrade i
> > naprawa tego co właśnie wypiździło,
> 
> Ale dla kogoś, kto pracuje z Pythonem i z tego żyje, to różnica między
> Pythonem 2.5 i 2.6 jest istotna (nowe „drobiazgi” w języku, które bardzo
> ułatwiają pracę) – jedna z tych, dla których wybiera się inną
> dystrybucję (o ile jest taka możliwość). 
> 
> Kupa ludzi musi się męczyć ze starymi Pythonami tylko dlatego, że są
> przywiązani do jednej dystrybucji, czy hostingu. PLD daję mi tę wolność
> zastosowania aktualnej wersji i za to sobie je cenię.
> 
> Dla ciebie, to tylko jakaś pogoń za numerkami, pakietu którego sam
> bezpośrednio nie używasz (używa to „coś w systemie”), ale dla innego to
> kluczowy element.
> 
> Podejrzewam, że podobnie jest z wieloma innymi przypadkami, gdzie
> niektórzy widzą tylko pogoń za numerkami.

jakis czas temu status Th zostal bodajze przez Arka M. okreslony
- w miare mozliwosci uzywamy ostatniego oficjalnego wydania pakietu.
tu oczywiscie zdazaja sie drobne wyjatki w stylu gcc/glibc, kiedy trzeba
uzyc jakis snapshot svn-a, albo branch.diff zeby nie produkowac blednych
binarek, ale generalnie Th ma byc up-to-date.

to, ze niektore najnowsze wydania aplikacji przestaja na jakis czas (do kolejnego
wydania) ze soba wspoldzialac (np. python2.7 vs. wicd) jest bezposrednim efektem
tej polityki i trudno - jest to cena placona za plywajacy rozwoj i up-to-date.

jesli teraz pewna grupa ludzi chce miec cos takiego jak snapshot-th, czyli zestaw
aplikacji/rpm-ow, ktore ze soba wspoldzialaja bez rozwalania motywu przewodniego Th,
to musi sie sprezyc i te wszystkie aplikacje wchodace w sklad snapshota uzywac,
raportowac bledy i testowac kandydatow na kolejne snapshoty.

zeby taka grupa hobbystow mogla dzialac i nie musiala forkowac Th wystarczy
im bezkolizyjnie zapewnic dostep do archiwalnych rpm-ow (o ktorych byla juz mowa w watku).

tu pojawia sie pytanie ile tych archiwalnych rpm-ow trzymac?
np. trzymanie n-ostatnich moze byc bezsensowne (np. n-releasow ostatniej wersji,
ktora nie dziala z pythonem 2.7) i byc moze warto sie skupic na archiwizowaniu
n-ostatnich releasow z m-ostatnich wersji (n,m zalezne od wolnej przestrzeni na ftp).

majac takie archiwum mozna dosc swobodnie kompilowac kolejne snapshoty bez wstrzymywania
pedu Th "za numerkami".

wszyscy powinni byc zadowoleni i usmiechnieci :)