Jak to w th będzie (

[Andrzej Krzysztofowicz]

Mariusz Mazur wrote:
> 
> On poniedziałek 07 marzec 2005 11:21, Andrzej Krzysztofowicz wrote:
> > Mysle, ze max. kilkanascie minut.
> > Po prostu wystarczyloby tepic naduzywajacych tego.
> 
> Jedno takie coś by pewnie wprowadziło desynch w serwerach, bo coś by się nie 
> zupgrejdowało, coś na builderze byłoby zainstalowane ręcznie, etc.

IMO wprost przeciwnie. Powodowaloby niwelacje roznic pomiedzy builderami.
Zakladam, ze mechanizm bylby taki:

0. wyinstalowanie _wszystkiego_ oprocz listy ustalonych, nieruszanych pakietow
1. doinstalowanie zaleznosci
2. zbudowanie
3. odeslanie wynikow

Bez tej dodatkowej opcji punktu 0. by po prostu nie bylo.
A punkt ten powodowal by "wyczyszczenie" builderow.

> Inna sprawa, że nie wiem po co to miałoby być?

Np. masz 2 pakiety, ktore maja rozne, wzajemnie konfliktujace BR.
Drugi powod sam przed chwila podales.
Trzecim moze byc sprawdzenie czy nie brakuje BR (ale to, jesli sie buildery
nudza).

> > 1. budowanie w srodowisku / na architekturze, ktorymi deweloper nie
> > dysponuje
> 
> Od tego właśnie są testbuildy w th (ja teraz tego używam do testowania gcc, 
> nic się nie taguje, nic nie jest nigdzie 'oficjalnie' wystawiane).

A jakbys chcial potestowac zestaw pakietow, ktore wzajemnie od siebie zaleza
(tzn. te, od ktorych zaleza tez wymagaja testowania) ?
Np. cale kde...

> > 2. budowanie czegos czasochlonnego (nie kazdy ma czas mozliwosci 
> > zapuscic budowanie czegos na kilkanascie godzin
> 
> Niestety nie sądzę, żeby buildery miały wystarczającą moc przerobową, żeby 
> ludziom zastępować własne maszyny.

Jesli bedzie zapotrzebowanie, to sie znajda.
Oferowalem swego czasu udostepnienie 30 maszyn w godzinach
wieczorno-nocnych...

> > 4. u mnie sie buduje, a na builderze ... ?
> 
> Jak już pisałem, buildery na takie 'ciekawostki' pewnie nie będą miały mocy 
> przerobowych. Ale jeśli to jest 'u mnie się buduje, no to przydałoby się 

Sprawdzales jaki % czasu buildery sie nudza?
Mogly by sie zajac czyms pozytecznym w wolnych chwilach.

> dodać do th', to po prostu puszcza się zlecenie i liczy na to, że się 
> poprawnie zbuduje. A jak nie, to zaczynamy używać test-buildów, żeby nie 
> produkować niezliczonej ilości paczek w 'test'. Zresztą to będę musiał 
> opisać.
> 
> > 5. jakiekolwiek inne powody budowania pakietu w celu jego _testowania_ (np.
> >    przez innych) a nie przenoszenia dalej. Nie kazdy ma jak/gdzie wystawic
> >    wlasne produkty (dysk/lacze/serwer)
> 
> Od tego jest 'test'. Specjalnie w tekście zaznaczyłem, że nie ma żadnego 
> problemu w trzymaniu w 'test' jakiegoś snapshota, który oczywiście 
> bezpośrednio do 'main' nie pójdzie, ale jest prawdopodobne, że jak już 
> wyjdzie wersja stabilna, to i owszem.

A jak to nie jest snapszot tylo pelna wersja, ktora podobno niektorym nie
dziala i ktora probuje poprawic. I nie chce, zeby rm (gdy juz wroci z
balangi/delegacji/wakacji) i wezmie sie za porzadki ja przeniosl? (Nie wiem,
czy mnie zapyta, czy przeczyta poczte itp.)

Poza tym w test juz lezy poprzednia pelna wersja, ktora wlasnie czeka na
przeniesienie (mips konczy ja budowac).

Fantazjuje? Wcale nie. Byly takie przypadki w Ra.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology