On 02/21/2018 02:44 AM, Hal Murray wrote: >> I'm a big fan of "always stable master" and time based releases. > > I'd be happy with that. What sort of interval did you have in mind for "time > based"?
I don't have one in mind. Looking at the history of releases, they tend to be 1-4 months, with an average around 2.5 months. If you're going to move to time-based, you might consider quarterly releases? > Our master is generally pretty stable, but we don't have a solid test setup. > We can tell if it builds, but that doesn't guarantee that it will actually > work correctly. I could argue this means you should release more often, so the deltas are smaller. If someone finds a problem, it'll be sooner with a fewer changes to bisect. Longer release cycles allow developers and users of git to test some changes longer, but that's only helpful if you have a freeze. If you keep making new changes right up to release, then the later changes still have very little testing. > How much testing do you do and/or are you willing to do? I make sure it compiles and runs on Debian and Ubuntu. I make sure the output of `ntpq -p` looks sane. For new upstream releases, I would want to run it on my systems for at least a few days before uploading and eyeball the ntpviz graphs. Two of my servers are in the NTP pool, so reviewing my server's statistics in the pool monitoring is another thing I do. Those are far less granular than ntpviz, though. When the package hits Debian, it goes in unstable for a while before it migrates to testing, where it sits until the next stable release. So it rolls out incrementally that way. > Does it matter if our release schedule does or doesn't mesh well with yours? Not at all. Your schedule drives mine (for new upstream versions). Packaging changes are independent, and I expect would be primarily driven by users reports or other changes in the distro ecosystem. The Debian distro (as a whole) release schedule is pretty much irrelevant, other than freezes blocking new uploads. Ubuntu does time-based releases, so there is some incentive for me to get any pending work in before an impending freeze boundary, but that's about it. -- Richard _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
