vitamin wrote: > > There better be fixes only! Or what's the point of the freeze? A freeze is to stabilize what one hat or to disregard any bug concerning older versions (so far the user is not reporting that the bug is still there). This excludes all regressions for which the cause was the introduction of a new feature (feature not fully implemented yet). Many regressions are just because something that worked well in the past due to something being skipped is now broken because the new function is not skipped but not 100% implemented. It's also like one of my late regressions. The regression is there because something that installed properly in 0.9.59 is not installing properly for any reason in 0.9.60. Is it a regression or indirectly caused by the work being done on assembly or storage?? I am not a programmer and I know how programmer hate to be told by people not knowing the basics telling them what to do but here my purely simple view of a fix: *finish the work that is in process so that a release does not come out with half implemented functions (if possible). *make a key group of softwares be working well enough to show the work about how great Wine is. *fix regressions due to an incorrect patch, means correcting the patch or the parts tied with it but no unnecessary functions. *polish the work to pass tests by 1000's journalists across the world so that they don't conclude their articles what what is still broken, but what is working. Of course I may be wrong, but Trados or Crysis are both softwares going to bronze on their good days. This is probably not the scope of a freeze so much that I am sorry for it. This is not a time for wondering what's gone wrong. If the user can't describe it so that the developers immediately knows it, that's the wrong patch for a freeze.
