Bug#1028025: hippotat shouldn't be a native package
On Sat, Jan 07, 2023 at 01:11:59AM +, Ian Jackson wrote: >... > IMO It doesn't make sense to separately maintain upstream and debian > branches just to handle a usually-empty difference. I have often > integrated NMUs in packages maintained this way and it works well. >... I do not even care how you *maintain* it, I only care how you *export* it to Debian tarballs. >... > In such a situation (you're making an NMU with a package I maintain > this way), if you were to provide me with your git commits, that would > be welcome. >... There are no git commits. To avoid introducing regressions when the contents of the previously used sources in the Debian package and the contents of some git tree differs (this has happened), my only usage of git in NMUs is usually git-format-patch to export changes from upstream git to debian/patches/ nmudiff(1) sends the diff of my changes to the BTS, a maintainer can easily git-am this without me having to learn a gazillion different workflows. >... > > being able to split my own changes into separate patches makes it > > easier for other people to review my changes. > > That is true, if you need to make a substantial NMU. I'm sure most > maintainers will almost immediately import such a thing into git. >... The exact opposite is usually true: If there was a maintainer available who would do anything "almost immediately", there would not have been a need for an NMU. Usually the maintainer is either temporarily not available (happens to most of us) or MIA. > Ian. cu Adrian
Bug#1028025: hippotat shouldn't be a native package
Adrian Bunk writes ("Bug#1028025: hippotat shouldn't be a native package"):
> I don't know what your workflow is, e.g. git-archive(1) with
> export-ignore attribute for debian/ could be used to generate
> the orig.tar.xz.
My upstream release process does not involve tarballs.
I make and publish a git tag. Downstreams are expected to get the
source code from git. If they want to make tarballs they can do so.
Then with my Debian hat on, I make a tarball because Debian still
expects tarballs. dgit does the git to tarball conversion for me.
(I also do a "cargo publish", which does involve tarballs underneath.
That is quite regrettable, but out of my bailiwick.)
If someone does an NMU in Debian (they are very welcome to) I will
either use the git branch and commits they provided (if they did it
with dgit or otherwise gave me their git branch eg via salsa) or
import it into git ASAP (if they didn't).
IMO It doesn't make sense to separately maintain upstream and debian
branches just to handle a usually-empty difference. I have often
integrated NMUs in packages maintained this way and it works well.
One way to look at this is that (with my Debian hat on) I am using the
workflow described in dgit-maint-merge(7).
> being able to split my own changes into separate patches makes it
> easier for other people to review my changes.
That is true, if you need to make a substantial NMU. I'm sure most
maintainers will almost immediately import such a thing into git.
In such a situation (you're making an NMU with a package I maintain
this way), if you were to provide me with your git commits, that would
be welcome. The most obvious way would be for you to do your NMU with
`dgit push`, but of course you can use a branch or MR on salsa or
something.
If you prefer to stick to the lowest-common-denominator tarballs, as
represented in the Debian ftp archive, then of course that is up to
you.
I hope this clarifies things.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1028025: hippotat shouldn't be a native package
On Fri, Jan 06, 2023 at 11:01:19AM +, Ian Jackson wrote:
>...
> Adrian Bunk writes ("Bug#1028025: hippotat shouldn't be a native package"):
> > After reading the package description, nothing seems to make
> > this package native other than the main maintainer happening
> > to also be a DD.
> >
> > Please make the package non-native. There should be no downsides
> > in practice,
>
> I think the downsides is that I would end up splitting the release
> process in a confusing way, given that I intend to release upstream
> and to Debian simultaneously.
You build an orig.tar.xz without debian/ and then let dpkg generate
a source package with debian.tar.xz.
orig.tar.xz can be released as upstream sources.
I don't know what your workflow is, e.g. git-archive(1) with
export-ignore attribute for debian/ could be used to generate
the orig.tar.xz.
> > and it avoids weirdnesses like an NMU 1.1.3+nmu1 being
> > a new upstream version that other distributions like Yocto or Fedora
> > might integrate in their distribution as 1.1.3+nmu1-1.
>
> That would be fine ?
There are also other issues, like lack of patch management in the
package sources if someone else does a security or stable update
of your package. Which makes the changes harder to review for
other people.
All such issues are not fatal and also affect "real" native package
like dpkg or linitian, but this brings us back into the non-quilt
world of dpkg format 1.0 without the option of proper patch management.
Literally 99% of my uploads are NMU/stable/LTS uploads of packages other
people maintain, seeing changes from previous NMU/stable/LTS uploads
as series of patches helps me and being able to split my own changes
into separate patches makes it easier for other people to review my
changes.
> Ian.
cu
Adrian
Bug#1028025: hippotat shouldn't be a native package
Thanks for taking an interest in this package.
Adrian Bunk writes ("Bug#1028025: hippotat shouldn't be a native package"):
> After reading the package description, nothing seems to make
> this package native other than the main maintainer happening
> to also be a DD.
>
> Please make the package non-native. There should be no downsides
> in practice,
I think the downsides is that I would end up splitting the release
process in a confusing way, given that I intend to release upstream
and to Debian simultaneously.
> and it avoids weirdnesses like an NMU 1.1.3+nmu1 being
> a new upstream version that other distributions like Yocto or Fedora
> might integrate in their distribution as 1.1.3+nmu1-1.
That would be fine ?
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1028025: hippotat shouldn't be a native package
Source: hippotat Version: 1.1.3 Severity: important After reading the package description, nothing seems to make this package native other than the main maintainer happening to also be a DD. Please make the package non-native. There should be no downsides in practice, and it avoids weirdnesses like an NMU 1.1.3+nmu1 being a new upstream version that other distributions like Yocto or Fedora might integrate in their distribution as 1.1.3+nmu1-1.
