Retirement from Debian/Wine
Hi all,
I'm sorry to say: I retire from being active for Wine and Debian.
It's mainly because the focus of my life shifted to other things. Maybe
that'll change again some time and I'll come back, but please don't plan
with that in mind. I'll be available for any questions and will try to
help anyone with taking over.
In recent years I mostly took care of src:wine, src:winetricks and for
some time Wine backports, while Mike mostly took care of
src:wine-development (where the main packaging happens) and several
specific build-dependencies. I don't know Mike's current plans and
capacities, but looking at the current packaged upstream versions, and
removals from testing, I get a feeling that we *seriously need more
people* being active in wine-team.
The next days I'll remove myself from uploaders and maybe file bugs for
some specific open things.
Also I have some thoughts about the way we handle packaging Wine.
My intention is to at least leave some knowledge and experience
available for whomever is interested in working on Wine. These thoughts
are in no way related to my retirement. If it's not helpful input,
please just ignore it. And yes, personally I'm really not up-to-date
with what is going on anymore.
Short version: Don't let the Perfect be the enemy of the Good.
* Packaging every version
Historically we packaged each and every version of Wine (each release
every 14 days and more). AFAIK the main reason for that was some
software only working with specific, older, Wine versions - I don't see
this as so important nowadays. Also, due to changes in (versions of)
dependencies, most source packages don't even compile without some
changes. I don't think there are many, if even any, people using Wine
versions from debsnap.
It's still useful for a quick regression testing, and having every
version packaged in time is brilliant - but in the case of a backlog of
unpackaged upstream version I think we should just go on with the
current version.
* Patching compiler warnings
We build wine in maintainer mode since I enabled re-building the Wine
fonts on compilation. This also lead to compiler warnings being handled
as errors. Nowadays we ship plenty of patches (some qualify for being
applied upstream, some are more workarounds which just work for Debian).
I think we should only patch these warnings if we also get the changes
applied upstream. Otherwise we should just make the warnings
non-critical. I admit I can't judge about the specific drawbacks or
risks of not patching these issues.
* Build dependencies
A few years ago we only had to make sure that unicode-data and
khronos-api were packaged in the correct version. Nowadays there is an
increasing number of wine-specific build-dependencies like faudio, vkd3d
and more. Also upstream changed how it builds DLLs towards PE. I never
had a look on what that specifically means. Probably this helps with
distros retiring their 32-bit archs, and may change how we build Wine:
also build 32-bit Wine on 64-bit (?). I suggest to emphasize on building
current Wine versions, even if this means that not every new feature of
Wine is supported from the beinning
So yes, that's it - it's been an awesome time here! Thanks everyone who
has been here the last years, and thanks to everyone who will be here
the coming time. Good luck everyone, I wish you all the best!
Greets
jre
Reply to: