tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
individual software releases for third parties
At the beginning of this year, rmind suggested an idea to the Board
about creating separate packages of TNF softare for the use by
third parties. Basically this means providing a simple tarball of
the specific code that can be easily and portably built and installed
without NetBSD. rmind suggested some benefits: encourage third
parties to continue using our code, increase reliance on our code,
gain more visibility, promote NetBSD trademark, and increase our
userbase.
We have a lot of code bundled with or packaged by other projects, such
as: ipsec-tools (racoon), libedit/editline, bmake (pmake), rcorder (and
rc.d scripts), libc, glob/fnmatch, makefs, rbootd, sh (Ash), stat,
tnftpd, tnftp, vacation, and others. We have lots of other software to
share too. I started a list of software (already shipped by others or
should be considered) at
http://wiki.netbsd.org/individual-software-releases/ .
In most cases, it is not trivial or quick to use our code; for
example maybe no tarball and maybe not portable to build. Some
third-parties extract code from our cvs or source tarballs, add or
improve portability, and then maintain it without NetBSD involvement.
We should make it easy for third-party users to work with us.
We have had a few of our softwares provided with autoconf/automake
environment and available via tarballs, but most of these have been
unmaintained and now just contained within the pkgsrc tree itself
(for bootstrapping purposes). (I made an autoconf'd tarball for
mtree several years ago as one example.)
Some thoughts on this:
- develop some tools to help automate the tarballs from our src tree
(there has also been some discussion about having a new place in the
src tree for this code to share)
- provide a maintainer per component (maybe a minimum 6 month commitment?)
- talk to existing packagers (or third party bundlers) for what they want
or need
- provide webpage and README; this will define the communication channels
for the software (probably existing mailing lists, like this one)
- as applicable autoconf (or consistent simple environment detection
build script) or portable simple makefile.
- provide updates (new tarballs) for the software as needed.
- make this consistent for all the software.
What do you think? Please share your thoughts on how we can organize this
including technical aspects.
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
Home |
Main Index |
Thread Index |
Old Index