[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Figuring how to work with team-maintained packages on salsa



Hi Sean,

On Sun, Jun 06, 2021 at 11:40:47AM -0700, Sean Whitton wrote:
> If you want to produce patches/commits to share with the maintainer,
> then `dgit clone` enables you to work with arbitrary packages in a
> homogeneous way, regardless of adoption of `dgit push`.  It can also
> help you NMU; see dgit-nmu-simple(7).  I am not sure what Helmut has in
> mind with the mention of .debdiffs -- could you perhaps explain why you
> feel you have to fall back to these, even with dgit?

For one thing, you answer your question below and I think this also is
what Florian was looking for.

There is another issue affecting me, that may derail from the original
topic. When I work with packages I tend to fix bugs that are reported by
some CI system on unstable. When I dgit clone, I may get the unstable
version or I may get unreleased changes that may work or may be broken.
That's not what I want. Instead, I strongly prefer working with exactly
that version that produced the failure in CI. Even accidentally using
experimental often produces wildly differing results. Beyond that, I
don't want my trust root for software to reside in SSL certificates. I
haven't found a way to ask dgit to produce a git tree that exactly
produces the source package signed by unstable reliably.

Admittedly, not working with unreleased changes makes integrating them
harder for the maintainer. That's certainly a trade-off between my time
and their time. I've chosen that I'm unwilling to work with unreleased
changes of arbitrary packages. Their quality is too unpredictable to me.

> What dgit doesn't really help you with is integrating those patches
> directly into the maintainer's repo, if the maintainer invites you to
> push your changes directly, which is perhaps what Florian was looking
> for.

Yes, that. debdiff kinda is the universal format here as it is
recommended in the developers reference and can be produced for
arbitrary packages. bugs.debian.org is a universal communication method
to package maintainers. It's a bit annoying, but universal (inside
Debian).

Thinking more about this, there is one project of Jelmer that is getting
closer to reintegrating changes. It is silver-platter, which really
attempts to grok maintainers' idiosyncrasies and produce patches in the
way they desire. As far as I know, it actually works with a significant
portion of the archive already as it backs janitor.d.n.

If everyone was using dgit, then yes it would be providing that
homogeneity much like dh does provide homogeneity on the packaging
helper level now. The way it currently is, dgit unfortunately is
https://xkcd.com/927/ (standards). We really cannot have both workflow
diversity and homogeneity. Either of them must be unhappy and dgit
chooses not to make the workflow diversity people unhappy. The price for
homogeneity is telling a significant number of people that they cannot
continue using their workflow and making them very unhappy that way.

Helmut


Reply to: