On 9/7/20 5:33 AM, Raphael Hertzog wrote: > On Sat, 05 Sep 2020, Richard Laager wrote: >> I do not see why we have to prohibit occasional uploads to experimental >> from debian/unstable. If this is permitted, then that also avoids the >> busywork of creating debian/experimental in that scenario. > > To me it feels awkward to allow this. You can't really get it both ways > IMO. If you decide to use codename-based branches, then you should use > debian/experimental for an experimental upload.
That view is: A > B. FWIW, my justification for B > CD is: Since the parallel branch scenario is already debian/unstable & debian/experimental, then I'll take a small inconsistency for the occasional upload to experimental to be able to use a strict subset of those choices (debian/unstable) as the normal scenario, rather than a whole new thing (debian/{master,latest}). > The "clarity" of debian/unstable is limited to Debian developers, upstream > developers might not know that unstable is the development branch. Random > outsiders neither. Whatever it is called, the main development branch will normally be the HEAD, so an unqualified `git clone` will give that branch. (Exceptions include when the repository is mixed upstream and packaging.) That probably covers the upstreams and random outsiders. > But what I meant is that "unstable" is only applicable to Debian and > that derivatives have different models and that we should not impose > too much to make sure we cater to the needs of derivatives too. I think you were following, but to be clear, the proposal isn't <vendor>/unstable, it's <vendor>/<suite or codename>. So debian/unstable, ubuntu/groovy (changes as time moves on), kali/kali-dev, etc. I do acknowledge that <vendor>/latest is undoubtedly easier for the tooling to implement, and that is a serious advantage of C. > Without having read your precise diff, I would believe my personal view > would be: C > D > B > A That is what I expected your view to be. You might be A > B rather than B > A, though, as discussed above. Anyway, I think I'm into dead horse territory here. Unless someone else speaks up, I assume the next step is for you to pick an option, which I assume will be C (in principle; not necessarily my wording). Thanks for taking the time to hear me out and thanks for DEP-14! -- Richard
signature.asc
Description: OpenPGP digital signature