Raport na temat błędów krytycznych dla wydania (nr 04)
Kontynuujemy publikowanie cotygodniowych statystyk błędów krytycznych dla wydania.Na zakończenie 04-ego tygodnia tego roku kształtują się one następująco:
- błędów ogółem: 888,
- dotyczących Wheezy'ego: 287,
- występujących tylko w Wheezym: 79,
- oczekujących na naprawę w Wheezym: 208.
Spośród tych oczekujących na naprawę w gałęzi testowej:
- w toku: 20,
- załatane: 59,
- duplikaty: 32,
- mogą zostać naprawione poprzez mechanizm aktualizacji bezpieczeństwa: 23,
- występuje w sekcji contrib lub non-free: 1,
- ktoś obiecał się nimi zająć: 5,
- naprawione, lecz uaktualnione pakiety jeszcze nie zostały dodane do archiwum: 3,
- naprawione w inny sposób: 17.
Pomijając powyższe (niektóre błędy mogą być przypisane do kilku przypadków), do wydania Debiana 7.0 Wheezy naprawione muszą zostać 93 błędy (tyle samo co tydzień temu).
Jednakże z punktu widzenia osób odpowiedzialnych za wydanie należy wyeliminować jeszcze 206 błędów (1 mniej niż tydzień temu).
Wyk.1. Liczba błędów krytycznych dla wydania
Informacje na temat błędów czerpane są z Wielkiej bazy danych Debiana (UDD). Znaczenia poszczególnych pozycji można znaleźć na wiki Debiana.
Dodany: 25 sty 2013 o 12:18
przez: ArnVaker
Komentarze (RSS):
Kompletny zastój, wcześniej przynajmniej większa wartość wciąż malała :(
To nie ja, bo ja jak ostatnio sprawdzałem to spadało ;)
Spadało _do_ momentu, w którym sprawdziłeś, potem wzrosło. ;)
A idźcie cholerka jasna, zamiast spadać zaczęło rosnąć ;)
Co wydanie to więcej pakietów w wydaniu i architektur więc czas mrożenia się wydłuża
Co racja to racja.
"Yampress, 2013-01-26 11:16 [#]:
Co wydanie to więcej pakietów w wydaniu i architektur więc czas mrożenia się wydłuża"
Przydałaby się nowa gałąź rolling release. Jeśli mnie pamięć nie myli, to miała powstać, ale projekt chyba umarł.
Co wydanie to więcej pakietów w wydaniu i architektur więc czas mrożenia się wydłuża"
Przydałaby się nowa gałąź rolling release. Jeśli mnie pamięć nie myli, to miała powstać, ale projekt chyba umarł.
Albo prościej by było gdyby Sid po prostu nie zamierał na czas mrożenia wersji stabilnej.
To na czas mrożenia powinno pojawiać się takie dodatkowe repo dla testinga, gdzie deweloperzy mogliby wrzucać swoje poprawki dla pakietów, a one po odleżakowaniu wędrowały by do przyszłej wersji stabilnej. Sid pozostałby otwarty i na czas mrożenia pakiety nie wędrowały by do testinga ;)
Nadal by się wydłużało — deweloperzy zamiast pracować nad wydaniem pracowaliby równolegle nad unstable i „frozen-unstable”.
I tak są już testing-updates oraz testing-proposed-updates. Mnie się podobała propozycja żeby Rolling oraz Sid były gałęziami ciągłymi, a co jakiś czas z Rollinga wydzielany był Testing, gdzie odbywałoby się jego przygotowanie do wydania jako Stable. No ale wiadomo jak jest – nie ma komu po prostu. :)
A tak w ogóle to tak mi się skojarzyło pewne powiedzenie. Parafrazując: wszyscy użytkownicy Debiana są ekspertami od rozwijania dystrybucji. ;)
Niektórzy po prostu trochę żałują, że szumnie zapowiadany CUT/Rolling nie wypalił. To nie był wymysł użytkowników, tylko deweloperów.
84/206, nagle spadlo :)
79/198 spada
Po prostu w Cambridge trwa BSP:
http://wiki.debian.org/BSP/2013/01/gb/Cambridge
:)
http://wiki.debian.org/BSP/2013/01/gb/Cambridge
:)
65/181 - i to jest postęp, tak trzymać ;)
"Po prostu w Cambridge trwa BSP" BSP a co to jest?