On 15 June 2015 at 21:59, GOUJON Alexandre ale.goujon@gmail.com wrote:
I don't know how statuses are managed but maybe a tool can be created or improved ? We can provide a mentor when a newbie posts a patch for the first time so that AJ can do other things in the meantime. (or delegate to wine-staging or a kind of sandbox but AJ doesn't like the idea) We could also use the 'sign-off' feature to delegate make a patch verified by a trusted dev (= having a list with domain <-> trusted dev). We can write standard commit rules and patch lifecycle rules so that everyone know where their patch is far from commit.
I've been watching the Wine project for years and a sign-off of sorts is something it really could use imho. There are several areas in Wine which Alexandre hasn't worked on at all and isn't the best person to judge a patch. I've used a "GTM" ("good to merge") system in both very large (wine-like) and very small codebases and projects. It's a type of implicit sign-off and a system that shines best on Github where commenting is cheap.
As a sidenote that's another issue I think: the only communication possible is through email. Email is formal. It's archived, it's spell-checked, it's proof-read and rewritten. So of course there's this huge investment to tell a contributor about something small and silly they're doing in a patch, which they might be completely oblivious to - no answer, frustration, duplication of efforts and sometimes patches are simply lost to that. In the large projects I've managed or been part of, line comments in patches are a huge deal. Being able to tell someone "you're doing something stupid here", rather than an implicit "proof read your patch because of its status in the queue", is a huge deal. Of course we can do that over email but not only do we need the right tools for it (to both do and keep track of), there is also the barrier of entry to email itself I was talking about. 2c
J. Leclanche