Re: [Ipsec-tools-devel] ipsec-tools maintenance

[Noah M. <fr...@mo...>]

On Mon, May 25, 2015 at 11:59:20AM +0300, Timo Teras wrote:
> > > Debian has also collected several patches, which can be found at
> > > http://anonscm.debian.org/cgit/pkg-ipsec-tools/pkg-ipsec-tools.git/tree/debian/patches
> > >
> > > These range from simple spelling corrections in documentation to
> > > platform-specific build fixes to new features. Most of the patches
> > > should include a header explaining in more detail what they
> > > actually do. All of them are currently included in the ipsec-tools
> > > builds currently shipped by Debian, Ubuntu, and others.
> 
> Ok, I'll take a look at these. It looks some of them are already
> applied in CVS. But I'll double check.

Another interesting patch, not yet applied anywhere but proposed in
Debian, is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780666

> I was later able to reach Derek Atkins (who is still the sole holder of
> sourceforge admin rights to my understanding). He did also give me push
> access to sf.net trees, as well as file release rights.

I've emailed Derek via sourceforge to see if he's willing willing to
either add additional admins or work toward retiring the sourceforge
project.

> There was also later an attempt to spin up ipsec-tools.net (a trac
> instance) as bug tracker (apparently because vanhu/manu did not
> have/get/want/whatever sf.net access). Though, that has also vanished
> since then.

Do you know who owns that domain? Whois isn't clear, and it's possible
that it may have expired and been picked up by a domain squatter, but
I'd like to try and resurrect it if possible.

> If someone is willing to take long term maintenance. They are free to
> fork and maintain their tree. I did ask for git tree couple of
> times. Though, seems vanhu/manu were not too interested on that, and I
> did not want to fork at the time; so I've just tried to live with the
> netbsd cvs tree.

IMO the best course of action now is to create a new repository. We can
sync (both ways!) with the NetBSD repository as needed. My hope would be
that we reach a point where NetBSD is pulling from us more than the
other way around.

noah