Hello Paul.
I sent the unblock request for MLMMJ 1.5.2 before seeing this email.
I was not aware of the +really version numbering before originally
replying, later I read about it in one of the developer documents
(probably Policy). That must have been implemented since the last time I
had read the documents, I had not seen that before.
Whether it's recognized or not, there are three sets of policies at play
here -- first there's Debian's policies, then there's mine as the
package maintainer for what I'm willing to support, and then there's
upstream for what they're willing to support. What I'm being requested
to do for this bug is to break MLMMJ further by uploading a 1.3.0-5
package removing mlmmj-php-web-admin and mlmmj-php-web, the resulting
package of which I and upstream would need to do stable support for at
least the next 3 years, as well as other Debian teams during and long
after that. I've had to deal with bugs on old packages both stable
releases and LTS uploads afterwards, so I know what that's like.
The MLMMJ 1.3 package has bugs that have been found because of the new
tests which I think likely existed long before. And the 1.3 package has
packaging I have never been comfortable with. So what I'm saying here is
that I am not willing to support that old version after having to break
it further through another stable release cycle, while continuing my
support of the updated package as long as that remains viable and
reasonable.
I use this package myself and I understand its importance. Regardless of
"low popcon" this is a mailing list manager that runs many mailing
lists, some of which are huge (1000+ subscribers). As the package
maintainer I am looking out for those that use this package. Giving
those users an ancient package that has a list of known bugs, some of
which would need to be backported to fix, I think is not in my or their
best interests.
I have had to make a new release during the Debian hard freeze cycle
before. I had to do that fo Mumble 1.3.0~git20190114.9fcc588+dfsg-1 in
2019 which was ugly because upstream was only going to support v1.3 and
did not have a stable release to offer, and I had to build the tarball
from multiple Git exports due to upstream's use of Git submodules. That
work was difficult and ugly, but it was the right thing to do and I am
proud that I accomplished it. It was hard but it was the right thing to
do. I never expect to be able to do this, it's rather surprising I was
able to do that at all during a freeze.
And so my personal plan, what I think is "the right thing", is the
following:
1. Deal with the MLLMJ build bugs to fix the code and the tests.
This part is now done.
2. Upload the fixed version for Stable if possible
3. If not, let the package fall out of the release and later do an
upload to Backports for the Stable release
Dealing with Debian Backports isn't fun, BTW, because bugs to Backports
aren't supposed to go to the Debian BTS last I knew. So the package will
have to be modified so that the bug reports go to Backports, and then
I'll need to change my Sieve mail filters in some way to grab the MLMMJ
bugs going to Backports to move them into my Debian-Bugs folder so that
I'll see them. Regardless of not wanting to deal with that complication,
I will do that, because it's what I think is the right thing to do here.
So I've written this to give you the background perspective as to why
I'm making the choices that I am.
If Thomas Goirand wishes to support MLMMJ 1.3 through another Stable
release that would be fine, as long as he doesn't expect me to be
involved in that work.
-- Chris
Chris Knadle
chris.kna...@coredump.us
On 5/31/25 08:46, Paul Gevers wrote:
Hi Chris,
On 24-05-2025 22:11, Chris Knadle wrote:
To me the idea of uploading "1.5.0 but not really 1.5.0 at all" is
just lying.
I'll admit that I was a bit blown away by this reply, hence it took me
a while to reply. Using the +really version is a very well established
way to repair uploads to unstable that shouldn't have happened in hind
sight. It's even mentioned in our freeze policy [1]
My whole proposal of using experimental was based on the idea to
repair unstable but keep the binaries, such that you wouldn't need to
go through NEW.
If you're unwilling to go back to the version in testing, I'm not sure
you leave me much room to help you to keep your package in trixie (I
see the php issue has now been filed in the bts). I'm not going to
accept 1.5.0 at this stage of the freeze:
265 files changed, 31842 insertions(+), 18429 deletions(-)
Paul
[1] https://release.debian.org/testing/freeze_policy.html#appropriate
