On Wed, Dec 06, 2017 at 12:14:18PM -0500, Eric S. Raymond wrote: > Matthew Selsky via devel <devel@ntpsec.org>: > > On Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote: > > > > > > If you want to do a quick release, then we should backport critical > > > fixes. I > > > assume that turns into a branch in git. > > > > Amen. We should release 1.0.1 that just includes the ntpq fix and the AWS > > fix (and any other critical fixes). There's been a lot of other churn > > since the release and that can all be deferred until a 1.1 release. > > I'd prefer to go to an accelerated 1.1 > > The main reason is that there isn't just one ntpq fix. There have been a > whole bunch of small but user-visible and irritating bugs in ntpq > reporting since 1.0 - we had Hans Mayer from Austria reporting one > every couple days for a while.
OK, then let's put those several fixes on a branch from the 1.0 tag and release from there (if we're looking for a quick release). There's been too much churn in non-PLL code removal, waf changes for python install paths, etc, to mix chose changes with actual user-impacting bugs (for users that were OK with the previous implementations of the python paths). If we do a slow release, then, sure, just release 1.1 with everything. If I were running 1.0 in production (I'm not), then I would want a quick release with just the exact fixes for the serious breakage. I wouldn't be comfortable deploying so many changes in a quick release, where there was one (or a few) key 1-line fixes. If we cut the release with everything, then I would roll my own packages with the specific fixes backported. What are the optics on a quick release to fix known compatibility bugs with AWS? Mark? Thanks, -Matt _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
