Re: RFC: Final update of DEP-14 on naming of git packaging branches
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.
Thus I stand on the opinion that we need to have a generic name for the
default development branch. We can accept use of alternate default
branches, for those who have strong opinions in that direction, but the
default recommendation should be some generic name.
> (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.)
That would not work. git is not allowing you to have those two branches at
the same time. A given path can't be a branch and a directory at the same
time.
> > 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?
> 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.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: