Re: RFC: Final update of DEP-14 on naming of git packaging branches
Raphael Hertzog wrote on 31/08/2020:
> On Mon, 31 Aug 2020, Paride Legovini wrote:
>> What I propose is to require for dep14 compliance that uploads to
>> <codename> are to be cut from debian/<codename> branches, unless
>> <codename> is experimental. This allows to checkout the "maintainer
>> view" of a given (nonexperimental) version of a package by knowing only:
>>
>> - the repository location
>> - the relevant d/changelog entry.
>
> You are asking for more than what DEP-14 is trying to achieve.
>
> DEP-14 does not mandate any specific workflow, it mainly tries to
> stantardize the branch names for the various cases that we have.
>
> We're not trying to impose one workflow or the other.
I agree, what I propose trespasses on the "workflows" territory. However
DEP-14 already does it a bit I think, and I don't think that what I
propose is too far away from it. Current DEP14 says:
---
In general, packaging branches should be named according to the codename
of the target distribution. We differentiate however the case of
development releases from other releases.
---
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.
(Could be made more generic by recommending optional branches named:
- <vendor>/<release>/devel
for development, to be merged to
- <vendor>/<release>
before uploading. But this is probably overkill.)
> 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?
>> This automatically allows:
>
> I don't think that anything in the current wording is forbidding
> anything that you list.
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.
Cheers!
Paride
Reply to: