I think I now have a better handle on how/why I disagree with the DEP-14 recommendation language.
On 8/30/20 8:36 AM, Raphael Hertzog wrote: > 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 So you are regularly using multiple releases (unstable and experimental) where the DEP-14 language allows you to use either debian/latest or debian/{unstable,experimental}, but you feel debian/latest makes the most sense most of the time in that scenario. I think I see your point. You don't always know a priori when you are going to want to upload to experimental. (Where you do know that, it's because you expect the experimental piece to live in parallel for a while and you'll use a temporary debian/experimental branch.) So you have one debian/latest branch that can upload to unstable or experimental as needed. You could use debian/experimental all the time and then merge down to debian/unstable only when you're ready to upload and have chosen unstable. But I suspect your objection would be: that's unnecessary busywork. And I see that point. I would probably make the same objection, which means I think I agree with the debian/latest concept in your situation. I'm not sure if most package maintainers are doing this or not. I've always assumed that most people are targetting only unstable most of the time and that use of experimental is relatively rare. I could easily be wrong on that. But that is definitely _my_ practice: My package branch typically moves between: - ready for unstable/upload to unstable - work in progress on a new upstream release - back to ready for upload to unstable That is, I'm generally always targetting unstable and _not_ regularly using multiple releases, so the DEP-14 language "prohibits" me from using debian/unstable. This is what feels backwards to me. If I'm always targetting unstable, debian/latest (and previously debian/master) is less clear than debian/unstable. At a minimum, can we rework this in some way so the language does not require me to be regularly using multiple releases to use debian/unstable as a branch name? Preferably, can we change this to convey the following (probably using better language): 1. If you (have one line of package development and) regularly alternate between uploading to unstable and experimental, use debian/latest. 2. If you normally only upload to unstable, use debian/unstable. 3. If you will have a separate line of package development for upload to experimental, name that debian/experimental. If that is long-lived, the other branch should be debian/unstable. #1 covers your use case. #1 is listed first per your view that this is the common case. #2 covers my use case. #3 allows either a #1 or #2 style to add debian/experimental temporarily, while recommending the debian/{unstable,experimental} pair if the experimental branch is long-lived (because it's confusing for debian/latest to not be the latest version). -- Richard
signature.asc
Description: OpenPGP digital signature