Bug#744820:

[Vincent Cheng <vcheng@debian.org>]

On Sun, Jun 8, 2014 at 11:30 PM, Alexander Wirt <formorer@debian.org> wrote:
> On Sun, 08 Jun 2014, Vincent Cheng wrote:
>
>> On Sun, Jun 8, 2014 at 11:10 PM, Alexander Wirt <formorer@debian.org> wrote:
>> > On Sun, 08 Jun 2014, Vincent Cheng wrote:
>> >
>> >> On Sun, Jun 8, 2014 at 10:57 PM, Alexander Wirt <formorer@debian.org> wrote:
>> >> > On Sun, 08 Jun 2014, Vincent Cheng wrote:
>> >> >
>> >> >> Hi Andreas,
>> >> >>
>> >> >> On Thu, Jun 5, 2014 at 3:35 PM, Andreas Rönnquist <gusnan@gusnan.se> wrote:
>> >> >> > The version in squeeze-proposed-updates (0.3.2-1+deb6u1) still got this
>> >> >> > wrong - running catfish from the terminal gives:
>> >> >> >
>> >> >> > python: can't open file '/usr/share/catfish/bin/catfish.py': [Errno 2] No such file or directory
>> >> >> >
>> >> >> > Where the /usr/bin/catfish has got:
>> >> >> >
>> >> >> > #!/usr/bin/env bash
>> >> >> > python /usr/share/catfish/bin/catfish.py "$@"
>> >> >> >
>> >> >> > it should be:
>> >> >> >
>> >> >> > #!/usr/bin/env bash
>> >> >> > python /usr/share/catfish/catfish.py "$@"
>> >> >> >
>> >> >> > (I just tested it in a Squeeze VM)
>> >> >>
>> >> >> Fixed and uploaded as 0.3.2-1+deb6u2, thanks! Jackson, I pinged you on
>> >> >> IRC, but since it doesn't look like you're going to respond anytime
>> >> >> soon, I just went ahead with a team upload.
>> >> >>
>> >> >> (Jackson: I can't believe I have to keep on saying this, but please
>> >> >> actually test your packages before asking for an upload!)
>> >> > if you uploaded the package, you have the same responsibility. I expect from
>> >> > anyone _uploading_ a package - be it a sponsor or the maintainer - to test
>> >> > their backports. That means installing the backport in a _fresh_ environment,
>> >> > before the upload. Testing means:
>> >> > - installation
>> >> > - using the software
>> >> >
>> >> > if you are uploading a bunch of dependencys, only upload after all backports
>> >> > are build and test with the whole dependency chain.
>> >>
>> >> #744820 has nothing to do with a backport. Also, I don't want to play
>> >> the blame game here, but I disagree with the assertion that sponsors
>> >> have the same set of responsibilities as the actual maintainer of the
>> >> package. In this specific case, I'm not a catfish user, I am merely
>> >> interested in fixing a bunch of CVEs against this package that have
>> >> gone unfixed for a while in stable/oldstable.
>> > Uhm, sorry. I got the wrong mailinglist. Anyhow, I disagree the sponsor has
>> > the same responsibility as the maintainer. If they don't understand the
>> > package, they shouldn't upload it.
>>
>> If sponsors were required to be domain experts in the packages that
>> they sponsor, then we'd see a lot less sponsoring taking place in
>> Debian, and a lot more packages bitrotting in the archive. I've always
>> advocated for lower barriers for contributing to Debian, and that
>> applies to both maintainership and sponsorship. In terms of
>> sponsorship, as long as the sponsor is able to fix anything he/she
>> breaks, that's fine by me; I don't see why we should be discouraging
>> people from sponsoring packages that they aren't necessarily familiar
>> with (and frankly, that's the last thing that we should be doing -
>> making it harder for prospective contributors to find someone, anyone,
>> who might be interested in sponsoring their package(s); just take a
>> look at the ever-increasing length of the sponsorship-requests queue).
> That way you are just wasting other peoples time, buildd time and so on.
> If such a policy prevents broken, packages with low quality and so on from
> being uploaded I am happy with it. And to just test some binarys, you don't
> have to be an expert.

What are you trying to imply? That I'd deliberately upload broken
packages to the archive just to waste everyone's time? Yeah, right, I
can assure you that I have better things to do with my time.

I've always advocated for a more liberal sponsorship policy within
Debian (and also w.r.t. NMUs as well, but that's another story).
Otherwise there's no hope of DD sponsors being able to meet the needs
of sponsorees. I think it's fine for sponsors to know less than the
actual maintainer(s) about the package that they choose to sponsor, as
long as they're willing to fix any breakage that they cause. At the
end of the day, I think that a buggy package with an active
maintainer/sponsor is better than an abandoned, bitrotting package
that nobody wants to take care of because of an overly bureaucratic
and restrictive sponsorship policy.

Regards,
Vincent