On Sat, 29 Aug 2020, Richard Laager wrote: > That said, I do understand we give a lot of deference to developers' > workflows. So I have no objection to DEP-14 supporting this workflow > with debian/latest. But I would like to see it (debian/latest) > recharacterized as the alternate approach rather than the recommended > method. Your approach is perfectly valid but I don't really believe that it should be the recommended approach. It doesn't seem to match the most common workflow. Most package maintainers are not actively working on two different development branches, instead the single development branch keeps moving between: - ready for unstable/upload to unstable - work in progress on a new upstream release - possible upload to experimental to gather feedback (buildd, users) - back to ready for upload to unstable In some rare cases, we will have to do some intermediary upload to unstable because some RC bug popped up and we don't want to wait until we're ready with the next upload. In that case, we will create a debian/unstable branch starting from the last tag in debian/unstable. IOW, while branches are cheap, I create them on request only when I need them, I'm not using multiple branches until I have a real need for it. But I might also do the opposite. If I know that the next upstream release breaks backwards compatitibly and that it will have to mature a long time in experimental until all other packages are ready, I might start to package it rigth now in debian/experimental and continue to use debian/latest for my unstable uploads. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Attachment:
signature.asc
Description: PGP signature