| Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.25-pre1-18-g20a4340 |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Mon, 11 Apr 2011, Ed W wrote:
On 11/04/2011 17:44, Miroslav Lichvar wrote:
On Sat, Apr 09, 2011 at 10:00:36PM +0100, Ed W wrote:
Been running this for a few days. Not particularly thrashing it, but
nothing untoward happened...
How are we looking for a release?
Maybe at the end of this week? Should we go with 1.25-pre2 first, or
final 1.25?
This probably seems rash since you are obviously in the conservative
release category: however, I would have preferred this release to be
(say) 1.29 with a bunch of prior releases plus bug fixes to get us to
where we are now...
You can always download the git yourself.
:-)
The point was more that I tend towards "more frequent" releases with a
sweet spot around the 2-3 month interval. The justification being that
few users will test anything other than "releases" (even as a developer
I find it massively more convenient to work mostly with "releases", and
more than a few source packages overwhelms my spare capacity.
Releases are supposed to be stable things, not works in progress.
I like the kernel release process, which I see as basically: a feature
release (2.6.x) , which is then maintained for a short period with bug
fixes (2.6.x.y), while a new feature release branch is developed and
released (2.6.x+1). I know this doesn't work for all projects, but, I
would vote for a move towards the next chrony release to be say 1.3 (or
2.0), with bug fixes named 1.3.1 (or 2.0.1) and your next big bunch of
fixes becomes 1.4.x, etc... This makes it easier to release earlier,
and if anyone screams you have a clear way to just apply bug fixes to
the last release without needing to release part developed features
The kernel is a far far more complex animal. chrony is a relatively stable
animal at present. Over the past while there have been a fair number of
additions to chrony (refclocks in particular) so one could have argued for one
prior release. Remember, the number of people using chrony over ntpd is small.
One does not want to turn people off releasing some buggy software.
This is really just a statement of the way git/hg/bzr allows us to work,
compared with old style cvs/svn...
Anyway, just my 2p.
Thanks to all for this excellent bit of software.
Agreed completely. Lichvar really has added a lot of functionality to what
Curnow originally developed and I certainly appreciate it. It is good that
ntpd has competition. Perhaps Mills will even start to pay attention and try
to improve ntpd, but I get the feeling that is an almost hopeless hope.
It would also be good to get someone to study the advantages and disadvantages
of chrony vs ntp-- especially the disadvantages ( I do not know of any). Does
it go unstable under certain circumstances? I do not think so but do not know.
Why is chrony so muchmuch better than ntpd in many situations? It is just its
far more rapid response to changes caused say by thermal fluctuations? or is
there some other reason?
Ed W
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.