Kernel Traffic #144 For 3 Dec 2001

There were 624 different contributors. 296 posted more than once. 244 posted last week too.

Linus Torvalds obwieścił nowinę o ukazaniu się jądra 2.4.15-pre9 i dodał: "Sądzę, że jestem gotów, aby przekazać jądro pod opiekę Marcelo." Anuradha Ratnaweera spytał, czy Linus nie mógłby najpierw "włączyć łatki Tima Schmielau, która daje możliwość obsługi czasu działania (uptime) dłuższego niż 497 dni? To jest fajna cecha, którą zawsze chcieliśmy mieć." Ale Tim Schmielay odparł: "Widzę, że różnice pomiędzy kolejnymi łatami pre są coraz mniejsze. Sądzę zatem, że jest za późno na włączenie tej łaty do 2.4.15. Będę jej pilnował i, ewentualnie, podeślę jej nową wersję Marcelo, gdy będzie to potrzebne." Linus także odpowiedział Anuradha mówiąc:

Właściwie to jestem teraz w ,,trybie poprawiania jedynie błędów które mogą uszkodzić system''. Wszystko, na co potrzeba 497 dni, aby to obejrzeć jest względnie nisko na mojej liście priorytetów. Tak naprawdę, najwyższy priorytet ma to, aby 2.4.15 ukazało się bez większych problemów.

Ponieważ to nie jest tak, że czas się zatrzyma, gdy Marcelo przejmie schedę po mnie. Sugerowałem mu, żeby trochę poczekał, aby zobaczyć, jakie są prawdziwe problemy, ale i tak będzie miał pełne ręce roboty przy włączaniu łat.

Ja przypuszczalnie zrobię to samo: w momencie opublikowania 2.4.15, opublikuję również 2.5.0, które będzie identyczne, z wyjątkiem numeru wersji (to później ułatwi synchronizację). I przypuszczalnie nie zacznę akceptować wszystkich czekających wielkich łat natychmiast. Będę chciał odczekać tydzieñ, czy dwa, aby stwierdzić, czy nie ma jakichś pilnych problemów.

O wiele łatwiej pracować nad łatami WE/WY, wiedząc, że kod, od którego się wychodzi jest stabilny.

Rob Radez nie zauważył ogłoszenia Linusa Torvaldsa na temat 2.4.15, a Frank Davis dodał: "Ja również nie widziałem na lkml ogłoszenia Linusa o ukazaniu się jądra 2.5.0 :)" Do tego Pozsar Balazs dorzucił: "No cóż, facet z jajami po prostu umieszcza plik i czeka aż świat o tym ogłosi :)))"

Tim Tassonis był zaintrygowany numerem wersji jądra 2.4.15: oficjalnie było to jądro ,,2.4.15-tłusty-indyk''. Jeff Garzik powiedział: "Święto Dziękczynienia w Ameryce... może Linus dziękuje, że może w koñcu oddać 2.4 Marcelo :)" Linus Torvalds również odpowiedział Timowi:

To jest kontynuacja wersji ,,tłustej łasicy'' z serii 2.2.x, ale jako że wczoraj w Stanach mieliśmy Święto Dziękczynienia i wiele indyków poświęciło swoje życie w celu uczczenia nowego drzewa 2.5.0, seria 2.4.x została ochrzczona imieniem ,,tłuste indyki'', zamiast łasice.

To może nie wywoływać podobnych skojarzeñ ze śliską szybkością jak łasica, ale wielu ludzi mówi to samo o pingwinie.

Oliver Xymoron odpowiedział, że, jako wegetarianin, musiał załatać jądro tak, aby przedstawiało się jako ,,2.4.15-tłusty-tofundyk, zanim je skompilował. Jamie Lokier dodał: "Bardziej przypadło mi do gustu 2.4.15-smaczna-sałatka."

Marcelo Tosatti, jako opiekun serii 2.4, ogłosił pierwszą przygotowaną przez siebie edycję. Powiedział:

