Buildery

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Pon, 13 Sty 2003, 22:59:02 CET


On Mon, 13 Jan 2003, Witold Filipczyk wrote:

> On Mon, Jan 13, 2003 at 08:24:02PM +0100, Tomasz Kłoczko wrote:
> > On Mon, 13 Jan 2003, Witold Filipczyk wrote:
> > [..]
> > > zmiana w CVSie (zmiana Release || zmiana Version || coś jeszcze) -> request SRPM
> > 
> > Wybacz le nie jest w tej chwili kluczową kwstia to żeby budować pakeit po 
> > każdej zmianie rel,. Kluczowe jest wszystko to co ma się dziać *PO* 
> > zbudowaniu pakewitu kiedy tak jak teraz leży on juz w test.
> 
> Dla mnie jest istotne, żeby każdy nowy pakiet, pakiet z podbitym rel, itp.
> był budowany.

Uwierz mi .. to nie jest kluczowe. Popatrz na Nest. Tutaj moze 
powstawać conajmneij tyle pakietów ile powstawało w Ra. Dlaczego nie 
powstaje ? Anio dlatgo, że newralgiczna czynnościa nei jest tu wysłanie 
kilku setek zleceń tylko obrobienie tego wszyetkiego co w wyniku tychże 
zleceń powstało.

Ważne jest i także to żeby przed puszczeniem pakietu miały szansę
przejrzeć go conajmnij kilaka osób. Jeżeli commit będzie generował sygnał
do przebudowania to tą sznsę odbierzesz wszystkim w z buildeów bedzie
wychodzić kupę sieczki której nikomu nawet nie bedzie chciało się dotykać
(a zmian wprowadzanych w osaniej chwili było zawsze dosć sporo o ile widać
było że szykuje się kolejne rel pakietu).

> Budowanie pakietów (przynajmniej w teorii) działa.
> 
> Co się dzieje dalej, sprawa przenoszenia pakietów z test na FTP, to właściwie
> nie moja sprawa.

I *to* co właśnie pomijasz jak na razie było najwęższym gardłem całości.
Jednocześnie powodowało najwiekszą ilość błędów.
Jednocześnie są tu czynnosci które były wykonywane zupłenie powtarzalnie 
(niemal automatycznie).

> Nie można tu wszystkiego zrobić automatycznie,
> tu musi decydować człowiek.

Można zrobić .. i to sporo.

> > > W czym jest problem?
> > 
> > W tym że to co poisujesz niczego nei rozwiązuje.
> 
> Według mnie sprawa budowania pakietów jest rozwiązana.
> Więc na czym polega oryginalny problem?
> Nie wyczuwam tu żadnych trudności.

Po zmodularyzowaniu i ustaleniu pewnej linii rozwoju tych narzędzie na
dłuższą metę przestanie to przypominać kupkę drożdży. Od czasu do czasu
jest taka pora żeby wręcz wszystko zgazować i wykorzystując zgromadzone
obserwacje zrobić coś zupełnie od nowa.

Rozumim zniecierpliwienie ale w ten sposób eksponowanie tego niczego nie
zmieni bo chcąć jedna jakoś pomóc blokujesz się niemal na wszelkie
informacje o tym jak to od tej pory było robione. Tym samym to co
ewentualnie zrobisz nie beędzie mogło wyjść w żaden sposób ponad to co już
do tej pory było robiione (będzie to rodzaj wymyślanai koła od pocżątku).
Mówiąc inaczje z tego tyu podejście,m masz sanse cos zrobić .. powtarzajac 
wszyskie błedy jakei do tej pory zostały popełnione.

Niecierpliwisz się .. nie ma sprawy. Patrz że na bugs jest (jednak) sporo
rzeczy które można obrobić. Sporo zapewne masz też do zrobienia i tak w
ramach tego co jest. Zajmując się czymś innym poswól mi, Tomkowi,
Andrzejowi czy może także Jakubowi dopracować to co trzeba zrobiąc to
jednak dość spokojnie.

Sytuacja przypomina tu nieco monet powstania skryptu builder. Powstał on w
sytuacji kiedy inaczej już się porostu nie dało efektywnie robić pakietów,
a całoś bez tego była mocno wyczerpująca. Dzięki temu, że zostało to na
spokojnie zrobione szkielet tego narzędzia po mimo rozbudowania
funkcjonalności w sumie kilkuktornie i to nie tylko przezemnie ale także
przez innych nie uległ faktycznym żadnym istotnym zmianom pozistajać
sytałym fundamentem całej konstrukcji. Na dokąłdnie podobne podejście jest
w tej chwili pora w przypadku automatyki do zarzadzanai budowaniem i takze
całeej "postropdukcji" pakeitów (powtórzż że to włąnie zabierało najwiecej
czasu i w tym wszystkim było najbardziej upierdliwe).

Porostu jest teraz wąłsnie taka pora żeby wysnczyć ntutaj taki na długo 
nienaruszalny fundament ogólnej konstrukcji całości.

kloczek
-- 
-----------------------------------------------------------
*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*



Więcej informacji o liście dyskusyjnej pld-devel-pl