Manuel A. Fernandez Montecelo
manuel.montezelo at gmail.com
Sat Dec 28 12:49:09 UTC 2013
2013/12/22 Gianfranco Costamagna <costamagnagianfranco at yahoo.it>:
>> Il Domenica 22 Dicembre 2013 0:19, Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com> ha scritto:
>> > 2013/12/21 Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>:
>>>> I can help of course, I'm trying to get more and more involved in
>> debian (I'm a DM since some months now, but I started contributing more than
>> one year ago in the debian alioth gits)
>>>> I'll be glad to help, altough sometimes I still make mistakes (the
>> .24 wasn't uploaded because the ABI/API changed and nobody bumped the
>>>> I pushed everything on alioth!
>>> OK, thanks, I will review it.
>> So I reviewed it and pushed the changes, which is mostly to squash the
>> changelog of .24 and .25 together and minor packaging changes which
>> probably are not important (didn't remember to commit separately,
> Wonderful! That was in my plans, but I was too lazy to to it :)
So is it OK to go for you, other than waiting for the transition?
>> I think that the bump in SONAME will bring the following complications:
>> - the binary .deb has a new name, thus has to go through the FTP
>> master's NEW queue (and can take weeks/months)
>> - all reverse-depends will have to be recompiled against the new
>> version (probably binNMU is enough, but since there are ~30 or so I
>> guess that some of them will fail to compile and complicate the
>> - I think that a transition should be opened with Release Managers,
>> the number of packages is high enough
>> I wonder if we can do something like the following to avoid at least
>> the 1st step:
> For this part I don't know the best solution honestly...
> I tried the possible to avoid the new queue stall, but maybe since this is an API/ABI change is good to change everything and to have a package name coherent with the new sdl API/ABI.
> for the transition yes, I think we should open a transition and ask for binNMU, I hope everything will go smoothless, since the changes weren't so deep, at least in the API (some internal function were removed, and some bug fixed, nothing more if I remember correctly)
OK, so please speak with Release Managers and keep this list in copy
so we can chime in if necessary, and do the actual uploads.
> (I'll look for sdl2 soon I hope)
OK, let me know when it's ready to review. This is less problematic
and we can upload once it's ready, since we don't have to care about
Just try to keep things as close as possible to the other libsdl2*
packages so everybody can treat all the modules as having the same
structure and config, and we can apply changes to packaging widely,
it's easier to understand and less error-prone. If there are things
that you don't like and can be improved in other modules they should
be fixed in them as well, and not only improve the gfx module.
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
More information about the Pkg-sdl-maintainers