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
