Winetricks: Maintainer: kreyren

[Kreyren]

Requesting write access to winetricks since i want to help with maintainance

[austin987]

I'm not comfortable with that at this time; that's what PRs are for.

[Kreyren]

@austin987 What would make you comfortable with it assuming that i'm making more merge requests then winetricks maintainers are able to process atm? and i have like half that much locally prepared for merge..

[austin987]

This is a volunteer thing for me. I don't have time to review gobs of broken PRs that you send, especially when you 'reserve' issues, open and close them, and generally fill my inbox with a ton of spam. It only encourages me to ignore or look at your issues last.

Just because you want to contribute to something doesn't mean you can demand to be maintainer to do it faster. Try doing that with gcc, firefox, linux, clang, etc. and see how far that gets you.

As with anything open source, you're free to fork it if you want to lead the project in a different direction.

[Chiitoo]

I've been meaning to say that it would probably be better if you work on them pull requests in your own fork first, until you feel they're ready for review (it does make getting feedback at least different, but they probably should be at least tested before bringing them here). This especially goes for 'drafts' and such.

Indeed, everyone watching this repository may get an e-mail for every new comment and commit to pull requests. For a smaller project (maintainer-wise) like this, it has been a big change (at least in my opinion). That's not necessarily a bad thing, but Austin needs to review each one of them while not having too much time for things in general, so I can only imagine it feels even bigger of a change that way.

Maintaining your own fork would probably work the best for you at this point, while perhaps contributing here in a slightly slower pace. ^^

[Kreyren]

I don't have time to review gobs of broken PRs that you send

Well they work when I make a merge request unless it's draft that needs more attention, but you usually take long time that I begin to work on another feature within that contribution instead of making separate that relates on another merge request.

or end-user provides feedback which requires adaptation like origin that get out of hand quickly or league of legends/magic the gathering arena that had changes after update that needs updating.

open and close them, and generally fill my inbox with a ton of spam.

For reasons provided could you recommend a better approach?

There are also best practices that I'm unable to know since project doesn't have any information about these like using W_DEBUG instead of debug naming etc.. I would be willing to make a contributing.md for it if you provide info about expected code practices.

---

@Chiitoo

I've been meaning to say that it would probably be better if you work on them pull requests in your own fork first, until you feel they're ready for review (it does make getting feedback at least different, but they probably should be at least tested before bringing them here). This especially goes for 'drafts' and such.

The issue with testing is that all merges that I make are tested to the best of my ability including different systems and multiple users and I believe that they are mergable at the time when I send them which generally changes with update of either wineapp, its dependency or end-users system which are complicated to keep track of which seems to be more problematic in wine-related projects compared to my usuall practice which seems to be impractical to be applied on winetricks

or what approach would you recommend? assuming that if I maintain a fork then the effort would be probably very conflicting due to the lack of QA and sanity checks for proposed implementation that would be present in fork

like this, it has been a big change

Well that is the main motivation for me to request write since I don't want to bloat winetricks with my merges and generally I like to work alone since then I'm able to do more work assuming that I currently have 29 open merge requests and another merges stashed locally for which Austin would probably hate me if I make a MR for them atm..