Re: Upstream Advice?

[Greg Troxel <gdt%lexort.com@localhost>]

Chris Maness <christopher.maness%gmail.com@localhost> writes:

> I have uploaded two pkg programs on GitHub --  ham/tnt and ham/dpbox.
> They sort of work on a modern NetBSD system, but need patching and
> modernization.  I have begun this process, but also want this
> reflected in a public place since I can't email the author with
> patches for him to commit my changes to the upstream tarball.  My
> changes are made after "make patch".  So I am including the pkgsrc
> patches on top of the pristine upstream tarball in my git repository.
> I would imagine that the correct way to do this is to become the pkg
> maintainer, then move upstream to github with the pristine upstream
> source from the original author (no NetBSD patches applied).  Then I
> could make my patches part of the applied patches that NetBSD applies.
> I am not sure what is best.  It used to work in Linux, but the latest
> version of Linux I could get it to compile on was c. 2006 distro of
> Slackware (v.11).  This is ancient.  It compiles on NetBSD, but runs
> with lots of bugs and crashes.
>
> Probably the BEST BEST way is to fix it for modern Linux, then port
> the fixed version here to pkgsrc so everybody can reap the benefit,
> but I don't think I have the motivation for that.

There are two separable issues (speaking generally here):

  When pkgsrc adds a patches/pathc-foo, often it is a bugfix that
  belongs upstream.  Sometimes it is a pkgsrc preference, e.g. putting
  in @mandir@ and substituting it instead of prefix/share/man.  The
  first kind we should send upstream and hope that upstream applies it.
  A test of whether it belongs is "if someone were compiling this on
  NetBSD, or on some other OS, not in pkgsrc, should they have the
  patch?"

  Sometimes people that are upstreams stop maintaining, for any of a
  number of reasons.  When this happens, often there is a "continuation
  fork" that seeks to carry on.  Sometimes people ask the upstream
  person, if they are reachable but just not maintaining, and sometimes
  you can't.  Sometimes various users collaborate.  It is often best if
  there is one continuation, but many things are often messy.  The
  pkgsrc MAINTAINER, when there is a non-functioning upstream and a
  continuation fork, can switch pkgsrc to use the fork.

So, you are

  accumulating patches in pkgsrc

  starting to be a continuation fork

Advice:

  Try to contact anybody else who is contemplating or taken steps
  toward a continuation fork.  Largely you have the same goals.

  I would say that as a continuation fork you should try extra hard to
  have clean changesets with good commments, starting from the last
  release from the original upstream.

  A continuation fork should aim to fix bugs so that it builds cleanly
  and works on all currently-maintained reasonable mostly-POSIX systems.
  Many of the problems are likely not OS-specific, but there are going
  to be OS-specific changes.

  I don't know about the build system, but the less you can change that
  you don't have to change, the better, until you choose to bit that off.

  Releases are necessary.  There are an infinite number of version
  numbers available.  Release as soon as it's better and all the
  available fixes are applied.  (pkgsrc has a very strong bias to
  releases.)


Once you have a continuation fork, then you the pkgsrc maintainer can
submit any changes that belong upstream and apply them there.  Once
there's a release, you can drop them from pkgsrc.

In pkgsrc-wip especially, there is a culture of foo-snapshot which
tracks an upstreams VCS tip.  (It's best named not -git because the
particular VCS is not important and not -devel because on many GNU/Linux
systems there is a culture that users use software but not dot build
anything and thus bar is missing headers and libraries and bar-devel is
the rest of what belongs in the package.)    Having a -snapshot package
is especially a good idea as you fix things and land them upstream, so
you can stop carrying patches earlier.

Obviously maintaining a continuation fork is a lot of work but the total
work among multiple people who care about different packaging systems is
less than each of them going it alone.