When to mark a bug as STAGED

KKing kicking177 at gmail.com
Tue Nov 7 04:57:12 CST 2017


<<
IMO, the real question is why dead-end hacks are being included in 
staging in the first place.
 >>
IMO: If not in staging, then there should be an alternative place for 
such hacks or patches, ideally that the AppDb can point to.
People go to the AppdDb to see if an app they want or need can run ...
They'll be more impressed and potentially get involved in Wine more in 
some way if it helps them.
You can make all sorts of usual disclaimers about not part of pure 
process and may break at anytime etc.
Accepting such hacks (somewhere) can potentially introduce a wider 
developer (of varying Wine based aptitude) base to draw from.
The hack could provide a basis for either progressing/converting it to 
non dead end approach by either mentoring the original author(s)
Or providing stimulus for another to take on and submit a more 
acceptable patch.
The hack may also allow sight of further bugs down the line in the 
app(s) it was intended for, which sometimes helps with tackling the 
original issue(s) and the solution approach.

<<
IMO if the patch solves the bug for a user, and the patch is in
staging, it should be marked STAGED. The whole point of staging is
that the patches may not be up to par, but are good enough for some
purpose. If Office works and it didn't before, I'd say that standard
is met.
 >>
+1
Ken.



More information about the wine-devel mailing list