Downstream projects & 3rd party / unofficial forks

[skmp]

Unofficial packages

• arch linux has one
• pandora package by @ptitSeb (is this even "unofficial" at this point?)

Direct downstream projects (projects that use reicast as is)

• ?

Closed source downstream projects (closed source projects that use reicast)

• ?

Products that bundle reicast (eg, I think GPD used to package some version built it?)

• ?

Forks with significant code changes

• libretro
• ?

Uncategorized

• RetroArch http://www.retroarch.com/
• RetroPie https://github.com/retropie/retropie-setup/wiki/Dreamcast
• EmuStation
• There's another comercial one somone told me about on FB and I forgot it's name :(

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/61034443-downstream-projects-3rd-party-unofficial-forks?utm_campaign=plugin&utm_content=tracker%2F500311&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F500311&utm_medium=issues&utm_source=github).

[dankcushions]

the retropie fork is here: https://github.com/RetroPie/reicast-emulator

maybe the retropie differences could be incorporated upstream, and then the retropie script could be updated to just build the upstream version: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/reicast.sh#L24

@gizmo98 might have an opinion here!

[gizmo98]

@dankcushions Our fork is outdated. All relevant changes (dispmanx and omx support) were posted and merged upstream. Upstream is running fine on a pi. I had no time to test retropie controller configuration with upstream. Keyboard works fine. If there is no problem retropie script can be updated.

[inactive123]

One of the main reasons I am collaborating here is because I hope in doing so, we can finally get rid of stigmas like 'unofficial forks/ports' when it comes to the libretro core. I hope that we will see much more adoption and support for our project in our collaboration here.

[skmp]

@gizmo98 would be great if you can test that. @twinaphex are the libretro build changes in mainline at all?

[inactive123]

No, it will take many changes to do that. We're looking at a longer-term project there. I am fine with getting it upstream, but it's best to get there by baby-steps, one thing at a time. Give me some time to rebase the codebase on my end first to allow this to be an easier transition.

[skmp]

Also https://github.com/batocera-linux/batocera.linux/tree/master/package/batocera/emulators/reicast might be of interest

[gizmo98]

@skmp checked. Controller works!

[skmp]

@gizmo98 so the scripts can be updated to use upstream directly now?

[gizmo98]

@skmp I have tested an older raspbian jessie installation. When omx and dispmanx support was merged i tested with a raspbian stretch test installation. I will do a final raspbian stretch test with an up to date installation. After that i will do a PR.

[skmp]

@gizmo98 thanks :)

[AbandonedCart]

reicast has a CLA, which typically requires the commit author's signature. This means that any commit returned upstream from a fork of reicast also requires a CLA signature.

This leaves two options for handling the commit. Either attempt to get the original author to put in the extra work of modifying and resubmitting it to reicast or alter the commit's recognized author by resubmitting it with a reference to the original commit (similar to how libretro handles reicast).

Inconveniencing authors and destroying history are unfavorable last resorts to working around a CLA, so is there any benefit to the CLA that outweighs promoting poor use of git?