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