Re: Is anyone maintaining (the ham radio tool) node?
Jonathan Nieder writes ("Is anyone maintaining (the ham radio tool) node?"):
> No response from the "node" package maintainers. My offer still
> stands, but I am worried that this is not going to be fixed before the
> next release.
>
> So, what next?
Our policy says that if consensus cannot be reached, both packages'
binaries should be renamed. That seems to be the case here. I agree
with the policy statement that both packages' binaries should be
renamed. (But then I would say that since I wrote the policy.)
However, we have a process difficulty, which I think may be part of
what is blocking these changes from being made. Normally a maintainer
would make such a change to their own package. However, if the
maintainer of package A uploads a rename of their binary to foo-A, the
maintainer of package B now has no more incentive to fix the problem.
A's maintainer leaves themselves open to the maintainer of B "winning"
through B's inaction.
Now I'm not accusing anyone of dishonesty or bad faith, but it's easy
to see how this is not an attractive proposition for A, particularly
given that in Debian we don't have any tradition of forcing people in
B's situation to act and our mechanisms for bypassing an inactive B
are cumbersome and slow (to say the least).
I think the best way to fix this is to prepare both renaming uploads
in advance, and allow either of the two contending maintainers to
upload both packages simultaneously.
So I would suggest that:
1a. The maintainer of "node" should prepare a new version of the
package where the "node" binary is called "ax25-node", and
containing whatever transitional arrrangements etc. they are
happy with. (It may be necessary for the maintainers to notify
each other of their proposed new version numbers, so that the
package dependencies can be correct.)
However, the "node" maintainer should not sign the package and
should not actually upload it. They should instead put it on a
public server (not mentors.debian.net, to avoid accidents!) and
send an email (signed with their Debian key) with the details
(including the checksum of the .changes) to the bug report and
the "nodejs" maintainer.
(1b. If the maintainer of "node" is not a DD or DM, and therefore
normally needs a sponsor for their own uploads, they should now
seek and obtain technical review from a sponsor. The sponsor
should, if satisfied, send an email to that effect signed with
their Debian key.)
1c. The maintainer of "nodejs" should download this package and
review the handling of the name change. If the "nodejs"
maintainer considers that this upload fixes the problem
according to policy they should say so.
Simultanously:
2a. Likewise the maintainer of "nodejs" should prepare a version
of the package where the "node" binary is called "nodejs".
(2b. Likewise any necessary sponsor review of "nodejs".)
2c. The maintainer of "node" should review this, as above.
After mutual approval of each package by both maintainers, ie after
each maintainer has said "yes" in step 1c/2c:
3. Either maintainer may upload _both_ packages. (In general this
would most conveniently be done by the maintainer who is the
later to give their approval.) The maintainer doing the
uploading should upload their own package first.
(3a. Alternatively, if either of the maintainers is not a DD,
the may request a sponsor to upload both packages. The sponsor
should confirm both approvals as above, and also confirm that
any necessary sponsor review by a DD took place earlier, but
need not undertake a technical review.)
4. If something goes wrong with this process, which results in only
one of the packages having its binary renamed in the archive,
both maintainers agree that the other maintainer may send an NMU
to fix this to DELAYED-7.
I include the stuff about sponsors, and failure recovery, in case it's
relevant, so that my proposal can be used as a template in future
cases.
Ian.
Reply to: