upstream (was: Re: sysutils/xen* clang patches for review)

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Fri, Mar 29, 2013 at 09:01:46AM -0400, Greg Troxel wrote:
 > I am bringing up the comments/upstream-tracker-links issue because I am
 > not really comfortable with pkgsrc being used to indefinitely carry
 > patches that belong upstream.  While it's progress to have the patch, it
 > also means that anyone doing updates has a lot more work to do.

As one of the chief perpetrators of such patches, I think I ought to
speak up.

There are a lot of packages where upstream is deadish but the best
response to this is not to just delete the package from pkgsrc. I
agree that carrying patches in pkgsrc is not the best way to handle
these. This is why http://www.netbsd.org/~dholland/patchkits/ exists;
I intend to be moving more of the large patchsets there in the future
as time permits. However, moving the patch sets to private source
repositories (the patchkits stuff is backed by local hg) that nobody
else can commit to also isn't the best possible solution.

Furthermore, this problem is only going to get worse in the future,
particularly in the long term; as time passes more and more software
will be more or less orphaned. For some software this is chiefly an
opportunity to delete it, the sooner the better. (lang/pnet*, for
example.) However, there's plenty of software that is neither toxic
nor useless, but isn't prominent or significant enough to prompt
someone to take over being upstream. In fact, this tends to be the
better software; good software doesn't need frequent maintenance, so
doesn't have a cadre of maintainers dedicated to keeping it going.

I have been thinking that it might be a good idea to set up,
explicitly under the auspices of netbsd and pkgsrc, a place to keep
and maintain otherwise neglected upstream versions of third party
software. I don't anticipate these versions would get noticeably more
attention than the same software currently gets in pkgsrc; but there
are a number of advantages over accumulating the same patches in
pkgsrc:
   - because they'd be actual trees, merging patches from elsewhere
     and so on is much easier;
   - if someone wants to become upstream, they can start straight from
     our version without needing to fuss about or separate
     pkgsrc-specific patches;
   - non-pkgsrc users can get up to date versions, which is
     particularly important when there are security fixes;
   - in the long run we'll probably be able to share the maintenance
     effort with other projects, particularly debian.

and relative to having one developer maintain private patchkits, or
stuffing the tree on sourceforge or github, there's the big advantage
that any of us can commit, and that the repository is backed by the
momentum of the whole pkgsrc community; things don't get derailed if
one person loses interest or gets hit by a bus.

This is not free to set up; but I think it's worth applying our
resources to. What do people think?

-- 
David A. Holland
dholland%netbsd.org@localhost