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

Bug#744820:



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).

Regards,
Vincent


Reply to: