Hi Jesse thank you for appreciating our work. Re-releasing different code with the same version is not a common practice, nor a good one. It was just a thought to avoid the unpleasant "update from SVN" and also a release per day. Obviously it would be notified somehow in case (an additional version number could be an option).
Besides this, I understand and agree with your suggestions, feedbacks are always appreciated, we will take care of them. Thanks Alfredo On Jun 5, 2013, at 8:29 PM, Jesse Bowling <[email protected]> wrote: > > 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
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
