Re: Looking sponsor for my package - Osmose Emulator
2016-08-30 8:46 GMT+02:00 Gianfranco Costamagna <email@example.com>:
>>I don't think it's the Debian policy to fork and maintain separately
>>projects which are already being maintained elsewhere, and especially
>>not for the sole benefit of Debian. If every distro maintainer started
>>forking all upstream projects for their own distro, the libre/open
>>source ecosystem would have a hard way providing interesting
> it isn't the Debian policy, but an honest mistake in my opinion :)
I agree :)
>>Now, I haven't checked the source code of your fork and it might be
>>superior technically, but I find it sad that you blatantly ignored my
>>invitation months ago to have a look at the lutris fork and contribute
>>their to help maintain this emulator.
>>Hopefully you'll continue developing osmose further and we can soon
>>drop the lutris fork and use yours as new upstream...
> no. You have more forks, and an older project (and better maintained, with
> a clean git history).
> Carlos, my proposal (if upstream accepts) is to move your development fixes
> into their fork, and move the Debian packaging into lutris.
> I don't really care about *which* fork is superior, at the end
> we should (whenever possible) have *one* single superior fork :)
I agree that both repos should ideally be merged. Whether hosted by
the lutris GH organization, Carlos, or a new `osmose-emulator` GH
organisation, I don't have a strong opinion.
Given that the lutris fork has indeed a better git history (without
the original upstream history though, but I think the previous
upstream only provided tarballs, no version control), it would indeed
be a better base to start from. Then Carlos' relevant developments
could be merged into this repo, and we could roll a 0.9.98 or 1.0
To give some context about the lutris fork, it was not created with
the intent to further develop the emulation features itself, but to
fix the buildsystem, port the emulator to Qt5, clean the codebase a
bit and do some general maintenance. This was initially done for
lutris' own static packaging needs, but I then helped to improve the
distro packaging aspects so that I could package it for Mageia .
If Carlos intends to further develop the emulation features itself, I
assume he could soon take over the lutris fork with strycore and I
staying to do the minor maintenance we intended to keep doing for the
sake of packaging.
> BTW also other distributions have still the 0.9.96 version (I looked at arch linux
> as example).
> Can you please ping the respective maintainers about your new fork?
> Moving into a better codebase is something that in Linux is done a lot, but
> sometimes a little bit of advertising avoids people forking or leaving old code
> around the distros
> (I'm speaking with my maintainer hat, I always appreciated a maintainer pinging me
> about some new fixes, or some repository moved around, otherwise my Debian tools will
> point to the old version, and I won't notice a new release somewhere else)
As a (Mageia) maintainer myself, I fully agree. Back when we released
0.9.97 I packaged it for Mageia, but also did not find many distros
having proper packages for osmose  (Debian was not on this list
back then, and I'm not sure why Arch doesn't show either, it does for
openSUSE's and Slackware's packages seem very old so probably
unmaintained, but I'll try to find their contact info nevertheless.
About the ROSA packages, I don't know which of those releases are
still maintained, but I'll ask some OpenMandriva maintainers, they
Ideally we would sort out the dual fork situation before announcing a
new maintainer though - given Debian/Ubuntu's influence, Carlos' fork
and packaging in Debian and Ubuntu is already all over the search
results in Google and DuckDuckGo and very well obfuscates the small
lutris fork ;)
> thanks you both, I really hope we can sort this out soon, for the benefit of everybody :D
If Carlos agrees, I'll start an issue on the lutris fork to notify
strycore (current lutris maintainer) of this discussion, and start
investigating how to merge the two branches together.
Rémi / Akien