Subject: Re: pkgsrc on Solaris
To: None <segv@netctl.net>
From: Jonathan Perkin <jonathan@perkin.org.uk>
List: tech-pkg
Date: 12/12/2005 23:03:57
* On 2005-11-17 at 13:28 GMT, segv@netctl.net wrote:

> Another point I would like to bring up is bug reports management and
> resolution. I do understand that work on pkgsrc is done by
> volunteers in their spare time, however I do get the feeling that:
> 
> 1. When submitting bug reports for Solaris, they get assigned to
>    solaris-pkg-people
>
> 2. Bug reports/patches sit there for months and solaris-pkg-people
>    don't do anything noticable about them. Checking out current
>    pkgsrc, I see the same old bugs that could have been fixed ages
>    ago.
> 
> I don't really know who solaris-pkg-people are and how much workload
> they have, but when people submit patches, etc., and they just
> stagnate in bug database, it makes you feel a bit discouraged.

There are only 4 of us currently, and like Grant I've had little time
for pkgsrc recently (as me replying to month-old threads on tech-pkg
probably shows!)  You're right though, PRs in our queue do tend to sit
and rot a bit, so apologies if this comes across as us being
ungrateful for the reports and patches that you produce.

I would however like to mention that for fixes which directly patch
the original source distribution rather than our Makefile/PLIST etc,
the best approach would be to feed the patch back directly to the
vendor.  In the strictest sense, the bug is with the software, not
pkgsrc, so should go to the appropriate people.  They are more likely
to have a vested interested in having their software work on other
platforms, and can probably test better than we can (often our patches
are integrated based only on the fact it makes the software compile,
not that it now behaves correctly and as designed).  There is also a
good chance that they will integrate the patch quicker than we will :)

This has the added bonus of making the package easier to maintain in
the future when it comes to upgrading to a later version, rather than
us having to amend a large number of patch files to accomodate their
latest source tree.  Another benefit of this approach is that we start
to teach the vendor how to write portable code, so that any future
software they write may not make the same mistakes and has a bigger
chance of working out of the box in pkgsrc.

I'll see if I can review the PRs we have in the new year.

Thanks,

-- 
Jonathan Perkin                                     The NetBSD Project
http://www.perkin.org.uk/                       http://www.netbsd.org/