Re: [gpsd-dev] Moving ntpd to an open VCS

[Dave Taht]

On Tue, Oct 22, 2013 at 9:17 PM, Eric S. Raymond <address@hidden> wrote:
> Harlan Stenn <address@hidden>:
>> 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 don't think I understand "must be more than just bk and git".

>>
>> 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.
>
> We have a pretty serious culture clash here.  Several of your
> assumptions are deeply in conflict with the way open-source people in
> general want to do things.
>
> I'm not going to do an RMS and scream that you're evil; I don't roll
> that way.  But the conflict is a problem for you because it cuts you
> off from your most natural source of development talent, and damages
> your ability to cooperate with peer projects such as GPSD.
>
> ntpd's driver list already has the smell of stagnant backwater about
> it.  The longer your policy choices self-segregate you from the
> open-source community, the worse that kind of problem will get.
> Eventually, it will be terminal.
>
> Now I'll identify the specific points of conflict I see.  Please do not
> mistake any of this for personal hostility; I'll still cheerfully
> cooperate with the ntpd project where your choices make that possible,
> and I expect that is true of most of my GPSD colleagues as well.
>
> 1. Bitkeeper?  Really? After the Great BitKeeper Flap of 2005, this is
> guaranteed both to make you no friends at all in open-source land and
> to make you a lot of vehement enemies.  Larry McVoy's behavior made a
> really bad stench in our collective nostrils; trying to argue his side
> would make it worse.
>
> 2. I have my own issues with git - at the design level I actually
> prefer Mercurial in many ways.  But Mercurial lost the war; I have
> recognized this, surrendered and use git anyway.  I advise you to do
> likewise.

I agree that git has won. And there are zillions of useful tools and
services using it now. Even the fcc uses git....

> In 2013 the only people who don't take flak for using
> other-than-git are a handful of Mercurial bitter-enders, Mark
> Shuttleworth's employees (because he pays them to use bzr), and legacy
> Subversion users.
>
> 3. Your claim that there is a clear and obvious case for keeping
> security patches private is not generally accepted by the open-source
> community.

Um, er, I think there is a strong community that favors keeping a security
tree/patches private for as long as needed to fully test, make ready a
fix, and cycle a new version to the field.

I note that all the current generation scms (git/bzr/mercural/etc)
make it very easy to keep private branches like that. Companies like
github make their living from the necessity to occasionally have a
shared private branch.

Companies like isc do contract work first in a private branch.

It is not, I'll admit, a particularly successful model for new
development, but it does aid in creating security related patches.

> I'm not going to argue the merits here because my personal
> views are not very relevant; what matters is the social fact that most
> open source developers are fans of prompt full disclosure, or at most
> a very short timeout.

NTP is a core network-facing service. It arguably is as common as dns,
perhaps more so on some platforms.  As such it is potentially subject
to attacks on a grand scale, and caution is indicated for making ready
and distributing new releases. Worse many machines running ntp are
old, unmaintained machines, that do not get much attention or updates
over their lifetime.

A hole in NTPD granting root privilege would be devastating across the
internet.

> The minority that partially agrees with you will

count me among that minority!

> not save you on any of these other issues.

true.

> 4. Your plan of "offering read-only access under an NDA to development
> repos" will be highly toxic to a community that generally considers
> NDAs to be the moral equivalent of nerve gas. This one is a
> showstopper, a crash landing, war to the knife.  You'd have an easier
> time feeding pork to Muslims.

I tend to view ntp as a rather stable service basically in maintenance
mode. I have no idea what new features would require NDAs... nor do I
know of a way to get new features paid for.  What new features are on
the table?

What bothers me is that inferior versions of ntp (take the busybox
version for example) have huge amounts of penetration due to their
comparative simplicity.

> 5. Source developed in parallel in two or more distinct repos?

Generally there needs to be a repo format that is "core" and a patch format
that is acceptible. I don't know to what degree a core maintainer working in
bitkeeper today could take patches generated by a downstream git
user... but I suspect it would be ugly.

one of my main projects (openwrt) is partially maintained in svn, and there is
a regular svn to git pull that happens. I work out of git because of
how easy it is to have a private repo, and while using the svn-git
conversion is useful for those that mostly read patches, but: whenever
I bother to submit one, going from git to svn back to git again
inevitably requires reverting the local patch, which is a pita.


> Unless
> there's automatic commit propagation among them, this is going to make
> hackers question your competence (and possibly your sanity).  Which
> wouldn't be an insuperable problem by itself.  But when you're also
> bucking the open-source crowd on what it considers core ethical and
> best-practice issues, the exposure you can least afford is looking
> incompetent.  That's like blood in the water to sharks...

ntp's culture goes way, way, way back.

> You might be able to buck community sentiment on *one* of these (2
> would probably be the least difficult) and still recruit enough talent
> from us to keep your codebase in good shape.  Well, on any one except
> 4; that one is, like, grabbing for the third rail.  But all five?  No
> chance. None at all.

NTP has "survived" for years on its existing development model. There
is no viable replacement, and not a lot of interest  in a generation
that thinks python and javascript can be used for everything.

*I* would certainly like a better ntp: bad chimers automagically
kicked out, a sane set of statistics on one way delay measurements,
good hooks to pps/gps/lte and other sources of reliable time, and
sanely configurable crypto...

but I'll argue it would require a seriously prolific, caring, new
generation of coders overwhelming the previous one with patches to
change the backend scm and long established development practices.



-- 
Dave Täht