PROPOSED, change of stance, release metronome
Hal Murray
hmurray at megapathdsl.net
Tue Mar 15 08:46:17 UTC 2016
verm at darkbeer.org said:
> This can get complicated real fast. I would encourage distros to do rolling
> testing but we cannot pin our releases to their schedule in any way.
> As long as we have our test results online and they can pinpoint the 'best'
> version to run they can go back a release or two in order to find one they
> are comfortable with.
I'm not sure what you have in mind for "test results". How is a non-wizard
going to be able to evaluate anything other than a yes/no, and we will
already have filtered out the no-s.
> This also encourages us to release more frequently. I don't believe we have
> any reason to have 10 releases in a month but we should always have at
> least 2 and no fewer than that. This is to avoid stacking changes and lets
> things get tested in the test system.
What is the purpose of a release?
I'm assuming it's a tag on a pile of bits so we have a way to talk about them
and a way to focus testing and usage on a smaller number of things to keep
track of and support.
> We could also solve this by having a 'recommended' version on our website
> and point to test results. It would be good to keep distros at least 30
> days behind our development cycle. I expect the full run of run-time
> testing to take at least one week per built release. I have a bunch of
> RPIs here that I will run ntpd on to make sure it keeps time properly one
> that test passes then we can say that is a 'stable' version of a release
> and recommend it as the next version to try.
The idea of "recommended" sounds good. It looks like you are automating the
2 week-ish release cycle. We still have to work out which releases to
support long term and how long.
In terms of testing...
I look at a lot of graphs by hand. I think I could automate some of that,
but that would still leave a lot of work.
It may not be possible (or worth the effort) to totally automate the testing.
This will probably change when Eric's TESTFRAME starts working. (I'm
assuming we can run some real servers setup to collect data so we can gather
a bunch of test cases when "interesting" things happen.)
We also have to test refclocks.
We can get real traffic by putting up pool servers.
--
These are my opinions. I hate spam.
More information about the devel
mailing list