tim.mcmanus,
thanks for proposal, will try it.
cmb
I am agree with you that "The fact that X doesn't work for someone doesn't mean X doesn't work" but i see that you agree I could be faced with a real bug at my setup..
1. So need the process of identification what is the real bug and what is not at forum/other sources. We are free testers for PFsense :) Need to utilize us.
2. Also some formal process of product readiness to sign off, for example by number of reported bugs in a period and no major bugs at stable release. Pfsense is not a commercial product, so no pressure from high-value, top customers to release product to a specific, predefined date. The main goal is stable and perfect product.
3. Major bugs discovered at stable release during production use should be an exceptional case. Need process for rapid patches…See current situation - we have stable 2.0.2 and fix at 2.0.3 which is still not released..Pfsense already have functionality for checking updates, so that could be easy to implement. See the debian process - major releases with new features and a lot of patches between them. Users should not wait for the next stable release to apply critical patches for existed packages/functionality.
I understand that I could missed some opensource development nuances. That is Just my thoughts in an air.. :)
I understand that you, pfsense guys, already have stable development process and great coordination - > currently you at top of free routers solutions.
With respect,
one of pfsense users.