Hi, Quoting Christian Kastner (2024-03-30 19:49:48) > On 2024-03-30 17:00, Marco d'Itri wrote: > > On Mar 30, Jonathan Carter <j...@debian.org> wrote: > > > >> Another big question for me is whether I should really still > >> package/upload/etc from an unstable machine. It seems that it may be > >> prudent > > If we do not use unstable for development then who is going to? > > Are you both talking about unstable hosts, or unstable chroots, or...? > > I do all my development on a stable host, within rootless podman > containers which are trivial to set up. I run final sbuilds and > autopkgtests in QEMU VMs, also trivial to set up. > > This is both out of convenience (I want my workstation to be based on stable) > and precisely because of the afforded isolation.
I find it *very* difficult to balance all the pros and cons of running stable versus unstable/testing on my own computer. On the one hand, yes, I was able to find and report bugs to packages in unstable before they migrated to testing just because I run sbuild and autopkgtest with unstable chroots and that is nice. Doing so also has become easier not the least thanks to Christian's work on sbuild-qemu, for example. On the other hand, I am still running bookworm because I only have only one computer and I really hate the times when I have to tell my family that sorry, I cannot spend the next few hours with you because some package on unstable broke some functionality of my system. So I should be happy with running stable on the host and unstable in my chroots, right? Well not so fast. The stuff I work on involves many things which are impractical or just not possible in a chroot, container or virtual machine. For example, recently there was a regression in mesa which introduced graphics glitches on my system (panfrost driver). Luckily, I'm backporting mesa from unstable, so I was able to notice this bug but I could not've noticed this if I had just used chroots, containers or virtual machines. This had to be installed on my system. Same with recent regressions in kernel 6.6 which locks up my system completely after around 10 minutes of uptime. This is specific to my platform and would not've been observable in qemu. Or take my work on mmdebstrap and system image building. I am not going to rung qemu inside qemu on my already comparatively slow system. Clearly, for many many things, running bookworm and using unstable chroots is sufficient to find bugs. There are just a number of situations where it isn't. So while I agree with your recommendation Christian in general, I do not think it is a silver bullet. Another example is when I wanted to run a GUI program inside an unshared chroot environment. Wayland does not seem to be happy about that and I didn't find a way to test my GUI application successfully. But maybe my container environment just fails to set up some things? Does there exist a way to test GUI applications inside a container without requiring superuser privileges to run the container? In summary: would running unstable instead of bookworm let me find more bugs than running bookworm with unstable chroots? For my specific work: yes, absolutely. Am I upgrading from bookworm to unstable or at least testing? Absolutely not. I just don't have the amount of free-time this would require of me. Just performing the 12-13 bisection steps to find the offending kernel commit which makes my system lock up would easily require a day of free time from me. I'm afraid I do not have this luxury. Not even remotely close! So I'll continue to not dogfood as hard as I could and run as much from bookworm as I can. Would it make me a better contributor if I ran unstable? Certainly! But this thing is just a hobby of mine and I can only allot that much time to do risky experiments with my only computer. I guess others are in the same boat? Thanks! cheers, josch
signature.asc
Description: signature
