On Mon, Apr 16, 2018 at 09:10:34AM +0200, Ansgar Burchardt wrote:
> Scott Kitterman writes:
> > Personally, I think people should be more annoyed at the people doing
> > the hijacking than the one they did it to.

> I thought this is called "salvage" now?

I believe I was the one who originated the term "salvage", so I want to
make clear why I thought it was important to change our terminology.

A few years ago, it was common practice to refer in QA circles to taking
over abandoned packages as "hijacking".  Hijacking is a hostile act; it is
forcibly taking something that is not yours from someone else.  The problem
with referring to QA work as "hijacking" is that it *signals that forcibly
taking over packages from other maintainers without coordination is ok*.

My goal in introducing the term "salvage" was to distinguish the QA activity
of identifying abandoned packages which we collectively agree should be
given to a new maintainer, from the antisocial act of a developer claiming
maintainership of a package without going through a community process.

If we have now come full circle and are calling the second act "salvage",
then we have reintroduced the original problem of implicitly blessing
package hijacking by an individual uploading developer.

> There might have been some miscommunications, but given an acceptable
> alternative is just requesting the removal of a package with open RC
> bugs that hasn't been uploaded for a time, isn't just salvaging the
> package by adding oneself as a maintainer better?

> And if this is the preferred outcome, shouldn't the salvaging be
> "easier" than just requesting removal (which is just one bug report
> away)?

First, by not following best practices of reaching out to the existing
maintainer beforehand, you are dishonoring any in-progress work the
maintainer has on this package (since they are a sole maintainer, there is
no reasonable expectation that their in-progress work will be globally
visible; the onus is on the non-maintainer to inquire).

Second, in this case the maintainer noted concerns that the new upstream
releases have not been of sufficient quality to fix the RC-bugginess of the
package.  Making it "easier" for a no-maintainer, who doesn't have the same
context of the package's maintenance history, to take the package over in
order to get it into testing without addressing the maintainer's concerns,
is not obviously a win for our users.

Further, in this case it appears someone added themselves as a comaintainer
on the package.  This seems to be something people do when they want to
signal that they are only trying to help and are open to collaborating,
rather than trying to take the package away from the original maintainer.
But I don't think anyone who has thought about this for more than two
seconds from the perspective of the existing maintainer can believe that
someone adding themselves as a comaintainer /without ever communicating with
the current maintainer/ is anything other than a hostile act, because you
have deprived the maintainer of the opportunity to refuse that particular
form of "help".

I think the particular structure of, and ambiguous messaging around,
collab-maint on alioth has definitely contributed to this.  People are
wrongly left with the impression that hosting a project under collab-maint
means that all uploading developers are free to consider themselves
comaintainers, when the original presentation of collab-maint was that any
developer can commit to the repo, /not/ that any developer should feel free
to upload the result without coordination.  I am hopeful that the move to
salsa means we will have less of this sort of thing going forward, since
creating a separate project under salsa is now not so heavy-weight that it
steers maintainers towards collab-maint with its unintended consequences.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slanga...@ubuntu.com                                     vor...@debian.org

Attachment: signature.asc
Description: PGP signature

Reply via email to