>>>>> "Mark" == Mark Hindley <m...@hindley.org.uk> writes:
Mark> Sam, Since I cannot get a working and robust dpkg-divert
Mark> solution, I feel the need to revisit the validity of these
Mark> concerns.
I'd like to push back on the phrasing here.
What i'm hearing is that after spending a couple of weeks exploring ways
to meet these concerns, you'd now like to push back on whether they are
a good idea in the first place.
That seems dismissive both of Julien's concerns and the engineering
effort you and others have spent exploring what the valid options are.
I agree with you that it's time to go back and revisit whether these
concerns are requirements that we can meet.
But that's exactly because you've spent time working to address the
concerns. In particular:
* You have explored and documented why libelogind0 needs to be a
different implementation than libsystemd0: while its API and perhaps
DBUS interface is the same, its cgroup interface is very different.
* You have explored options for maintaining libsystemd0 and libelogind0
co-installable and described problems with those approaches: namely
that there is a significant period on every upgrade where libsystemd0
will be used rathen than libelogind. That period will depend on how
many packages are being unpacked before triggers get run.
I haven't responded to your text because I disagree with your premis.
You seemed to be trying to show that no problem could exist. Since the
concern raised explicitly included problems caused by our incomplete
understanding of what apt's dependency resolver will do, that's a really
hard thing to do, and I'd expect that if you went down that path it
would involve formal proofs and some model of apt's behavior.
Instead, I think you've done the work to argue that you have the best
option anyone has come up with. You've explored the other options Simon
and Michael have suggested and explained why they won't work.
You've worked with the Apt developers to resolve the concrete problem
that Simon had with your approach.
In your testing you are not able to produce particularly bad
situations.
I think it is fair to ask Julien as the bug submitter to engage here
either by coming up with new options that none of us have explored or by
coming up with specific problems. Alternatively it would be reasonable
for him to ask someone else who has more time to dedicate to this issue
to step in.
In general, we expect maintainers to respond to RC bugs within two
weeks.
I think that in a situation like this it would be reasonable to expect
Julien to respond within two weeks as well.
However, for your information, DSA is having some significant hardware
challenges and I think he is very involved in that.
I'd recommend being very receptive to a specific request for more time.
Assuming no response, I think it would be reasonable for you to close
the bug after the timeout arguing that you have considered the issues
he brought up, considered alternative designs, and articulated why this
is the best option.
I won't lie: there are various ways politics can happn at that point.
I have a couple roles in this:
1) facilitating communications.
2) I'm an experienced Debian Developer. I'm giving you advice on what
is reasonable process in handling an RC bug. I don't have any DPL
powers in that regard; other DDs may disagree with me. If you want to
double check my recommendations with other developers that wouldn't be
bad. If other developers pop up here, considering their input would be
a good idea.
3) I cannot review specific Release Team decisions. I do have a role in
reviewing whether the release team is using a reasonable process and
talking to release team members or release managers when I have concerns
about that. Ultimately, I can ask the project to review a release team
decision if I think the process is unreasonable. (I have the technical
power to ask the project to review a decision in other circumstances,
but I would be much more reluctant to use that power in a situation
where I thought the process was reasonable than in a situation where I
thought it was not.)
--Sam
