Bug#900928: deps
Hi Matthias,
[quoting previous private post to help establish context]
Quoting matthias.geiger1024@tutanota.de (2023-03-14 11:39:30)
> I wanted to discuss fractal. I also have a somewhat related interest to it. I have been constantly working on it. My wip-gtk branch covers most of its missing dependencies, so the big chunks missing are the matrix sdk and comrak. I have been constantly working on those, too. I'd like fractal to be maintained within the GNOME team since 1) it uses the GTK stack and 2) is also a circle app. Since I also put in some effort I also would like to be included as uploader. I think this is fair since now 80% of the dependencies are covered.
Quoting matthias.geiger1024@tutanota.de (2023-04-13 14:57:41)
> > Is your work available publicly somewhere?
> >
> Yes. The matrix-sdk depends mainly on ruma which is 80% packaged in the debcargo-conf repo.
> The GTK-rs update is visible here: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/463 and most of the *debs are here: https://salsa.debian.org/werdahias/obfuscate-wip/-/tree/debs?ref_type=heads ;
>
> Stuff still missing: ashpd, oo7 and matrix-sdk. The former two are GTK related and I will package them as soon as the GTK update gets uploaded because I need them anyway. the latter needs ruma which I have constantly been working on.
> comrak isn't needed anymore apparently.
Ah, makes sense now. I thought you meant that you mean a wip-gtk branch
of the fractal packaging - i.e. this git repo:
https://salsa.debian.org/matrix-team/fractal
I appreciate your work on getting dependent Rust crates packaged for
Debian.
Personally I dislike the all-crates-in-one-git approach practiced in the
Rust team, and since the team has made it a "must" to do so within the
team I am not in that team at all.
Please consider using the Debian bugtracker to communicate "intents to
package" by filing an ITP bugreport for each single upstream project
that you work on packaging for Debian. That enables us to keep track of
efforts targeted but not yet included formally into Debian - i.e. the
very purpose of that class of bugreports in the Debian bugtracker.
> wrt maintaining: I thought all GNOME circle apps should be also maintained within the GNOME team, maybe even in a separate workspace, but that is just my opinion (especially since I maintain three of those programs that way). You're free to maintain it however you see fit, I didn't want to impose.
There are benefits of streamlining packaging within a team, but there
are also drawbacks of "optimizations" done within single teams. There
is a real risk that packages may bitrot when maintained by a team with a
too large focus, as single packages at the edge of their focus may not
get adequate attention.
Obviously a package may lack attention *anywhere - we do not magically
get more hands by splitting the task into more smaller buckets. But in
a smaller team mistreated packages has arguably a higher chance of
getting noticed - either by the team itself or by fellow Debian devopers
outside of the team or by users.
I mean, the task list for the security team is several pages long:
https://udd.debian.org/dmd/?team%2Bpkg-security%40tracker.debian.org#todo
...but that pales in comparison with the task list for the python team:
https://udd.debian.org/dmd.cgi?email1=team%2Bpython%40tracker.debian.org
There is no single obvious way to group packaging efforts.
Some teams streamline for one build systems (e.g. Rust team). Some
teams streamline for one programming language, across build systems
(e.g. Perl, Java, and Python teams). Some teams streamline for one
widget toolkit use, across languages (e.g. the GNOME team). Some teams
streamline for one desktop environment, across widget toolkits (e.g.
LXQT team)
Most packaging teams at https://wiki.debian.org/Teams, however, have a
scope of concrete tools or a smaller collection of interrelated tools.
The GNOME team likely has a team policy that optimized towards projects
closely related to the GNOME core infrastructure, at the expense of
packages more loosely related to that. That does not mean that all
projects close to GNOME is better off maintained by that team, only that
maintenance of the projects there benefits from that optimization - but
the backside is that maintainers are then expected to align with the
policy.
I don't use the GNOME desktop myself, and do not maintain a range of
packages tightly related to GNOME, so for me it would be more a burden
to engage in yet another team with maybe-peculiar-to-me policies.
> Regarding the "credit": also maybe came off wrong. My POV: I made a list of all the fractal deps and slowly started working those off. I put in a lot of effort to get the GTK-rs update underway and the rest of the fractal stuff like ruma. I guess that resulted in me thinking "Well, I do want some of the credit for working on fractal!" And I think while that may seem selfish I still deserve that as I put in constant work towaord the goal of packaging fractal. It's not my intention to come off that way but I think you get my point.
I totally get that.
It pains me that when I ask about your work, you point me to what I
perceive as a teamwork with little visibility of your efforts in it.
In a parallel universe, you would have posted to this ITP each and every
time you initiated the packaging of a dependency, exactly because you
initiated it with Fractal in mind. Then your work would have gained
visibility for anyone looking for progress on the Fractal packaging,
including me who have been attacking the challenge from the other end.
Personally I suspect that some of the pain you have gone through in
getting those packages in shape is due to the Rust team "streamlining",
and I fear that the current blocker of bug#1017905 is a sign of that.
> Honestly: Feel free to do whatever you think best for debian. The GTK stack will land in trixie and then it's straightforward to finish packaging. Please don't interfere with a) the gtk stack and b) the rest of the ruma stack,
> I kinda don't care about the rest. (not trying to start a side discussion which rust packaging is better; if I have an overview for both stacks that makes things easier)
What I think is best for Debian is that we collaborate more in Debian.
In Debian as a whole, not (only) within teams.
I dislike several things in the Rust team, and I suspect that
bug#1017905 exists because of the Rust team insisting that Debian
packaging should mimic upstream distribution design. That bug is about
a project packaged by redistributing pregenerated files, instead of what
is supposed to be the core rule in Debian: Packaging the preferred form
for editing.
You apparently work in the Rust team. If it works for you, then great -
I am not saying you should leave. But I am saying that I am torn
between wanting to collaborate and then having strong opinions myself
that arguably hinders collaboration.
I was preparing packaging of Ruma, but then saw a single package related
to that trickle into Debian, and I gave up on it: I would have packaged
a *collection* of packages together, because that is clearly how
upstream "preferred form for editing is for that codebase. But that
conflicts with the Rust team style of packaging. *SIGH*
I think a good step towards a better overview is to file ITPs. Also for
library-only crates, not only for applications.
> Sorry for a bit of an rant and the wall of text,
Thanks a lot for all that you wrote, and thanks for your work on
packaging crates.
- 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
Reply to: