<< 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.
On 7 November 2017 at 14:27, KKing kicking177@gmail.com wrote:
IMO: If not in staging, then there should be an alternative place for such hacks or patches, ideally that the AppDb can point to.
Traditionally we've just attached those kinds of hacks to the corresponding bug report.
On Tue, 7 Nov 2017 15:28:11 +0330 Henri Verbeet hverbeet@gmail.com wrote:
On 7 November 2017 at 14:27, KKing kicking177@gmail.com wrote:
IMO: If not in staging, then there should be an alternative place for such hacks or patches, ideally that the AppDb can point to.
Traditionally we've just attached those kinds of hacks to the corresponding bug report.
There was also the old repo at http://repo.or.cz/wine/hacks.git, which had the advantage of making it clear to users that they were hacks. The problem I have with marking hacks as STAGED is that will create an endless procession of users asking when the fix that has been STAGED for x years is finally going to be included in Wine. The distinction Sebastian has been trying to make between hacks and patches being worked on has not been made clear enough to users--they should not have to hunt through an outside website to find that out--but IMO it is a useful distinction.
On 7 November 2017 at 22:12, Rosanne DiMesio dimesio@earthlink.net wrote:
There was also the old repo at http://repo.or.cz/wine/hacks.git, which had the advantage of making it clear to users that they were hacks. The problem I have with marking hacks as STAGED is that will create an endless procession of users asking when the fix that has been STAGED for x years is finally going to be included in Wine. The distinction Sebastian has been trying to make between hacks and patches being worked on has not been made clear enough to users--they should not have to hunt through an outside website to find that out--but IMO it is a useful distinction.
Sure, the distinction is useful. I think ideally we'd make that distinction by not putting dead-ends in staging though.
-
Henri Verbeet -
KKing -
Rosanne DiMesio