Dear TC, I cannot speak for what Ian wants, but I would also like to formally ask the TC to rule on this issue. My hope is that what Ian and I are asking for is similar enough that the TC can consider the issues together.
Specifically, I'd like to ask the TC to come up with policy on native
packages and debian revisions using its power under 6.1.1.
In particular I ask the TC to consider the hypothesis that:
* Debian revisions are useful when there is a separate upstream flow
from the packaging flow. For example when Debian versions are
released at different times than upstream times, Debian versions have
different content (for example a debian directory), or Debian versions
are maintained by different people. IN these cases a debian revision
may be useful.
* Native source package formats (1.0 tar only and 3.0 (native)) are
useful when the work flow
is easier to maintain without separated Debian changes. There are
several cases involving git work flows where package maintenance is
improved by not requiring this separation.
* Git work flows are a best practice. There may be other best practices
too. We want to encourage git work flows to become more streamlined
and easier; when people have found git work flows that make their job
as maintainers easier, we want to encourage that.
I don't think the TC needs to do out-of-charter design work to come up
with policy in this regard.
I think there's been a lot of work within debian-policy, within
discussions of git packaging flows, and within the consensus-seeking
discussions run over the years.
I'll point outt that the behavior of non-experimental package
building tools explicitly falls under 6.1.1 and does not require the TC
to override a maintainer.
I believe it is also appropriate for the TC to rule under 6.1.2.
It's clear that policy, the packaging tools, archive build tools, and
tools to support git work flows need to be in harmony for things to work
well.
It's clear there is overlap, and it is clear to me we do not have
harmony today.
I'd also like to provide some initial briefing material to the TC to
help you all come up to speend on this issue.
* Ian's mail that you were forwarded
* #bug 737634
* My messages starting at
https://lists.debian.org/00000144017b42b6-b65ba883-c94b-472c-89b7-7341c14ce8ab-000...@email.amazonses.com
and following the thread. I explain one case where you want to use
a debian revision with native packages. I think Ian has described
cases that are more clearly directly related to the Debian archive,
but I clearly outline in that bug report problems I was having and
why proposed alternatives did not work.
* Around that time a claim was made that debian-policy did not permit
debian revisions with native packages. I challenged that claim and in
https://lists.debian.org/[email protected] Russ
acknowledges that the section of policy he was pointing at did not
actually forbid debian revisions with native packages. So at the time
dpkg made the change it was breaking things and there was no policy
requirement for the change.
* Ubuntu had to make a change to dpkg-source at least as used by
launchpad for recipe builds to continue to work. I don't know if they
still maintain that patch, but it seems like a bad sign when a major
downstream needs to revert a change we've done to get work done. It
would perhaps be valuable to look into whether they still have that
delta and if not how they work around things.
* https://lists.debian.org/[email protected] the most
interesting bit there is a consensus of the project that if your
upstream uses git, best practice is for your packaging to use git.
* https://lists.debian.org/[email protected] Consensus:
native packages are sometimes an appropriate tool to use in contrast
to earlier consensus that we wanted to move away from them.
* Plus the recent thread on debian-devel.
* The git packaging BOF at DebConf19.
Thanks for your consideration,
--Sam
signature.asc
Description: PGP signature
