[ntp:hackers] The Distinction between Development and Stable

Harlan Stenn stenn at ntp.org
Sun Apr 10 02:42:41 UTC 2011


Sorry for the delay in replying to this.

> I am unhappy with the current system for updates to ntp.
> Perhaps I just don't understand the system, and
> I hate to complain when everyone working on the system is
> a volunteer, but I think this is significant.
> The problem is with their being a Development and a Stable Distribution.
> In the past we had a single line of development for ntp.
> Then the distinction between Development and Stable was made, with
> the implication that only serious errors would be corrected in both
> Stable and Development, and all other changes would be made in Development
> only.  This clearly is not what is going on.

It is going on that way for some folks.  And I think we might have had
this discussion before.

Please see http://support.ntp.org/bin/view/Dev/MaintainerIssues .

As a refclock maintainer, it is *your choice* where to put patches.

If you think a patch you are working on is a candidate for stable,
please see the instructions on that page for "Fixing a bug in both
-stable and -dev", and if those steps are followed then there will be a
new -stable patch release that includes your fixes, and about that same
time there will be a new -dev release which also contains your fixes.

When ntp-dev is "ready", it will become the next -stable.

I was planning to release 4.2.8 at the end of last year, but an internal
issue came up that has sucked up way more of my time than I would have
preferred, and it basically delayed things by about 6 months' time.

> My assumption was that folks using the Development branch would discover
> any problems with the patches applied there, before they became a part
> of the Stable branch.  And there was an inherent implication that
> the Development branch would be 'swept' into the Stable branch at
> reasonable intervals.  My assumption for the timing of a 'sweep' would
> be the next Release Candidate of the Stable release.
> This does not seem to be the case.

I would prefer to have new "full" stable releases about once a year or
so.  Lately that hasn't happened, and I am actively working on creating
a framework that will get this goal back on-track.

> I have some patches in the Development version of ntp that have been
> sitting there for a year.  It would seem that the ONLY way a patch
> is going to make it into the Stable version of ntp is to put it there
> directly, which then opens the question of WHY we have both Distributions.

Because without 2 branches we only have 1, and that is an immutable
-stable release and a potentially indeterminate -dev cycle.

We went to 2 branches so we could have the *option* to put fixes into
-stable.  But it's up to the refclock maintainers to decide if they want
their fix in -stable and -dev, or only in -dev.

> There seem to be lots of changes being made to Stable, yet the
> changes which have been tested for a year in Development are still
> there.
> Do I make one GIANT update to the ONCORE driver (it would be over
> 1000 lines) of the differences between Development and Stable and
> submit it?  I had assumed that BK had some sort of 'pull' mechanism
> and that this would be invoked every now and then, but that
> does not seem to be the case.

The only time what you describe happens is when I make a new -stable
release.  As I said, that was originally scheduled to happen at the end
of 2010 and I now expect it to happen in a couple of months' time.

> So, do I misunderstand the update process, or do I need to make
> the GIANT update???

I'm not aware of any major changes in the refclock "API" between -stable
and -dev.

While I'd rather not start another RC cycle for -stable given that I am
hoping to start the RC cycle on -dev within the next month or so, if you
want to see if you can just backport refclock_oncore.c from -dev to
-stable we can do that.


More information about the hackers mailing list