When filing a bug, assuming that it's valid, the acceptable, desired outcome is a verified & deployable fix. In our distro terms, that's a package, made available in a repo -- arguably one of the repos that the system reporting the bug has enabled, and that the OP has verified -- by using/deploying the updated package -- works (within an acceptable response time frame ...). @ Opensuse bugzilla, it's frequently true that bugs are 'closed' when a developer has made changes to code -- without, necessarily, evidence that an OBS request has been made, the package is in a test-repo, &/or that it works for the OP. For example, here are two bugs I've filed where that's occurred (it's an example, not a criticism of the work done/contributed in the bugs ): https://bugzilla.novell.com/show_bug.cgi?id=779087#c28 Bug 779087 - after 12.1->12.2 upgrade, system with ROOT on LVM-on-RAID fails to boot; loops VG not found/partial mode https://bugzilla.novell.com/show_bug.cgi?id=782835#c15 Bug 782835 - Xen HVM Guest fails (errors) to launch on Opensuse 12.2 + Xen 4.2 + 'xl' toolstack Reopening is certainly an option. Reopening is not always well received. The noise created by the open/close/reopen 'dance', and hunting for bug-specific information outside of the bug, simply wastes everybody's time, and, imo, discourages participation/contribution. I'd like to propose (at least for some discussion) that bug process/workflow be changed to require the inclusion/posting of target package info, and an OP-verification step. - ar -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org