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
signature.asc
Description: PGP signature
