> Aha. This sounds like the beginning of something I just asked you to do > privately - design an actual acceptance process for a release.
I'll be glad to work on that. Where does it fit in on the priorities? I'm assuming not much will happen until after the release. There was some sort of document on the release process. Anybody remember where it lives? I think there are 3 areas. 1 is the big picture of project management 2 is getting ready for a release, freeze, testing, and such 3 is the actual release, bumping versions, tagging, tarball, etc In the short term, I think we have 2 options. One is to make a bug fix release with only a few lines of code changed. That doesn't require much testing. The other is to release the current HEAD. I think that deserves serious testing. Handwave, week. > What does a "serious testing phase" look like? When we do a documentation > pass, how do we know when we're done? My view of a testing phase is either of two options. One is to allow plenty of time and ship when the timer runs out unless the fan is covered with brown stuff. That requires good judgment on the project managers part to pick the duration of testing. The other is to ship after you have gone N days without finding anything interesting. Again, somebody has to pick N. My comment about a documentation pass was expecting at least one set of eyeballs to look at each of the documents in our collection. More than one would be better. It can be one person looking at everything or split over several people. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
