Bug#788061: Bug#788057: game-data-packager: please add support for Blake Stone: Aliens of Gold and Planet Strike

[Manuel A. Fernandez Montecelo]

(I am "replying all", but I don't know if all of you are interested in
this, please let me know if it's not so and I'll remove you from
future e-mails).


2015-07-01 1:27 GMT+01:00 Braden Obrzut <admin at maniacsvault.net>:
> On 30/06/15 14:40, Manuel A. Fernandez Montecelo wrote:
>>
>> I have had a look at some of the patches, not in much detail though
>> (I'm in a bit of a rush in the last few weeks).
>>
>> Perhaps some of them, at least the most simple and obvious, should be
>> (if not done already) reported in the bug tracker, attaching the
>> particular patch fixing the issue.  I saw upstream happily accepting
>> patches in the past (although they are a bit slow to react sometimes).
>>
>> So Braden already did the right think in trying to upstream his
>> changes, but breaking them down to small pieces for individual
>> consideration will help a lot in the process, I think.
>
> That's why I posted on the mailing list.  If there's anything in there that
> would be accepted, I can break it out.  But it just wastes my time to break
> out patches for everything and have them be denied.

To me it look like a chicken-and-egg problem -- upstream does not have
the time or mental energy to look at it because it is too much to
digest at once (it happened to me when skimming over it), you don't
want to make it easier to digest because you are not sure if they will
like it and don't want to waste your time.

It's always a tradeoff -- there's never a guarantee that it will be
accepted even if you split it in smaller chunks, but it usually makes
things more likely.  On the other hand, if you don't make it easier
for upstream to look into it, it is less likely that upstream goes and
picks it up.  This in turn might make things more difficult or easier
for you in the future (e.g. conflicts merging would make it more
difficult, but making sure that your patches don't change makes it
easier to know that it will work for you).

If I were you, I would at least submit a few requests to their
bugzilla to merge parts fixing the most straightforward / glaring /
serious issues, just pointing to your git repo or attaching a patch,
and see what happens.


> I suppose what frustrates me a little about the situation is that if I
> merged that source code into the ECWolf tree and didn't mention it, it would
> be packaged without a second thought, but since it's a separate repo in
> order to allow me to trivially merge any changes from upstream it's a big
> deal.  To be clear, I'd never suggest that Debian provide the library in a
> separate package.  Only statically linking. ;)  But I'm glad that you guys
> are even considering packaging it at all.

To be clear, I am not considering packing this fork, at most I would
select some patches.  And it's happening to me the same as I explain
above about upstream -- I lack the time / energy / motivation to spend
one or more afternoons looking at the patches, trying them and
deciding if to ship them or not.  SDL upstream must have more interest
in seeing fixes and improvements for their project than me, but still
I suspect that this might be a factor explaining why they didn't reply
yet.


Also, if ECWolf included the source but didn't mention it, it would
most probably be detected by the maintainers and automatic tools and
would make it more difficult to get accepted, or people from central
teams like Release or Security could reject it altogether (e.g. as it
happened with ffmpeg for the last stable release, even if it's a much
more important package).

I had the same situation for example with K-3D and OGRE embedding
GLEW, if I recall correctly, and was working with upstream to make
them work with the copies shipped by the system, not the embedded
copies -- otherwise I was quite sure that the packages would end up
being dropped out of the distro because of this.


> My customized SDL_mixer is based of SDL_mixer 2.0.  SDL_mixer 2.0 can
> actually be compiled against SDL 1.2 or 2.0 just fine, so I imagine the
> branch is just there for ABI reasons.
>
> [...]
> ECWolf compiles with SDL 2.0 starting with the recently released 1.3.2.  I
> hear it doesn't compile with stock SDL_mixer 2.0 due to the way I call a
> certain function, but I haven't bothered checking it yet.

That's good, thanks.

The majority of packages in Debian which depend on SDL still goes with
1.2, but v2 is growing and I hope to have time to push for more of
this to happen in this release cycle.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>