[Scummvm-devel] Patch submission workflow

[Max Horn]

Am 05.04.2011 um 07:03 schrieb Julien:

> Hi all!

Hi.

> 
>  
> 
> There was a question from tsoliman today on IRC about how to best submit patches.

Looking at the logs, he actually started by asking whether he should submit both a bug report *and* a patch, separately. The answer to that is: No, just file the bug report, and attach your patch there (and make sure to explicitly mention that you attached a patch that cures the bug ;).


> The current workflow for people that don’t have write access to the main ScummVM tree, as indicated on the wiki, is to submit patches to the patch tracker. Since the switch to git, people can now easily fork the main repository and create pull requests. This IMO makes it much easier to review patches (no need to check manually if the patch applies, easier way to comment and get feedback, etc.).s
> 
> What is other developers opinion on that matter? Should we update the default workflow to allow/encourage pull requests (in addition to a submission to the patch tracker if there is still a need for it)?
> 
> Julien
> 
> PS: If this has already been discussed, can you point me to the thread/irc log so I can update the wiki with information about the new workflow?

This has been discussed in a kind of off-hand manner on this list and on IRC (e.g. when I listed advantages of git over svn, the possibility to more easily maintain little forks, and the ability to submit "patches" via the fork queue / pull requests, was explicitly mentioned). And we already integrated several pull requests.

So, yes, submitting "patches" directly via a github pull request is fine. And for complex stuff, it is actually preferable. However, not everybody is comfortable with git, and therefore we definitely still want to let people use the regular patch tracker.

I guess the current policy is this: To submit changes, either use a patch (as before), or use github's pull request feature. The latter is somewhat preferable, esp. for complex changes. Reasons for that include the ability to comment on things interactively as well as the preservation of history. 
Note: Git pull "requests" outside of github are not included on purpose; as then we'd loose the interactive code review abilities.  


Cheers,
Max