[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Looking sponsor for my package - Osmose Emulator



2016-08-30 10:52 GMT+02:00 Gianfranco Costamagna
<costamagnagianfranco@yahoo.it>:
> Hi again Rémi,

Hi Gianfranco,
>
>
>>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.
>
>
> as a start, I did on your git repo:
>
>
> git checkout 0.9.96
> cp of the Debian 0.9.96 code into the repo, and I see already some (not many) differences
> e.g.
> modified:   Joystick.cpp
> modified:   Makefile
> modified:   Osmose-0-9-96-QT.pro
> modified:   osmose/MemoryMapper.cpp
> modified:   osmose/MemoryMapper.h
> modified:   osmose/OsmoseCore.cpp
> modified:   osmose/SoundThread.cpp
>
>
> I'm attaching a patch of the diff
>
> the differences are unzip related, an unistd.h inclusion, typo fixes, and some qt changes,
> you might want to check if some bits are still needed on top of your current master branch
>
> I would save some changes in
> osmose/SoundThread.cpp
> osmose/OsmoseCore.cpp
>
> and
> osmose/MemoryMapper.cpp

Was the Debian 0.9.96 source modified directly instead of being
patched during packaging? I'd have to double check, but I believe
strycore committed the pristine upstream version as first commit in
the lutris fork - I would have assumed the Debian version would be the
same (modulo line endings fixing maybe) with own patches in
`debian/patches`.

At any rate, though it's more cumbersome, it's still interesting to
see what changes were made in Debian directly to the 0.9.96 and see if
some are still relevant to merge on top of 0.9.97. But I reiterate
that using proper patches for each change (e.g. unbundling unzip)
would have been better practice for the changes history (though I
guess I might find those as commits in the Debian git repo if there's
one, I'll have a look).
>
>
> The second patch, is the 1.0 version, diff on top of the 0.9.96 one.
> (so you can see with the same codebase which changes have been done)
>
> I had to use dos2unix and unix2dos to revert some newlines changes
> that were making the diff huge.
> I would like to suggest you to run dos2unix on the whole source tree,
> to avoid such issues in the future.
> this new patch (debdiff) contains some copyright changes, some indentation changes
> and some fixes (the one mentioned by the Debian maintainer).

Note that as mentioned, the 0.9.96 version is the unmodified version
from the original author. For the sake of history and making clear
what changes were made by different author and new maintainers, I
believe it's always best to start from the original source, and apply
changes as patches/commits.

I did fix the line endings in the whole repo back in January:
https://github.com/lutris/osmose/commit/079de6321645a2a23c3ef3fda1af9dbfd6b4bd02
But of course that only applies to the later commits, including
version 0.9.97, and not to the original version 0.9.96.
>
> It would be nice to rebase/cherry-pick this one into the current master, and maybe release
> a new version once the merge is done.
>
> Does it sounds good/helpful for you?
>
> I'm leaving the patches to you all, because I don't want to learn the code since I have
> not a great knowledge on it.

This is definitely helpful, I'll have a closer look at your patches
when I'm home. As for the workflow, since Carlos' fork sadly lacks
history, I think I'll just copy his 1.0 files on top of the master
branch of the lutris fork (which is the same commit as our 0.9.97) and
see from there what would be the extent of the changes that need to be
merged. Once identified, it would probably be best for the sake of
authorship that Carlos (if he agrees) makes a pull request with
distinct commits for each relevant change.

Then we can release a new version after some QA testing has been done.
>
> Hope this helps,
>
> (tl,tr; "patch" is a diff between the two same-called 0.9.96 versions, while debdiff are diff between 0.9.96 with Carlos
> changes, except for the newline fixes)
>
> Gianfranco

Cheers,
Rémi


Reply to: