[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


  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


Reply to: