[Scummvm-devel] Changes in the ScummVM Team and PR approval process

[Peter Bozsó]

Hi all!

I can't agree more with Arnaud and I am also thankful for all the work you
guys have done so far.

All the best,
Peter

On 14 July 2016 at 15:32, Arnaud Boutonné <strangerke at scummvm.org> wrote:

> Hi Eugene
>
> Thanks for this detailed mail about the changes, it's clarifying a lot of
> things.
> I hope we'll still have some good code reviews as we had until now :)
>
> I'm impatient to see the next engine PR to see how it's applied!
>
> Thanks to you and wjp (and LordHoto, but he won't read this mail I guess)
> for your work on the Core Team
>
> Best regards,
> Arnaud
>
>
>
> On Thu, Jul 14, 2016 at 11:31 AM, Eugene Sandulenko <sev at scummvm.org>
> wrote:
>
>> Hi Team,
>>
>> I had a nice chat with wjp over a beer, and we were discussing how we may
>> proceed with ScummVM project since LordHoto left.
>>
>> There are going to be several separate e-mails on the process, so we have
>> enough room for discussion. I am looking for your thoughts and obviously
>> seeking support.
>>
>> So, after almost 5 years of existence of the Core Team, I am declaring it
>> as officially disbanded.
>>
>> In the past, we had the Core Team involved mostly in the OSystem
>> development and architecture, and now that role comes back to the
>> individual developers.
>>
>> That means that there is also an adjustment to the PR approval. Now the
>> (slightly modified) procedure will be as follows:
>>
>>    1. For a sizeable, significant changes it is advised to make a Pull
>>    Request on the GitHub
>>    2. Such Pull Request will have to stay for at least 2 weeks open for
>>    the comments
>>    3. Everyone is invited to comment and review and voice their opinion
>>    (views of non-team members are valuable, but have no decisive power)
>>    4. If there are no unaddressed objections after 2 weeks, the PR could
>>    be merged. Exception could be made if there are suggestions over
>>    refactoring or tidying up the code, granted that they will be addressed
>>    in-tree
>>    5. Immediately after the merge the PR maker ensures that
>>    the buildbot stays happy and is not worsened (historically we had few ports
>>    broken for months).
>>
>> Now on the sizeable changes. First of all, this is up to the discretion
>> of the PR creator, but normally I expect that anything which breaks
>> existing the OSystem API and the Common code, or significantly extends
>> these, especially if it requires more work from the Porters, should go via
>> a Pull Request process. The goal is to ensure that everything stays
>> maintainable.
>>
>> Any developer is free to open the PRs for less significant changes, and
>> that process could be used very well for facilitating discussion and
>> collecting feedback, but when there are no big changes involved, no 2 weeks
>> timeout is enforced.
>>
>> Individual engine sub-teams decide by themselves on the process. As I am
>> aware, currently the SCI development is performed via PRs as well for any
>> sizeable changes. It is up to that sub-team to drop this rule any time or
>> make something even stricter. Just make sure you continue enjoying hacking
>> on the ScummVM.
>>
>> That sums up this change on the Core Team.
>>
>>
>> Eugene Sandulenko
>> ScummVM Team Lead
>>
>>
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning
>> reports.http://sdm.link/zohodev2dev
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20160714/3c4eda26/attachment.html>