On 29/05/2025 12:51 pm, Jonas Smedegaard wrote:
Quoting Xiyue Deng (2025-05-29 06:15:30)Hi Holger,Holger Levsen <hol...@layer-acht.org> writes:On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:If you suggest that using "debian/latest" should *not* be done by default, then it seems that requires reverting changes to DEP-14.yes. dep14 currently says "that uploads to unstable and experimental should be prepared either in the debian/latest branch or respectively in the debian/unstable and debian/experimental branches." I think it should (instead) recommend debian/unstable (for uploads to unstable) (and in very brief) allow any debian/* branch layout & probably specifically name certain common ones.Personally, I don't see a problem in finalizing DEP-14 with its current wording, but I might miss something (more generally relevant than "let's just all use git-buildpackage" which I don't think is what you are saying here).my biggest problem with dep14 is that it doesnt recommend *one* layout. my biggest problem with how I see that interpreted is that I think debian/unstable is much better than debian/latest *as a default recommendation*. because IMO debian/latest is rather *not* helpful when uploads to experimental are involved. and because debian/unstable is rather very clear what this branch is about.I am not yet a DD, but I maintain packages as a DM. Just want to provide a perspective from a "debian/latest" user, as I found using "debian/latest" easier personally. When I need to experiment something on experimental and intend to upload to unstable as soon as the experiment succeeded, using "debian/latest" provides a simple linear git timeline. If I were to use "debian/unstable", I would need to sync "debian/experimental" with "debian/unstable", do experiment there, upload; and once done, I would need merge "debian/unstable" with "debian/experimental"; and after future upload to unstable, "debian/experimental" becomes stale again and requires another merge in the future. As I don't intend to let the experimental version stay long, I think using two different branches for unstable and experimental unnecessarily complicates the process. Just my two cents.Thanks for describing that usage pattern well, Xiyue Deng. I find it sensible begin packaging targeted experimental, and move the package to unstable only when stable (yes, that is one common confusion: the notion of "stable" versus "unstable" is descriptive not for the package itself but for the *integration* of packages, which also emphasizes targeting experimental initially: At first, there is zero integration which commonly equates to zero integration stability). ...but yes, then later on I use experimental branch for either of two patterns: Either an experiment not expected to lead anywhere in itself (but possibly reused e.g. through cherry-picking into another branch), or an experiment expected to stabilize and get merged in another branch. If we really want to etch a default branch into the DEP-14 spec, and it should be mainly targeted newcomers to Debian, then I think the default should be "debian/experimental" to limit the amount of information needed to declare for creating a package from scratch. Perhaps, to ease the burden of those of us maintaining many packages, we could instead have this more complex rule:The default debian branch is the first available of these, in order: 1. debian/latest 2. debian/unstable 3. debian/experimental
This sounds like a good solution that covers both cases.
That would cover both those who prefer to explicitly name if their latest mainline work is currently targeted the Debian unstable suite or not, and those who want explicit branches only when need for distinction arise. Please also note, that "need for distinction" may not involve unstable/experimental suites: I maintain packages with zero distinction between unstable and experimental but a need to distinguish stable or oldstable updates. - Jonas P.S. Tools taking legacy git branch naming into account could append this:4. debian
OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
