Launchpad Entry: hhd-test-livecd
Alongside the memtest option it would be great to be able to do a pre-flight test of the health of the hard disk, possibly including SMART statistics and a full read test and performance test of the drive(s).
Helpful for a new install, or diagnosing problems with an existing install. Sometimes people come to Ubuntu following a bad experience with unreliability on other operating systems, if the underlying issue is a bad drive then it would be good to identify this in advance so that Ubuntu does not get mistaken for the cause of problems experienced - which will probably be perceived as worse than the previous OS if the drive is deteriorating.
- Jamie is frustrated with constant crashes and data loss on Windows. In frustration he upgrades to Ubuntu, but shortly afterwards experiences progressively worse crashes, data loss and finally an inability to boot. He ends up with a perception that Ubuntu is worse than Windows for reliability, however the underlying cause is a deteriorating hard disk affecting both operating systems, but Ubuntu appears worse as it does not have the benefit of any time on a reliable platform.
- Peter is about to install Ubuntu on a new computer and wants to check the health of the computer before installation
- Amy sells computers with Ubuntu pre-installed and wants to ensure that her customers get a computer that is reliable and doesn't come back. She is happy to spend time doing a full soak test before sale.
This proposal is to select and use existing tools rather than build a new testing tool. Possibly a CLI based tool that can run from the grub menu like memtest86. Alternatively a GUI tool that runs from a fully booted liveCD desktop. http://www.coker.com.au/bonnie++ smartmontools http://www.howtoforge.com/checking-hard-disk-sanity-with-smartmontools-debian-ubuntu provides useful data, but a better user interface would be desirable for the livecd
The summary should not attempt to say why the spec is being defined, just what is being specified.
This should be the description of why this spec is being defined.
Scope and Use Cases
While not always required, but in many cases they bring much better clarity to the scope and scale of the specification than could be obtained by talking in abstract terms.
Use cases are positive statements which (loosely) conform to a pattern like
- A person and their role
- The objective they want to achieve
- The steps they go through
- The positive result
Specifically, describing the current unsatisfactory state of affairs is not a use case; that belongs in the Rationale section.
This section is usually broken down into subsections, such as the packages being affected, data and system migration where necessary, user interface requirements and pictures (photographs of drawings on paper work well).
To implement a specification, the assignee should observe the use cases carefully, and follow the design specified. He should make note of places in which he has strayed from the design section, adding rationale describing why this happened. This is important so that next iterations of this specification (and new specifications that touch upon this subject) can use the specification as a reference.
The implementation is very dependent on the type of feature to be implemented. Refer to the team leader for further suggestions and guidance on this topic.
The specification process requires experienced people to drive it. More documentation on the process should be produced.
The drafting of a specification requires English skills and a very good understanding of the problem. It must also describe things to an extent that someone else could implement. This is a difficult set of conditions to ensure throughout all the specifications added.
There is a lot of difficulty in gardening obsolete, unwanted and abandoned specifications in the Wiki.