[ntp:hackers] The Distinction between Development and Stable
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
> 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
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