Hi Sylvestre,
Quoting Sylvestre Ledru (2024-02-16 19:24:00)
I am really sorry but it seems that I made a mistake with rust
palette:
https://tracker.debian.org/pkg/rust-palette
I didn't realize that it was already uploaded (probably because I
uploaded https://tracker.debian.org/pkg/rust-palette-derive )
Please let me know how to fix this issue :(
I needed it for the new version of eza!
Ok, I will try fix that. I recognize how that confusion could arise (as
in: I could've easily made the same mistake - and possible did).
Please take a look at related bug#1063779.
And when you do hijack packages²³, then please be respectful and give credit, by preserving/reviving past contributions in the changelog file.
I'll second what James wrote, this was done by mistake by me as our
tooling didn't discover your package and I'm sorry for the extra work
it caused.
Den mån 8 apr. 2024 kl 12:41 skrev James McCoy <jamessan@debian.org>:
On Sun, Apr 07, 2024 at 09:58:10PM +0200, Jonas Smedegaard wrote:
And when you do hijack packages²³, then please be respectful and
give credit, by preserving/reviving past contributions in the
changelog file.
As the person who uploaded rust-lazy-regex-proc-macros, I wasn't
aware the crate already existed in Debian and wasn't intending to
upload a hijack of your package. The Rust team _does_ have a lot of automated tooling and when I prepared the upload to NEW, it agreed
the package was new.
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.
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.
...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?
Den mån 8 apr. 2024 kl 12:41 skrev James McCoy <jamessan@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.
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).
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.
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.
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@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.
On Mon Apr 8, 2024 at 9:21 PM BST, Jonas Smedegaard wrote:
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
I've never interacted with any Rust packaging.
For Haskell, I believe there are sound technical reasons for the
monorepo. I have found that trying to contribute fixes to Haskell
packages is difficult because it is so different from Debian convention.
I think that's important, so a decision to use a monorepo should not
be taken lightly.
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
(or did I misunderstand your point?)
Interesting: Can you elaborate on those examplary contributions of yours which highlighted a need for maintaining all Haskell packages in same
git repo?
Quoting Jonathan Dowland (2024-04-17 17:29:11)
On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote:
Interesting: Can you elaborate on those examplary contributions of
yours which highlighted a need for maintaining all Haskell packages in
same git repo?
My Haskell contributions (which I did not enumerate) are tangential to
the use of a monorepo. But it strikes me as an odd choice for you to
describe them as examplary. Paired with you seeming to file me on "the
opposing side", your mail reads to me as unnecessarily snarky. Please
do not CC me for listmail.
I can see why it might come across as snarky. It was not intended that
way.
I just meant to write describe your contributions as examples, but I
realize now that with your emphasizing it that I wrongly described them
as extraordinary examples.
On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote:
(or did I misunderstand your point?)
You misunderstood my point: I was actually supporting your position.
You've read it entirely backwards.
Interesting: Can you elaborate on those examplary contributions of yours which highlighted a need for maintaining all Haskell packages in same
git repo?
My Haskell contributions (which I did not enumerate) are tangential to
the use of a monorepo. But it strikes me as an odd choice for you to
describe them as examplary. Paired with you seeming to file me on "the opposing side", your mail reads to me as unnecessarily snarky.
Please do not CC me for listmail.
Jonas Smedegaard <dr@jones.dk> writes:
Quoting Jonathan Dowland (2024-04-17 17:29:11)
On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote:
Interesting: Can you elaborate on those examplary contributions of
yours which highlighted a need for maintaining all Haskell packages in >>> same git repo?
My Haskell contributions (which I did not enumerate) are tangential to
the use of a monorepo. But it strikes me as an odd choice for you to
describe them as examplary. Paired with you seeming to file me on "the
opposing side", your mail reads to me as unnecessarily snarky. Please
do not CC me for listmail.
I can see why it might come across as snarky. It was not intended that way.
I just meant to write describe your contributions as examples, but I realize now that with your emphasizing it that I wrongly described them
as extraordinary examples.
I suspect (based on Jonas's domain) this is one of those subtle problems
when English isn't your first language. The English language is full of weird connotation traps.
For anyone else who may not be aware of this subtle shade of meaning, an English dictionary will partly lie to you about the common meaning of "exemplary" (which I assume is what Jonas meant by "examplary"). Yes, it means "serving as an example," but it specifically means serving as an *ideal* example: something that should be held up as being particularly excellent or worthy of imitation.
If you ask someone "could you elaborate on your exemplary contributions,"
a native English speaker is going to assume you're being sarcastic about
90% of the time. In common usage, that phrase usually carries a tone
closer to "please do enlighten us about your amazing contributions" than
what Jonas actually intended.
I keep having to remind myself of this in Debian since many Debian contributors have *excellent* written English skills (certainly massively bettern than my language skills in any language other than English), so
it's easy to fall into the trap of assuming that they're completely
fluent, but English is full of problems like this that will trip up even highly advanced non-native speakers.
To be fair, I _was_ upset (not with Jonathan, but) earlier in this
thread, which makes it harder to err on the side of a mistake when I
write something that can be read as being sarcastic.
Sorry, Jonathan, for being difficult to read here.
Sorry, Jonathan, for being difficult to read here.No problem: Sorry for lapsing in assuming good faith on my part.
On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote:
To be fair, I _was_ upset (not with Jonathan, but) earlier in this
thread, which makes it harder to err on the side of a mistake when I
write something that can be read as being sarcastic.
I would be upset too if my packages were repeatedly hijacked.
Sorry, Jonathan, for being difficult to read here.
No problem: Sorry for lapsing in assuming good faith on my part.
WRT Haskell and the monorepo, I've just done a bit of digging to try and remind myself why it was necessary, and I've not found a satisfactory
answer. Perhaps there isn't one! [1] says it's "easier to update them
in bulk" which, in isolation, I personally don't think is sufficient for
the trade-off.
I've just noticed that you upload Pandoc, and it (thankfully) is in an individual repo. You don't build a library package, perhaps that's
relevant. I haven't traced the history that results in there being a
separate haskell-pandoc source package yet.
[1] https://lists.debian.org/debian-haskell/2024/02/msg00001.html
[2] https://tracker.debian.org/pkg/haskell-hakyll
I am unaware if I am alone in maintaining Haskell packages outside of
the team giant-git-repo thingy.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 339 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:04:40 |
| Calls: | 7,466 |
| Calls today: | 2 |
| Files: | 12,691 |
| Messages: | 5,627,862 |