Nadchodzi zatem 2.4.16-pre1. Oczywiście najważniejszą poprawką jest ta związana z iput(), która przypuszczalnie rozwiązuje zaobserwowany problem z uszkodzeniem systemu plików.

Osoby, które dotknęło to uszkodzenie, niech jak najszybciej przetestują to jądro i niech powiedzą mi, czy działa, tak abym mógł opublikować ostateczną wersję 2.4.16 ASAP.

Poprawna synchronizacja iwęzłów w iput() (Alexander Viro)
Konfiguracja rozmiaru pamięci podręcznej stron przy odczycie z wyprzedzeniem przez /proc (było w drzewie -ac)
Poprawki przy kompilacji jądra na PPC (Paul Mackerras)

Odpowiedział sobie minutę później, pownieważ zapomniał podać URL, który teraz pokazał: ftp.xx.kernel.org/pub/linux/kernel/people/marcelo/2.4/testing/. Phil Sorber odpowiedział, że nie widział ogłoszenia na pierwszej stronie http://kernel.org/. Marcelo powiedział, że sądzi, iż H. Peter Anvin, administrator serwera, zareaguje na to dość szybko. H. Peter również odpowiedział Philowi, mówiąc:

pozwólcie, że sobie ulżę...

BĘDĘ KURNA WDZIĘCZNY JEŚLI KTOŚ BYŁBY ŁASKAW MNIE POINFORMOWAĆ O TYCH CHOLERNYCH ZMIANACH CIUT WCZEŚNIEJ!!!!!!!!!!!!!!!!!!!!!!!!

Przy okazji każdej zmiany, coś około 200 luzerów pisze do mnie jakieś bluzgi, i muszę poprawiać skrypty tak szybko jak to możliwe, mimo że miałem inne rzeczy do roboty. Zaczynam mieć dość zgadywania tego, co zrobią opiekunowie jądra, i chciałbym oddać to pod ich rozwagę.

Uznałem, że dobrym pomysłem jest przenieść podkatalog ,,testing'' do katalogu z właściwym jądrem.

Tak więc przeniosłem wszystkie rzeczy testowe związane z 2.5.x do kernel/v2.5/testing, i zostawiłem stary kernel/testing samemu sobie.

Marcelo może zacząć używać starego katalogu (co spowoduje, że jego łaty pre będą się automatycznie pojawiać na kernel.org), lub, co bym zalecał, zrobi to co ja i będzie umieszczał łaty testowe 2.4 w katalogu v2.4/testing (co będzie wymagało dodatkowej pracy ze strony administratora, który jest przypuszczalnie przepracowany z powodów kłopotów z RAID-em ;)

Alan Cox odpowiedział: "Ja też będę używał v2.2/testing, o ile będę tylko o tym pamiętał, gdy zacznę pracę nad 2.2.21pre1."

H. Peter poprosił Alana, aby ten go poinformował, gdy to się stanie; gdzie indziej dodał:

Ten pomysł podoba mi się bardziej niż ten Marcelo, który wymaga nieco dodatkowej wiedzy ad hoc w skryptach -- nawet w tej chwili jest tego za dużo. Postaram się to zaimplementować.

Aby podsumować:

Spodziewam się, że łaty testowe dla v2.5 będą w v2.5/testing, łaty testowe dla v2.4 -- w v2.4/testing, i nic więcej...

(Nie znał jeszcze zamiarów Alana w kierunku użycia tej samej metody dla 2.2, gdy wysyłał tę wiadomość)

Były również sugestie, że seria 2.0 także mogłaby skorzystać na takim traktowaniu. David Weinehall skomentował to tak: "Cóż, jeśli ludzie będą chcieli, umieszczę moje testowe łaty w v2.0/testing." H. Peter był szczęśliwy.

W zupełnie innym podwątku toczyła się mała dyskusja na temat możliwości Linusa względem pielęgnacji jądra, sposobu, w jaki powinny ukazywać się nowe wersje jądra, oraz ogólnego kierunku rozwoju i przyszłości jądra Linuksa. Stephan von Krawczyn sądził, iż problemy wyrosły ze zbyt szybkiego ukazywania się werji jądra, co zaowocowało takimi kwiatkami, jak 2.4.15. Ale Linus odpowiedział:

