새로운 우분투 릴리스가 릴리스 될 때 버그 수가 줄어 듭니까? [닫은]
답변:
아니요. 새 릴리스에는 새 소프트웨어와 소프트웨어의 새 버전이 있으므로 완전히 새로운 버그가 있습니다.
새로운 하드웨어는 또한 새로운 드라이버, 새로운 소프트웨어 및 새로운 버그를 도입합니다.
이전 릴리스의 문제를 해결하기위한 새로운 릴리스의 요점이 아닙니까?
소프트웨어를 제거하고 설치 공간이 적은 다른 소프트웨어로 전환하여 버그를 수정할 수도 있습니다 (버그가 적기 때문에 코드에 버그가 적은 경향이 있음).
예를 들어, Gnome에서 Unity로 전환했습니다. 따라서 이전 릴리스에는 Unity와 관련된 버그가 없으며 최신 버전에는 Gnome을 사용하는 우분투 파생물이 여전히 많이 있습니다. 따라서 이러한 Unity 버그로 인해 버그 수가 증가했습니다.
오류 추적기를 들어 본 적이 있습니까? errors.ubuntu.com 으로 안내 하고 ...
예를 들어 우분투 18.04까지는 버그 양이 두 배가 될 것입니다. 우리는 "오래된"Unity7뿐만 아니라 "새로운"Unity 8도 다룰 것입니다. 자체적 인 스타일의 문제 (일명 버그)가있는 완전히 새로운 데스크탑 환경.
흥미로운 링크 목록에 추가하려면 : 버그 런치 패드 에는 태그가있는 버그 목록이 있습니다. 또한 릴리스와 관련된 버그도 포함합니다 (대부분의 버그는 릴리스와 관련이 없을 수 있음).
57 zesty
2346 yakkety
3043 xenial
2382 wily
4415 vivid
37 utopic
2724 trusty
1 saucy
1995 precise
이것을 보면 금액은 릴리스마다 크게 다릅니다. Yakkety는 Xenial 및 Vivid에 비해 꽤 잘하고 있습니다.
우분투 릴리스 당 버그 수를 계산할 수 있다면 (... 10.04, 10.10, 11.04, ...) 줄이 줄어 듭니까?
이것은 감소하는 경향이 있지만 이것은 우리가 이야기하고있는 소프트웨어 개발 입니다. 소프트웨어 개발에 대해 조금 이야기 해 봅시다.
소프트웨어 개발은 과학 이 아닙니다 ! 예술이야!
누군가 소프트웨어를 작성할 때 추측합니다. 그들은 노력하고 있습니다. 그들은 정상적으로 코딩하고 있는데, 불행히도 아무도 예상하지 못했던 버그를 생성하는 경향이 있습니다. 어떤 코드라도 버그가 없음을 보장 할 방법이 없습니다.소프트웨어 개발자는 인간
"잘못을하려면은 인간이다" 속담에도있다. 인간은 완벽하지 않습니다. 그들은 실수를한다. 변수를 변경하는 것을 잊습니다. 그들은 우분투가 충돌하는 이상한 방아쇠를 보지 못합니다.이 경우 소프트웨어 개발은 생명이
나쁘지 않습니다. 우분투에는 자체 업데이트 기능이 있습니다. "아, 이건 100 % 버그가 없어야하고 다시는 바꿀 수 없기 때문에 테스트가 필요하다"라는 생각은 동일하지 않습니다. 나중에 고칠 수 있기 때문에 실수를해도 괜찮습니다. 이것은 의도적으로 버그를 무시하는 변명은 아니지만, 테스트가 일반적이지 않은 이상한 경우를 다루지 않기 때문에 문제가 발생할 수 있습니다. 다른 경우에, 엣지 케이스는 매우 엣지가있어 모든 역사상 두 사람이 그 버그를 유발할 수 있습니다.
이전 릴리스의 문제를 해결하기위한 새로운 릴리스의 요점이 아닙니까?
새로운 릴리스에는 새로운 기능 및 버그 수정이 포함됩니다. 불행히도 새로운 기능은 새로운 버그를 의미합니다.
완벽한 우분투 LTS를 꿈꿀 수 없습니까?
우리는 꿈을 꿀 수 있지만 그뿐입니다. 인간이 작성한 코드입니다. 완벽하지도 않고 완벽하지도 않습니다. 어떤 프로그램도, 특히 우분투처럼 복잡한 것은 완벽 할 수 없습니다 .
오류 추적기 에서이 효과를 시각적으로 볼 수도 있습니다 . 매번 릴리스 할 때마다 다양한 패치 및 버그 수정으로 인해 관리 가능한 수준으로 다시 돌아올 때까지 버그 또는 다양한 급등으로 인한 오류 수.
TL; DR : 죄송합니다. 버그는 소프트웨어 개발의 일부입니다.
각 우분투가 동일한 버전의 구성 요소 소프트웨어에 머물러 있으면 버그 양이 줄어 들지만 우분투를 구성하는 다양한 패키지의 기능을 추가하도록 변경되므로 새로운 버그가 발생할 때마다 도착합니다.
모든 버그를 해결할 수있는 것은 아니며, 더 자세히 살펴보면 일부 버그가 더 많은 버그로 분할되고 일부 버그가 더 적은 버그로 분류되는 경우가 많으며, 대부분 버그가 충분히 설명되거나 반복 가능하지 않기 때문에 개발자에게 제공하지도 않습니다.
또 다른 요인은 사용자 기반이 증가하고 있다는 것입니다. 이는 버그를 발견 할 가능성이 높지만 (사용 시간이 더 길지만) 더 많은 개발자와 동일하지 않기 때문에 버그를 해결하기위한 리소스는 늘리지 않습니다.
또 다른 요소는 우분투가 끊임없이 변화하는 매우 다양한 플랫폼에서 실행된다는 것입니다. 일부 버그는 전적으로 우분투의 결함이 아닌 하드웨어 문제와 관련이 있습니다.
전문 소프트웨어 QA로서 버그가없는 소프트웨어는있을 수 없다고 말할 수 있습니다. 일부 코드로 수행하려는 작업이 버그를 유발하지 않는다는 것을 증명하는 것이 가장 좋습니다. 제로 버그 (사소하지 않은 프로젝트에서)는 여러 가지 이유로 철학적으로 불가능합니다. 가장 큰 시간과 공간 내에서 완벽이 불가능하다는 것이 가장 강력합니다. 또 다른 이유는 버그와 기능의 차이가 보는 사람의 눈에 있다는 것입니다. 버그라고 부르는 것은 개발자에게 기능 일 수도 있고 그 반대 일 수도 있습니다.
그렇다고 우분투 배포판의 품질이 떨어 졌다고 생각하는 것은 아니며 대부분의 상업용 OS가 꿈꾸는 방식으로 새로운 기능과 안정성 사이의 타협에 현실적으로 접근합니다. rinzwind가 게시 한 그래프는 이러한 모든 주요 문제에도 불구하고보고 된 대부분의 버그가 처리되고 일반적으로 해결된다는 점에서 인상적입니다.
보고 된 버그 수는 다음을 기준으로합니다.
- 더 많은 코드 줄 = 더 큰 버그 가능성. Ubuntu는 Linux 커널을 기반으로하며 1 억 5 천 라인 (버전 1)에서 1,700 만 라인 (버전 4.5.4)으로 증가했습니다.
- 더 많은 사용자 = 더 많은 수의 잠재적 인 하드웨어 / 소프트웨어 페어링으로 버그 발생
- 더 많은 사용자 = 버그보고 가능성이 더 높습니다. 버그가 시간의 20 % 만보고되고 5 명의 사용자가 발생하면보고되지 않을 수 있습니다. 50 명의 사용자가 (더 큰 사용자 기반으로 인해)이를 발견하면보고됩니다.
- 새로운 하드웨어 = 더 많은 버그. 인텔 베이 트레일 프로세서, nVidia 카드 및 Radeon 카드와 관련된 모든 종류의 버그가 있습니다. 이것은 4k TV, USB 3.1 및 새로운 하드웨어 개발이 무엇인지와 함께 증가 할 것입니다.
- 더 많은 하드웨어 = 더 많은 충돌 가능성. 각각의 새로운 장치는 자체 장치 드라이버 / 커널 모듈을 가져올 수 있습니다. 모듈이 많을수록 서로 충돌하여 버그가 발생할 가능성이 높아집니다.
- 더 많은 소프트웨어 = 더 많은 충돌 가능성. 사용자층이 증가함에 따라이를 위해 개발 된 소프트웨어의 양도 증가합니다. Apache Open Office는 Libre Open Office와 충돌 할 수 있으며 일부는 스토리지 공간이 저렴한 가격으로 풍부하기 때문에 둘 다 설치하도록 선택할 수 있습니다. 팬 속도를 제어하는 데 사용할 수있는 프로그램이 5 개있을 수 있으며 사용자가 둘 이상을 설치할 수 있으며 서로 충돌하여 10 초마다 시스템 마이크로가 정지 될 수 있습니다.
버그의 수가 증가함에 따라 버그를 수정하는 사람들과 다른 사람들과 솔루션 / 응답을 공유하는 사용자의 수가 증가한다는 점을 명심하십시오.
또한 어떤 경우에는 버그 수가 증가하지 않았지만 버그가 발생한 사람들의 수가 증가했습니다. 또한 앞에서 언급했듯이 버그를보고하는 사람들의 수가 증가했습니다.