[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Clarifications needed for the time-service HOWTO

From: Harlan Stenn
Subject: Re: [gpsd-dev] Clarifications needed for the time-service HOWTO
Date: Wed, 23 Oct 2013 01:10:36 +0000

"Eric S. Raymond" writes:

> I'd be *quite* willing to contribute to the ntpd code.  But there's a
> showstopper; no public repo access.  Their stuff is trapped in a
> Bitkeeper instance, no open-source clients allowed.  Which severely
> limits ntpd's developer pool - gonna be a problem in the long and
> maybe not-so-long term.

There are two issues here, one is public access and the other is tool
choice.  More below.

> Harlan, if you ever decide to fix that, it just happens that one of my
> other projects is the best-in-class tool for repository conversions
> (reposurgeon).  It would take some reverse-engineering of BitKeeper to
> break your code history out of jail, but I'd do it.

First, I *love* the way bk works for me.  I find it far easier to use
than *anything* else I have looked at, and for my use as a developer,
patch integrator, build engineer, and release dude.

Getting our metadata and history converted from bk should not be an
issue, should that be useful to do.

I would be happy to see the released NTP codebase be available under
more than just BK.  But it *must* be more than just bk and git, and I
must have committed sysadmin help for the non-bk repos.  I will not
allow them to bitrot in case of problems and I do not have the spare
cycles to admin those.

I have used git and I am not thrilled with it.  From what I have seen,
git is a versioned filesystem.  That's not quite the same as an SCM.  I
do not have the spare cycles to rehash or re-examine other SCMs right now.

There must be support for keeping at least certain collaborative
development repos private (non-public).  There is a clear and obvious
case for this regarding security patches.  There is a slightly less
clear and obvious case for development repos being public in general.
One decent reason for keeping development repos non-public is that it is
a potentially valuable resource to companies, and offering read-only
access under an NDA to development repos is a good way to provide value
to institutional members.  There's nothing wrong with providing free
institutional membership to free software OS projects.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]