Bug#995341: Highly inappropriate behavior which the RT should be aware of
On 10/1/2021 5:48 AM, Diederik de Haas wrote:
Hi Release Team,
I want to make sure that you're aware of what I consider HIGHLY inappropriate
behavior by Chuck where he is trying to sidestep/override the Xen maintainers
by filing this bug directly to the release.debian.org pseudo package.
This only appeared on the Debian Xen maintainers' ML because Chuck went on a
severity-dance where he *also* changed the severity of bug #994899, which _is_
assigned to the Xen package and therefor the Xen maintainers could see it.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#10 I tried to
steer the efforts to getting the issue fixed in a more constructive manner.
I failed at that.
We've already identified a possible fix, which I can point to if so desired, but
I don't think the RT should be bothered with this (dispute).
I respectfully disagree, because as I have mentioned repeatedly both
in this report and in #994899 that the process of migrating the
stable package of the xen hypervisor for amd64 broke because when
bullseye was released on August, 14, 2021, that package still contained
patches from the unstable upstream Xen 4.16 branch, whereas the
version advertised by Debian for the stable release was, and still
is, the stable upstream of Xen, version 4.14.
It may be news to Chuck, but not the RT, but a package maintainer has the
prerogative to include additional patches in the package that gets uploaded to
the Debian archive. (It happens all the time)
And that can introduce bugs. Shit happens. You learn from that. And then you
go on fixing those bugs *in coordination with* the package maintainers.
Perhaps it may be news to Diederik that the Release Team does have
the prerogative to review and either accept or reject a series of
patches from an unstable upstream branch into the stable release
and respond to a request from a user/volunteer to review such
patches that obviously can and in fact did cause bug #994899 in
this case.
It may have just been an oversight, but in this case, IMO, the package
maintainers *should* have notified the release team of the unstable
patches from Xen 4.16 that were in the supposedly stable 4.14 xen
hypervisor package for amd64 sometime BEFORE bullseye was released
as the new stable version on August 14, 2021, so the Release Team
could decide if the unstable patches could stay in the formal release of
bullseye. IMHO, it is up to the Release Team, not the package maintainers,
to decide if Debian specific patches from an UNSTABLE upstream branch can
remain in a package of the STABLE upstream version at the time of the stable
release. The package maintainers never gave the Release Team a chance to
review the upstream unstable patches before bullseye was released.
It is also for the Release Team, not the package maintainers, to
decide if those unstable patches can remain after a user/volunteer
requests that they be removed as the appropriate way to fix a bug
in the stable release that is caused by the presence of the unstable
patches in the stable release.
I would be much less inclined to request that the Release Team review
the unstable patches that are causing #994899 if there was some
evidence that upstream plans to eventually backport those patches from
Xen 4.16 to Xen 4.14. At present no such evidence exists, and perhaps
a way to resolve this controversy is for Debian to submit a pull
request to the Xen project to merge the unstable patches in Debian's
current Xen 4.14 packages into Xen's stable Xen 4.14 branch. If upstream
endorses the unstable patches as suitable for their 4.14 stable release and
eventully commits them to their 4.14 branch and subsequent upstream
point releases, then I would also accept them as appropriate for the Debian
package of the upstream stable 4.14 version of Xen that targets the stable
version, currently bullseye.
Regards,
Chuck Zmudzinski
What you don't do, is try to go above/around them by addressing the RT
directly.
One should have at least the decency to directly To/CC the package maintainer
when you do, which in 99.99+% of cases you REALLY should not do.
Regards,
Diederik
Reply to: