Your message dated Tue, 4 Apr 2023 23:39:36 +0200
with message-id <zcyzgnfout5fb...@ramacher.at>
and subject line Re: Bug#1031587: [request-tracker-maintainers] Bug#1031587:
Handling of the request-tracker4 -> request-tracker5 transition in bookworm
has caused the Debian Bug report #1031587,
regarding Handling of the request-tracker4 -> request-tracker5 transition in
bookworm
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1031587: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031587
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: Dominic Hargreaves <d...@earth.li>, Debian Request Tracker Group
<pkg-request-tracker-maintain...@lists.alioth.debian.org>
Control: block 1030749 by -1
https://release.debian.org/testing/freeze_policy.html#soft
...
Dropping or adding binary packages to a source package, moving binaries between
source packages or renaming source or binary packages is no longer allowed.
Packages with these changes will not be allowed to migrate to testing. These
changes are also no longer appropriate in unstable.
...
The problem is that opening of #1030749 is de facto
a request-tracker4 -> request-tracker5 transition that
happened 4 weeks after the deadline for transitions.
There are two options for resolving this:
1. Treat #1030749 as a forbidden transition and ship both versions
of request-tracker in bookworm, or
2. grant reverse dependencies an exception from the soft freeze
rules for the request-tracker4 -> request-tracker5 transition.
For option 2 I looked at the 9 reverse dependencies of request-tracker4
in the autoremoval list:
RT extension installer that has to stop depending on
both versions:
- libmodule-install-rtx-perl
No package remame required, has to upgrade to the upstream version
that supports request-tracker5:
- librt-extension-commandbymail-perl
Ships packages for both versions and has to drop the
request-tracker4 package:
- rt-extension-assets-import-csv
request-tracker4 -> request-tracker5 transition prepared
in experimental:
- rt-extension-customfieldsonupdate
- rt-extension-calendar
- rt-extension-jsgantt
- rt-extension-nagios
- rt-extension-smsnotify
Update to latest upstream version and package rename required:
- rt-extension-repeatticket
--- End Message ---
--- Begin Message ---
On 2023-03-30 01:24:56 +0100, Dominic Hargreaves wrote:
> On Mon, Mar 20, 2023 at 11:06:49PM +0100, Sebastian Ramacher wrote:
> > Hi Dominic
> >
> > On 2023-02-27 15:50:05 +0000, Dominic Hargreaves wrote:
> > > On Thu, Feb 23, 2023 at 04:54:33PM +0100, Paul Gevers wrote:
> > > > Control: tags -1 moreinfo
> > > >
> > > > Hi,
> > > >
> > > > On 20-02-2023 13:09, Dominic Hargreaves wrote:
> > > > > If the release team would be willing to grant an exception to the
> > > > > policy
> > > > > to get this done, we can get this wrapped up inside a week I expect.
> > > >
> > > > Can you please confirm that everything is ready to do this? I.e. there
> > > > is no
> > > > "this should work but we haven't tested it" cases. If yes, then please
> > > > upload the packages that involve new binaries to experimental and when
> > > > those
> > > > are passed NEW, ping this bug. If no surprises pop up, we'll grant an
> > > > exception, but we want everything fully ready before doing so.
> > >
> > > Thanks, yep. We had planned out this transition and I feel confident
> > > the rest of it will work out (worst case we need to drop a barely
> > > used extension package somewhere).
> > >
> > > Andrew and I are working on this at the moment and will ping this bug
> > > when it's fully staged.
> >
> > What's the status of this transition?
>
> Hi Sebastian
>
> Sorry for the long delay. Myself and, I think, Andrew have been short on time.
>
> The transition is basically ready to go, but I've been rethinking the need
> to drop request-tracker4, given it will all be quite tight. It turns out that
> request-tracker4 is still supported upstream
> (https://bestpractical.com/release-policy)
> and there's no specific EoL set. When we first started the plan to
> deprecate request-tracker4 in Debian, I think we were assuming otherwise.
> The package is in good shape and I believe otherwise ready to be released.
>
> If Andrew is in agreement, I therefore think we should let request-tracker4
> be released with the next release. We can reconsider whether to drop it from
> the release + 1 at a more leisurely pace. The work we've done to date will not
> be wasted effort.
>
> I've tentatively downgraded #1030749 to signal this intent.
Okay, that's fine. I'm closing the bug now. Andrew, if you disagree,
please feel free to reopen it.
Cheers
--
Sebastian Ramacher
--- End Message ---
