Re: RFC: Final update of DEP-14 on naming of git packaging branches
Raphael Hertzog wrote on 31/08/2020:
> Hi,
>
> On Mon, 31 Aug 2020, Paride Legovini wrote:
>> A tl;dr version of my idea is: let's remove the special treatment for
>> development releases, treating e.g. debian/unstable like a stable
>> release. Optionally use a 'debian/devel' branch for development work.
>> The only "workflow" bit is: if you work on debian/devel, merge your
>> changes to debian/unstable before uploading.
>
> I understand this but you are imposing usage of multiple branches to some
> persons who are happy to have a single branch alternating between unstable
> and experimental. I don't want to go that extra mile. In particular
> because this requirement has other drawbacks that you didn't list:
>
> You hardcode the name of the Debian development release while I would
> like DEP-14 to result in changes to packaging tools that can be useful
> across multiple distribution vendors. And while tools can easily query
> `dpkg-vendor --query vendor` there's currently no simple way
> for a tool to learn the codename of the development release.
I do not fully agree:
- if you go back to my proposal I exclude experimental from the "branch
name should match upload codename" requirement
- the devel branch name is not hardcoded: vendor foo with devel release
bar would have development for it done in the foo/bar branch
*however* after some more thinking I came to the conclusion that a
long-lived development branch with a cross-vendor predictable name makes
sense.
I second your proposal, with preference for <vendor>/devel over
<vendor>/latest.
>>> We want to document what we can expect when you have debian/latest
>>> and what you can expect when you have debian/unstable.
>>
>> On this point: should there be a way for a package to declare its
>> packaging repository follows dep14?
>
> What would we gain from this?
Predictability: if a package is declared dep14 compliant then I'll know
immediately what to expect in its packaging repo and how its branches
are used. The repository can be "linted" for actual dep14 compliance.
But the branch structure itself and the name of the default branch are
probably enough to infer that dep14 is being followed.
>> And you are right, however I think the current wording may be partially
>> missing the opportunity to set stronger expectation of what is to be
>> found in a Debian packaging repository in terms of branches, which is
>> what my comment is about.
>
> I'm trying to bring this DEP to some conclusion and I'm not going to
> extend its scope.
Thanks for this.
Paride
Reply to: