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
Attachment:
signature.asc
Description: OpenPGP digital signature