Line 1: |
Line 1: |
| | | |
− | flags
| + | The template layout for bug verification differs from that template proposed here: http://wiki.contribs.org/SME_Server:Documentation:QA:Verification Which is it to be? [[User:Trex|Terry Fage]] ([[User talk:Trex|talk]]) 00:04, 27 February 2013 (MST) |
| | | |
− | what do the -+? mean, when do you set them, if in doubt just use + ?? <br>
| + | Donno Terry ... Just come across this page and the one over in documentation. As posted into devinfo: |
− | not sure why we have some of the flags, check comments below
| |
| | | |
− | [[User:Snoble|Snoble]] 21:54, 8 April 2007 (EDT) | + | What would be really useful and lower the barrier imposed (for good reasons) by having to use it would be a version with guidance for each section that can be copy 'n pasted into bugzilla. |
| + | |
| + | The full example on http://wiki.contribs.org/Bugzilla_Help#Verifying_Bugs is close to meeting that requirement. |
| + | |
| + | By "guidance" I mean the commands to run to gather the system information, or show the version of the affected package, for example |
| + | <pre> |
| + | = ENVIRONMENT: |
| + | Post the output from these commands: |
| + | cat /etc/*-release |
| + | uname -mrs |
| + | /sbin/e-smith/audittools/newrpms |
| + | </pre> |
| + | Some of the other fields ought to be marked optional. If I'm only verifying a bug I don't have enough information to get involved in changelog entries, release notes or documentation. I also feel it's up to some one further up the tree to set bug flags.[[User:Allsorts|Allsorts]] ([[User talk:Allsorts|talk]]) 11:20, 6 January 2015 (CET) |