Tak naprawdę, to sądzę, że to jest jedynie _symptom_ bardzo prostej kwestii: nie lubię pełnić roli opiekuna.

Spójrzmy prawdzie w oczy. Te same problemy mieliśmy w 2.2.x, z tych samych powodów: po prostu nie jestem dobrym opiekunem. Wynika to z tego, że jestem zbyt niecierpliwy i zbyt szybko się nudzę.

Fakt, że tak długo przetrzymywałem 2.4.x, głównie z powodu problemów z VM, na pewno nie pomógł. To sprawiło jedynie, iż byłem _mniej_ ostrożny. Zwłaszcza od momentu, gdy ostatni znany problem z VM został rozwiązany (tzn. blokada z highmem i Oracle) i bardzo się spieszyłem, żeby ,,przekazać Marcelo to piep***ne jądro''.

Znacznie lepiej się czuję rozwijając jądro i to, w czym jestem najlepszy dla Linuksa, to podejmowanie ,,trudnych decyzji'' -- i to nawet nie z przyczyn technicznych, ale dlatego, iż _mogę_ je podjąć bez ryzyka, że zbyt wiele osób będzie oponować. Najlepszym przykładem może być reorganizacja VM, z którą w pierwszej chwili większość się nie zgadzała.

Ale nie jestem dobrym, uważnym, opiekunem. Nigdy nie twierdziłem, że jestem.

Założę się, że dostaniecie lepszą jakość ze strony Marcelo.

Patrick McFarland zasugerował (co wywołało małą wojnę), aby Linus zaprzestał opieki nad jakimkolwiek jądrem, stabilnym, czy rozwojowym. Podczas dyskusji, kilka osób posądziło go o trollowanie. Stwierdził, " Jestem może jedną z 10 osób na tej planecie, które chciałyby, żeby kernel stał się czymś więcej, niż jest obecnie, i pomogłyby w tym. Oczywiście cała ta cholerna społeczność ma ze mną problem, nie zgadzając się z tym, więc chrzanić to. Spieprzyliście sprawę chłopaki." W pewnym momencie, Rik van Riel powiedział:

Nie. Ludzie uważają, że jesteś trollem, ponieważ wszystko, co do tej pory zrobiłeś, to wrzeszczenie naokoło o tym, jak inni powinni wykonywać różne rzeczy lepiej.

Jeżeli pokazałbyś nam kawałek swojej pracy (łatki, dokumentację, wytropione błędy, itp), mógłbyś nas przekonać, że mówisz serio o pomocy w udoskonalaniu jądra.

Patrick odrzekł, że już od jakiegoś roku ma kawałek kodu związanego z MIDI (niekoniecznie związanego z kernelem)

W innym miejscu, pojawiły się spokojniejsze reakcje na oświadczenia Linusa. Mike Fedyk powiedział:

Przyznajesz, że nie przepadasz za opieką. Zauważyliśmy to; niestety jest to prawdą, jeśli chodzi o 2.4.

Osobiście uważam, iż 2.4 zostało wydane zbyt wcześnie. Było to wtedy, kiedy gorączka internetu osiągnęła swoje apogeum i nikt (nawet ja) nie może być obwiniany za to, że dał się porwać przez falę, jaką gorączka ta była.

Chciałbym zasugerować dwie możliwości.

1) Rozwijaj 2.5 do czasu, gdy będzie ono gotowe, aby stać się 2.6, wtedy od razu przekaż je opiekunowi i zacznij 2.7.

2) Rozwijaj 2.5 do czasu nabycia przez nie funkcji, które chciałbyś, aby poszły do 2.6; i przekaż je przyszłemu opiekunowi serii 2.6, aby je ustabilizował i wydał. (w tym wypadku, przez krótki okres czasu, byłyby dwie serie rozwojowe jądra w tym samym momencie)

Przy obu rozwiązaniach, mógłbyś robić to, co chcesz, co Cię nie nudzi, a jednocześnie umożliwił ludziom podzielenie się ich najnowszym kodem, w celu pokazania go dużej widowni.

