Hi Scott, On Tue, Feb 04, 2025 at 01:22:18PM +0000, Scott Ashcroft wrote: > Then out of blue there was an upload in January, still based on an old > version.
Larry reminded me to do it that's why :-)
As much as I try sometimes these mail threads end up not going to the BTS,
gah.
The short of "why still 0.33" is new versions introduce new problems and we
were still fixing the old ones (reproducibility). When contributor time is
the limiting factor Debian tends to prioritise stability over latest and
greatest features.
You're very welcome to help with that, but you have to understand that
Debian work is more time consuming than that you may be used to in almost
every aspect imaginable. We have a plethora of architectures to support,
stacks of policy to conform to and more users than one might reasonably
expect ;-)
The very first step for reviewing a new upstream version is always
copyright/DFSG review which is just going to take a serious amount of time
right off the bat with 43k lines added in this case.
These factors are why you'll find us DDs are slow to review new
contibutions at times because it's a *lot of work* and while reverting a
botched new upstream import is in principle always possible it's ugly (See
debian-policy 5.6.12.1. on use of +really), represents even more work and
after the xz incident we're just a tad more paranoid in general :-)
Your MR in particular was looking very good but missing a lot of context on
the doc side of things: why is presentation.pdf being removed? justification
for dropping patches (upstreamed/obsoleted/conflicting..)? did you even test
the new docs build? What about reproducibility testing? (since you're
removing a SOURCE_DATE_EPOCH patch).
I appreciate Andreas jumping in here to provide a new contributor with some
(immediate) positive feedback, which we tend to be collectively bad at in
Debian. However just hitting the merge button doesn't answer any of those
hard questions, only you can realistically do that.
> So I got a salsa account, did the work to clean up my local packages,
> committed the changes and sent out a merge request.
>
> It got merged and I hoped that one of the uploaders would be able to use
> it as a basis for a new upload.
>
> However, that doesn't seem to be the case.
Maitainers are usually quite busy. This weekend FOSDEM consumed many
people's time (including mine). One week is a reasonable time after which
to ping people on IRC, not for despair :3
> So I'm looking for advice for what I should do next.
>
> Should I go through the process to upload my packages to
> mentors.debian.net? Or is there a better route to take?
In general the escalation order here is something like this:
1) Mail Maintainer through BTS:
- Note this could be a Team mailinglist or a person.
- File "new upstream version pls" bug or reply to existing one.
- For reply note that nnn...@bugs.debian.org only sends to Maitainer so
you must CC other people you want notified.
2) Mail (CC) Uploaders directly (if Team package) or ping Maintainer again,
- If no response ping on #debian-$team or find Maintainer on IRC
4) Upload to debian-mentors *and* post RFS bug.
- If no response ping on #debian-mentors
5) Despair and write a strongly worded physical letter to your governing
body of choice on the pressing matter of funding FLOSS :-)
6) Optionally lament on IRC in #debian-devel and/or debian-devel
mailinglist.
((I wonder if we have something like this written down in the wiki already))
Something else to keep in mind: Salsa notifications are unreliable as they
are opt-in for maintainers. Always follow up through BTS/mail immediately
or after a couple days if you don't want MRs/issues to be lost. [[Yes this
sucks. I'm as frustrated about that as anyone but it's how it is now. Git
is still "new" in many Debian people's workflows and Salsa even more so.]]
Mentors is always an option as any DD can upload any package in principle
(as a non-maintainer- or team-upload). When they are not supposed to due to
policy/convention they're likeley to tell you, but you can read up on the
guidelines in developers-reference as they can prevent certain types of
changes to be made without Maintainer involvement in some situations:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus
Thanks <3,
--Daniel
signature.asc
Description: PGP signature
