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 [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Gdansk University of Technology _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