Linus, czy mógłbyś powiedzieć, czy planujesz zrobić coś podobnego?

To chyba nie o to chodzi.

2.4.0 było dobre na tamte czasy. Problem z _każdym_ poważnym krokiem tkwi w tym, że Wy _naprawdę_ chcecie to testować, ale nie będziecie, póki nie będzie stabilne, a nie można tego ustabilizować nie posiadając rzeszy testerów. W skrócie -- typowy problem typu ,,co było pierwsze? - kura, czy jajko?''.

Tak samo uważacie (choć w mniejszym stopniu), jeśli chodzi o łaty -pre, gdzie o wiele więcej osób koñczy testowanie łat innych niż -pre -- i nieuchronnie jest więcej problemów z ,,prawdziwą'' wersją, niż z łatą -pre. Statystycznie powinniście zdać sobię sprawę, iż nie jest to do koñca prawda ;)

Jeśli chodzi o propozycję rozpoczynania nowej serii rozwojowej bezpośrednio po stworzeniu wersji stabilnej, Linus powiedział:

Chciałbym tak robić, ale działa to niezbyt dobrze. Po prostu dlatego, że zawsze, gdy rozpoczynana jest ,,stabilna'' gałąź, będą problemy, których Strażnik Teksasu nie zauważył, lub nie zdawał sobie sprawy, w jaki sposób dotkną one ludzi w rzeczywistym świecie.

Mógłbym więc przerzucić 2.6 przez płot i zacząć serię 2.7, ale obarczone byłoby to dwoma zabójczymi problemami

(a) Naprawdę nie lubię dawać czegoś kiepskiego komukolwiek, kto będzie opiekunem stabilnego jądra. To po prostu nie ma racji bytu: ktokolwiek, kto chciałby opiekować się takim stabilnym jądrem, będzie frajerem i chłopcem do bicia.

(b) Nawet jeśli znalazłbym takiego kozła ofiarnego, który byłby na tyle inteligentny, aby być dobrym opiekunem, _rozwojowe_ drzewo także wymaga, aby rozpocząć je od jakiegoś ,,uważanego za sensowny'' punktu. Nie musi być doskonały, powinien być _znany_.

Na dobrą sprawę, mamy teraz taką sytuację z 2.4.x -- system wygląda całkiem stabilnie, z niewielkimi tylko problemami, na które są już zresztą rozwiązania, i które nietrudno będzie usunąć. 2.5.x ma więc swój początek w dobrym miejscu, którego nie byłoby, gdybym po prostu uciął wszystko od 2.4.0.

_Prawdziwym_ rozwiązaniem jest robienie mniejszych zasadniczych zmian pomiędzy stabilnymi jądrami i spodziewam się, że takie rozwiązanie będzie stawać się coraz bardziej realistyczne w trakcie stabilizacji jądra. Już teraz uważam, iż 2.5 ma o _wiele_ mniej zasadniczych zmian, niż 2.3.x kiedykolwiek miało -- skalowalność SMP i pamięć podręczną stron różnią się naprawdę znacznie w 2.2.x i 2.4.x.

Ale musisz sobie zdawać również sprawę z tego, że ,,mniej zasadniczych zmian'' to cecha systemu, który nie ewoluuje tak szybko, który osiąga swój średni wiek. Chyba jeszcze tam nie dotarliśmy ;)

Rik wystąpił z silnym poparciem dla zaproponowanego przez Linusa rozwiązania, polegającego na robieniu mniejszych zmian między seriami stabilnymi, a H. Peter dodał, "NAPRAWDĘ chciałbym aby takie założenia weszły w życie. Trąbiłem o tym już od jakiegoś czasu -- mamy 2-3 zbyt długie cykle pomiędzy stabilnymi jądrami, co owocuje zbyt wysokim naciskiem aby ,,dodać swoje właściwości'', zamiast właściwej odpowiedzi ,,uciekł Ci autobus, poczekaj na następny''."

