(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 <ad...@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.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
