Bug#744820:

[Alexander Wirt <formorer@debian.org>]

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.

Alex