David Relson był zdenerwowany faktem, iż serie stabilne nie były ostatnio zbytnio stabilne i kilka oficjalnych wersji miało poważne usterki. Zasugerował, "Kiedy opiekun kernela, obecnie Marcelo dla 2.4, jest gotowy do wypuszczenia następnego jądra, powiedzmy 2.4.16, sugerowałbym, aby przeszedł z "pre?" do "-rc1" (,,release candidate''). Dzieñ czy dwa z -rc1 szybko pokażą, czy ma ono błędy wstrzymujące wydanie. Jeśli tak, wtedy drobne poprawki (i nic więcej) wędrują do -rc2. Dzieñ czy dwa ..., i mamy albo -rc3, albo stabilną wersję -- 2.4.16 jest gotowe do wydania." Bill Davidson odparł, "Życzę powodzenia. Jakieś 18 miesięcy temu zaproponowałem utworzenie grupy testerów, którzy, przed umieszczeniem źródeł jądra na serwerze ftp, kompilowaliby je na różnych maszynach x86, SPARC{32,64} i ALPHA, aby być pewnym, że przynajmniej się kompilują. Odpowiedziano mi, głównie w sposób nieuprzejmy, że takie rozwiązanie opóźniłoby wypuszczanie nowych wersji (co jest DOBRĄ rzeczą w stabilnych jądrach), oraz że powinienem unikać serii 2.4 i używać ,,stabilnych'' jąder 2.2 (2.4 JEST oczywiście stabilnym jądrem, ale nigdy byś się tego nie domyślił)."

Dan Kegel pochwalił propozycję Davida, zasugerował też, aby przeprowadzać testy kolejnych wersji, przed każdym ,,release candidate'', u chłopaków z Open Source Development Lab. Członek tej grupy, Nathan Dabney, odpowiedział:

Będziemy przeprowadzać wszystkie dostępne testy (dopóki ich lista nie stanie się na tyle duża, iż będzie to niemożliwe) na każdym jądrze, następnego ranka po jego wydaniu. Łącznie z kernelami pre/test/latającamałpa/cokolwiek. Obecnie, testy są wykonywane automatycznie po wypuszczeniu nowego jądra.

Wsteczne testy, które planowaliśmy, to większość prób dostępnych na Linux Test Project (sourceforge:LTP). Nie zakoñczyliśmy jednak procesu ich automatyzacji.

Również Marcelo pracuje już z laboratorium nad niezwiązanymi z stp projektami.

Linux Kernel dorobi się kontroli jakości. Jednakże, tak jak wszystko inne w Linuksowym świecie, nie będzie to coś, do czego jesteś przyzwyczajony. (czytaj: NIE będzie miało miejsca automatyczne wysyłanie raportów o błędach na listę LK.)

Potencjalną niedogodnością, jeśli chodzi o oczekiwanie na zakoñczenie testów, przed przystąpieniem do sprawdzania kolejnych wersji jest fakt, że jakkolwiek wszystkie testy są rozpoczynane następnego ranka po pojawieniu się jądra na kernel.org, mogą one trwać przez kilka dni. Dzieje się tak z powodu innych, zakolejkowanych testów, lub testów, które trwają dłużej niż dzieñ. Mając to na uwadze, kierowałbym się ku małemu zestawowi doświadczeñ, który może być rozpatrywany jako ,,sprawdzenie, czy się nie iskrzy i nie dymi'' w jądrze, w celu sprawdzenia krótkiej listy elementów zapewniania jakości, przed rozpoczęciem szczegółowych badañ danego jądra. Ta krótka lista obejmowałaby zarówno większość spraw związanych z kompilowaniem/uruchamianiem, jak i, w ograniczonym zakresie, problemy ze sterownikami, oraz przyzwoitą ilość obszarów wydajności komponentów jądra. Widzę potencjał w działaniu STP w tle, w stosunku do działañ rozwojowych i ujawnianiu się na liście LK tylko wtedy, gdy zauważymy jakieś problemy, lub inne sprawy godne skomentowania. Nie widzę żadnych korzyści z kontrolowania ani kierowania prac rozwojowych przez cokolwiek, co proces kontroli jakości robi, lub czego nie robi.

