[Pkg-rust-maintainers] Silent hijacking and stripping records from changelog

[James McCoy]

On Mon, Apr 08, 2024 at 10:21:49PM +0200, Jonas Smedegaard wrote:
> ...and about moving on: Can you please also clarify if you understand
> "moving on" as reverting to me maintaining the package that you
> accidentally hijacked, or if you instead understand it as you (on bhalf
> of the Rust team) now having taken over maintainership of that package?

I've already filed an RM request for src:rust-lazy-regex-proc-macros, so
your package will prevail.

> > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy <jamessan at debian.org>:
> > > Now, that happens because our tooling is based around a 1:1
> > > relationship of crate to source package where as you've been
> > > packaging an entire workspace as a source package. We need to adapt
> > > our tooling to better detect this so we get accurate information
> > > presented to us and avoid stepping on your work.
> 
> Yes, please improve your tooling to better align with Debian packaging
> rules, not assume your team rules apply also outside of your team.

Having policy for a language ecosystem is pretty common, since that
makes it easier to interoperate.

> > > I'd still prefer if we could consolidate our efforts into the rust
> > > team (and re-integrate your forks of our package helpers), rather
> > > than have two divergent sources of rust packaging.
> 
> I would also prefer if we could consolidate our efforts, and am open to
> joining the Rust team and collaborate there, as also stated previously.
> 
> What I am not open to is abandon the one-git-repo-per-source-package
> packaging style that is commonly practiced in Debian. As I understand
> it, only Haskell and Rust teams use giant-git-for-all-team-packages
> style, and only the Rust team strictly enforce that style (Perl team
> uses myrepos to work across many packages which I recommend you to
> consider).

When I first started looking into Rust packaging it was initially going
to be for a workspace of crates. I didn't receive any pushback when I
asked about taking over the one crate that had already been packaged and
handling it from a single source package for that workspace. In the end
I changed my mind and continued using the monorepo for the rest of the
crates.

It makes certain things easier, while using a repo based on upstream git
makes other things easier. Which method is used is up to the maintainer.
Not using the monorepo just requires better coordination.

> More important, however, and despite what I can or cannot agree with:
> For as long as the Rust team chooses to deviate from general Debian
> practices, it *must* constrain those deviated rules to team work, and
> *not* make the flawed assumption that all Rust crates in Debian are
> aligned with Rust team packaging rules. At any time any Debian developer
> may upload a rust-* package - that namespace does not belong to the Rust
> team, regardless if/when I join the team.

As far as I know, no one has claimed that we have sole ownership of the
rust-* namespace.  However, we do expect anything using that namespace
is uploading a package which agrees with upstream's use of that
namespace.  If src:rust-foo or bin:lib-foo-dev is not the same project
as foo on crates.io, then *that* is a problem.

The only confusing example I'm aware of is the opposite issue -- no use
of the rust-* namespace when I was expecting it to be (src:btm rather
than src:rust-bottom).

> I am happy that you bring up my forks of cargo-related package helpers.
> I'd be delighted if they were to be adopted in dh-cargo, as that would
> simplify my packaging. Only reason I haven't filed bugreports was that
> my past interaction with Wimin and Josh regarding the core packaging
> choices of those helper script of yours left me with a very clear
> understanding that the Rust team had made those choices deliberately and
> was not about to negotiate changes to them.

I'm not sure how broad the sentiment is, but I would certainly like to
see the workspace handling reintegrated. I've considered that for some
packages I work on, and I believe others have been interested in it as
well.  I'm not familiar with what other changes have been made, so thank
you for the pointer to the fork repo.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB