Hi all;
I have been reviewing the problematic vs less problematic releases in the
past and have noticed an interesting pattern:
Releases tend to be problematic when a) they follow a long period of no
releases or b) they require extensive testing to validate all features.
Obviously major releases are always going to fall under the extensive
testing category and may contain new bugs (hence good beta test programs and
participation in that process by a broad base of users is important).
However, one important question is how we can avoid the main traps that seem
to let bugs slip into released versions To date we have automated a lot of
the cleanup which has caused packaging errors in the past.
My proposed solution is that we begin validation of bugfix releases within 2
weeks of the previous release (I am thinking the second monday after the
last release). In urgent cases, we can move that schedule up, but we should
avoid moving it back. If the number of bugfixes are small and the software
is easily testable, validation should take no more than 48 hours.
I also think that going forward, we should probably upload all validation
tarballs to Sourceforge and use that as a distribution method for the
validation. Validation emails would be sent to this list so that more
people could weigh in on problems that they see, concerns, and whether there
is the need for more testing. If there is, then that same sourceforge
distribution can be used as a public beta.
Does this sound like a good idea? Any other feedback or ideas?
Best Wishes,
Chris Travers
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