Jest to ciągła gra wychwytywania i weryfikacji. Dobrze, że przynajmniej narzędzia są coraz lepsze.

W związku z problemami w jądrze 2.4.15, wypuszczam 2.4.16.

Lista zmian:

wersja ostateczna:

Naprawiony oops w 8139too (Philipp Matthias Hahn)

pre1:

Poprawna synchronizacja i-węzłów w iput() (Alexander Viro)
Konfiguracja rozmiaru pamięci podręcznej stron przy odczycie z wyprzedzeniem przez /proc (było w drzewie -ac)
Poprawki przy kompilacji jądra na PPC (Paul Mackerras)

Dominik Kubla zawiwatował, ale Anuradha Ratnaweera zasugerował, że Marcelo, zgodnie z wytycznymi, powinien wypuszczać finalną wersję, jako identyczną w stosunku do ostatniej wersji pre-. Później, w tym pod-ątku, Helge Hafting odpowiedział:

Te ,,wytyczne'', to uproszczenie, które nie jest potrzebne.

Można w sposób trywialny udowodnić, iż ta poprawka nie pogarsza spraw, więc nie ma powodu, aby ją omijać. Takie ,,wytyczne'', ,,reguły kciuka'', itp, są dla kierownictwa i innych, którzy nie posiadają szczegółowej wiedzy. Ci, którzy wiedzą lepiej, nie powinni być ograniczani takimi zasadami. I nie są. :-)

Naturalnie, możnaby zapisać szczegółowe zasady, na które zgodziliby się nawet doświadczeni programiści -- ale po co? Nie udałoby Ci się streścić tego w kilku linijkach...

W związku z sugestią Anuradha, Alan Cox odparł, że takie subtelności nie są wcale potrzebne, "kiedy łata jest całkowicie oczywista, a poza tym istnieje potrzeba wypuszczenia danej wersji." Również Rik van Riel powiedział, "Ta poprawka do 8139too to JEDNA LINIJKA, w zawierającym się w sobie fragmencie kodu." Anuradha stwierdził, że tak czy inaczej, najlepszym sposobem uniknięcia niejasnych sytuacji byłoby wdrożenie wyraźnych wytycznych, lecz H. Peter Anvin powiedział, "Przykro mi, ale właśnie przekroczyłeś granicę rozsądku w tym, czego można wymagać od innych. Jeżeli nie ufasz opiekunom i chcesz utrzymywać takie wytyczne, stwórz swoją własną gałąź jądra i opiekuj się nią." Andreas Jaeger dodał:

To Marcelo decyduje, co jest ok, a co nie. On jest za to odpowiedzialny. Jeśli chcesz mu dać przyjacielską radę -- nie widzę problemu, ale nie uważam, że masz prawo *określać*, co dla Marcelo jest dobre, a co nie.

Czytając wątki na lkml na temat opieki nad jądrami, odniosłem wrażenie, że kilka osób stara się wymusić coś na Marcelo bez dania mu szansy zrobienia tego po swojemu. Wierzę, że Marcelo postąpi słusznie.

Czy moglibyśmy teraz wrócić do kodowania i testowania?

Anuradha odparł, że on również ufa Marcelo, i tylko omawiał swoje przemyślenia na ten temat.

Także Marcelo odpowiedział na pierwszy komentarz Anuradha, mówiąc, że tamta poprawka była naprawdę bardzo mała i z całą pewnością prawidłowa; Anuradha się z nim zgodził.

Olaf Hering wysłał na listę łatę do 802 na jądro 2.4, umieszczając w Cc: Linusa Torvaldsa i Marcelo Tosattiego. Marcelo odpowiedział, "Chciałbym, aby poprawka przyszła do mnie od opiekuna 802."

Z technicznego punktu widzenia, nie ma teraz takiej osoby. W sumie, ten kod pochodzi z części ,,networking'' i wygląda na to, że będę to ja.

Osoba, która pierwotnie napisała rzeczy związane z 802, już się nie udziela i widnieje tylko na liście zasłużonych.

