Re: O: nvi - 4.4BSD re-implementation of vi
On Sat, Jan 26, 2013 at 12:38:07AM +0000, Stuart Prescott wrote:
> Package: wnpp
> Severity: normal
>
> The maintainer for the "nvi" package has indicated that he is unable to
> maintain this package for the time being. I'm marking this package as orphaned
> now. If you want to be the new maintainer, please take it -- see
> http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions
> how to adopt a package properly.
>
> Description-en: 4.4BSD re-implementation of vi
> Vi is the original screen based text editor for Unix systems.
> It is considered the standard text editor, and is available on
> almost all Unix systems.
> .
> Nvi is intended as a "bug-for-bug compatible" clone of the original
> BSD vi editor. As such, it doesn't have a lot of snazzy features as do
> some of the other vi clones such as elvis and vim. However, if all
> you want is vi, this is the one to get.
>
Looks like this is still orphaned over ten years later.
As an active nvi user I would love to step up and help, but the biggest
problem I see is that the choice of upstream project. Since the original
is gone there isn't a clear successor.
The BSDs all have their own forks which diverged over time (and those don't
build on Linux).
The other two options there are today are https://repo.or.cz/nvi.git which
d/control currently points to and more recently https://github.com/lichray/nvi2.
The first has a very low commit frequency (last commit was 2020, before
that 2016) and sticks very closely to the original source. nvi2 has added
new features such as multibyte support and is starting to receive bug fixes
and features from the different *BSD forks.
I have been thinking of proposing a new package for nvi2 but maybe it would
make more sense to move this one to the more active upstream. It looks like
some of the issues we are carrying patches for in Debian might be fixed there
already and if not they seem active enough to merge our fixes.
What would be the best way forward here? ITA and eventually switch the upstream
or start a new package and let this one continue its slow death?
Tobias
Reply to: