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

Tue Apr 9 08:26:49 BST 2024

Quoting James McCoy (2024-04-09 03:25:16)
> 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.

Ah, good to know. Thanks!

> > > 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.

Yes, team-specific policies exist, to ease work within those teams.

Team-defined policies do not, however, hold any special powers outside
of said team, so it is sensible for them to not conflict with general
Debian packaging policies or assume that all packages *outside* of the
team are aligned by those team-specific policies - e.g. that a binary
package containing cargo crate source files must¹ be built from a source
package with same name as that cargo crate.

¹ "Package naming" in https://wiki.debian.org/Teams/RustPackaging/Policy

> > > > 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.

Well, I received strong pushback by Ximin (on irc - I can share chat log
discretely if interested) when I joined the team and published a
single-package-repo rust library (possibly the first librust-* in
Debian), and the pushback and insisting on strong rules imposed for team
members lead me to drop that package and leave the team.

I have since, every time I have been approached by Rust team members and
suggested to join the team, shared my concern about the Rust team
policy, and asked if those policies might have changed, or if those
approaching me might see a benefit of working towards changing team
policy.

I am not quite sure what you are really saying above. Squinting my eyes
it kinda sounds like you might be open to relaxing team policy.  If
that's the case then that's great news.  I look forward to that.

If you are interested in better understanding my notivation for the
crisicism I raise towards the Rust team policy, then feel free to reach
out - I am happy to elaborate.

> > 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.

Sorry if my phrasing came across as such strong allegation.

What I meant to imply was not explicit *claim* of ownership but merely
*assumptions* about team-specific policies applying Debian-wide.

> 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.

How is that a problem for Debian (not for Rust team tooling)?

Can introducing some asset to crates.io affect stability of Debian?

> 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).

Sounds like you are talking about Rust team tooling assumptions here,
not Debian-wide consistency.

> > 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.

Happy that you see some use for my work.  Again, please tell if you are
in need of some clarification about it.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20240409/39f0d988/attachment.sig>