David Relson podziękował Marcelo Tosattiemu za przejęcie opieki nad 2.4 i za wydanie 2.4.16; zapytał, "Przez ostatnich kilka dni pojawiło się wiele listów na temat ,,Wypuszczania kolejnych wersji jąder'' i ,,-preX vs. -rcX''. Ty, jako oficjalny opiekun jądra 2.4, jesteś osobą, która tworzy takie wytyczne i wprowadza je w życie. Czy mógłbyś podzielić się z nami swoim zdaniem na ten temat?" Marcelo odparł:

Przepraszam, że nie jestem w stanie dyskutować nad tymi sprawami. Jestem po prostu zbyt zajęty opieką i innymi zajęciami w Conectivie (ludzie zasypują mnie łatami, btw, przerwijcie to na chwilę).

Daniel Quinlan zasugerował mi wypuszczanie wersji ,,pre-final'' przed wersją ostateczną (co pozwoliłoby wychwycić większość ,,głupich'' błędów), uważam, że jest to dobry sposób rozwiązania problemu.

_Prawdopodobnie_ tak zrobię -- nie jestem jednak tego pewien.

Czy nie wszystkie -pre są -pre-finalnymi? Co będzie, jeżeli w -final zostanie znaleziony jakiś duży błąd? Zakoñczy się to wydaniem -final-final?

Podobają mi się metody ISC. Wypuszczają oni -rc'ki (-pre byłyby ok dla jądra, ponieważ jest już takie nazewnictwo), każde -rc poprawia błędy znalezione w poprzednim. Kiedy -rc jest już upublicznione wystarczająco długo i nie ma żadnych raportów o błędach -- wypuszczają ten kod, BEZ zmian.

Tylko -pre-final to -pre-final. :)

-pre-final zasadniczo znaczy, że jest to ,,kandydat'' na wydanie jako finalna wersja.

Mógłbym je nazwać ,,kandydat'', czy jakkolwiek inaczej (nie interesuje mnie zbytnio nazwa).

H. Peter Anvin spostrzegł, "Jeżeli uregulujecie sprawę nazewnictwa, powiadomcie mnie *proszę* wcześniej, abym mógł zaktualizować skrypty śledzące, zamiast dowiadywać się o tym poprzez setki skarg w mojej skrzynce pocztowej..."

David Weinehall objaśnił swój własny system, " Używałem nazewnictwa -pre i -pre-final przy serii 2.0.39 i prawdopodobnie użyję takiego samego schematu przy ostatecznych łatach do 2.0.40, _chyba_, że są jakieś ustalenia co do innego nazewnictwa. Byłbym całkowicie zadowolony, używając w zamian schematu -rc dla wersji ostatecznych. Ważną rzeczą jest nie sam schemat nadawania nazw, lecz spójność pomiędzy różnymi drzewami jądra." H. Peter odpowiedział, "Spójność to Bardzo Dobra Rzecz [TM] (słowa tego, który próbuje nauczyć skrypty nazewnictwa). Zaletą schematu -rc jest fakt, iż unika się fenomenu -pre5, -pre6, -pre-final, -pre-final-naprawdę, -pre-final-naprawdę-teraz-mówię-serio, jeżeli ,,release candidate'' nie był całkiem udany; po prostu wydajesz -rc1, -rc2, -rc3. Nie wstyd jest potrzebować więcej niż jednego ,,release candidate''." Marcelo odparł, " Zgoda. Będę trzymał się konwencji -rc dla 2.4+..." H. Peter odpisał, "Poprawiłem skrypty na kernel.org, aby rozpoznawały schemat nazewnictwa -rc. Jakakolwiek znaleziona łata -rc jest uważana za nowszą niż jakakolwiek łata -pre. Postaram się dodać śledzenie drzew 2.0 i 2.2 za kilka dni." David Weinehall stwierdził, że będzie używał takiego nazewnictwa dla serii 2.0.

