> > > On Wed, Jun 5, 2013 at 11:51 AM, Alfredo Cardigliano <[email protected] > > wrote: > >> Hi Doug >> we released 5.5.3 a few days ago, it is likely we refresh that tarball. >> >> Regards >> Alfredo >> >> On Jun 5, 2013, at 5:45 PM, Doug Burks <[email protected]> wrote: >> >> > Hi Alfredo, >> > >> > Thanks for the fix! I did a few quick tests and it appears to be >> > working properly. >> > >> > Will you be releasing a 5.5.4 tarball soon? >> > >> > Thanks, >> > Doug >> > >> >
Let me preface the following by saying that I very much appreciate the cost of PF_RING, the value I get from it, and the level of support that Luca, Alfredo, and the rest of the PF_RING team provide. I believe your work is enabling great things to happen in the world of security monitoring, as well as other areas, especially for verticals that typically have more bandwidth than resources dedicated to monitoring that bandwidth (EDU for instance). That being said... The release cycles and bug fixes for PF_RING are a constant headache for people such as myself trying to implement PF_RING in a production environment. For instance, re-releasing different code with the same version number doesn't let people know that there has been changes/bug fixes. This is a headache not just for people who want to create packages for PF_RING, but for anyone trying to track down a particular error with their version of code. I don't know if bug fixes are typically released in the fashion Alfredo has described, and how would I ever know? In my years of following this product the answer to problems described on the list has always been "update from SVN"...That's all well and good, but more often than not I've found that I've gotten a bug fixed but introduced a new one. Not knowing what state the SVN will be in makes every update a gamble, even if you're testing the code. Personally, I don't have the time to do extensive testing with PF_RING for every update, usually because I have to update NOW because some new bug has been uncovered by the few that DO have time to test (Thank you Doug, and others, by the way). To my naive (or selfish, or "simple user") way of thinking, your SVN needs branches for each release that bug fixes can be introduced to...keeping new features and/or untested code out of the hands of people like myself who are simple consumers of PF_RING. If that's a hassle (which it probably is), then how about publishing patch files, or at least re-releasing the same version with an additional version number (say, 5.5.3.1). While we're at it, a list of what was fixed in that version would be very helpful for deciding when to update. This issue is something that's been on my mind for a while, so I felt I had to share back to the list my thoughts. I believe that this issue is an unnecessary hindrance to wider adoption of PF_RING. If wide adoption is not the goal, or if there are existing methods for obtaining stable, bug-fixed versions of PF_RING that I'm unaware of, my apologies. In that case, maybe there should be more communication about such publication. If there are resource issues (people, time, money), let's talk about them. I'd like to see PF_RING be THE killer open-source app for all things high-speed network, but the current development and release model is a real impediment to it's adoption. Thanks for taking the time to read, Jesse -- Jesse Bowling
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