Oliver Xymoron zapytał, czy ktoś zna jakieś narzędzie, "które pozwoliłoby dyskowi/sterownikowi SCSI wykazać swoją funkcjonalność " , w celu użycia go do testów regresyjnych. Marcelo Tosatti odparł, "Cerberus (narzędzie do testów wytrzymałościowych, powinieneś znaleźć je na freshmeat.net) potrafi wykonać SCSI ,,burn test''." Oliver stwierdził, że się temu przyjrzy. Również Andre Hedrick odpowiedział na początkowe pytanie Olivera, mówiąc, "Któregoś dnia zabiorę się za poprawianie SCSI, aby miało niskopoziomowe wejście diagnostyczne do testów, lecz narazie nie mam na to czasu... przepraszam." Ale Olivier odparł, "Myślę, że interfejs sg jest wystarczający, jeśli chodzi o moje potrzeby."

Oto następny. Jeśli nie dostanę więcej żadnych łat, to następna łata bedzie pierwszym kandydatem do wypuszczenia przed v2.0.40

2.0.40pre3

Poprawiona literówka w sched.c, tym razem naprawdę; ostatnio zaaplikowałem tę łatę do niewłaściwego drzewa, dlatego została odrzucona (Tim Sutherland)
Łata do sondowania IDE dla niektórych napędów ATAPI (Geert Van der Plas)

Stefan Smietanowski (prawdopodobnie przy wykonywaniu skryptów parsujących pocztę elektroniczną), zauważył, ze David w linii ze słowem Subject: podał numer wersji jako "2.0.40-pre3", a w treści wiadomości "2.0.40pre3". Stefan sądził, że David ostatnio zgodził się na używanie formy z myślnikiem. David odparł, "Używam jej w EXTRAVERSION w Makefile." Stefan spytał, czy jest jakiś powód, dla którego nie można używać jej wszędzie, a David odpowiedział, "Nie, to raczej kwestia myślenia o tym :-)" Koniec wątku.

Marcelo Tosatti ogłosił 2.4.17-pre1. Andrey Nekrasov zauważył, że łatka nie zaktualizowała numeru wersji. Marcelo odpowiedział, "Tak. Zapomniałem tym razem tego zrobić, przepraszam. Mam nadzieję, że to się nie powtórzy." Tommy Reynolds odpowiedział, "Nie ma nic złego w robieniu błędów tak długo, jak są one nowe ;-) "

W innym miejscu Mike Fedyk zapytał Marcelo, "Czy jest jakaś szansa, że dodasz łatę netdev-random Roberta, poprawiającą równomierność, jako domyślnie wyłączoną? " Ken Brownfield zduplikował tę propozycję, a Robert Love podał odnośnik do łatki. Marcelo napisał Mike'owi, "Nie wiem. Muszę przeczytać łatkę... " Koniec wątku.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	21 Nov 2001 - 26 Nov 2001	(20 posts)	Rozgrzewka przed 2.5 i przekazanie jądra Marcelo
2.	23 Nov 2001	(3 posts)	Rozpoczyna się 2.5
3.	23 Nov 2001	(6 posts)	2.4 przechodzi w ręce Marcelo
4.	24 Nov 2001 - 27 Nov 2001	(105 posts)	Marcelo przejmuje 2.4
5.	24 Nov 2001 - 28 Nov 2001	(35 posts)	Zapewnienie stabilności serii stabilnej
6.	26 Nov 2001 - 29 Nov 2001	(20 posts)	Sugestie dla Marcelo
7.	26 Nov 2001	(15 posts)	Krótka dyskusja na temat zasad wysyłania łat do 2.4
8.	26 Nov 2001 - 28 Nov 2001	(47 posts)	Wytyczne dla wersji 2.4
9.	26 Nov 2001	(5 posts)	Narzędzie do przeprowadzania testów regresyjnych sterownika SCSI
10.	26 Nov 2001	(5 posts)	Przygotowania do 2.0.40
11.	28 Nov 2001 - 29 Nov 2001	(13 posts)	Przekazanie 2.4: sagi ciąg dalszy

Kernel Traffic #144 For 3 Dec 2001

By Zack Brown

Translated By: Jakub Jankowski , Maja Królikowska and Paweł Kot