This bug is apparently not getting fixed, since it's been open for a long time now with no action. I'm going to argue why it instead should be tagged "wontfix" (and possibly closed), to atleast dignify the bug reporter with an answer to his request. (But as I'm not the maintainer, I won't add the tag myself.)
- The esqf is described as a verbatime copy of sqf which some hardcoded values exposed as configurable and some other modifications. The reason I've read was to not jeopardise the stability of the original sfq with changes. I'd say that if these changes now has been proven reliable the proper way of dealing with this would be to merge them into sfq, instead of merging the "development version" - esfq. Someone else seems to agree and there's recently been an effort to port some of esfq features (the useful ones which isn't supposed to be covered by a planned rewrite). See http://www.spinics.net/lists/netdev/msg37041.html (Posts to the netdev list on 29 Juli 2007 titled "SFQ: backport some features from ESFQ (try 2)") - As far as I know there has been no effort to merge esfq in the upstream kernel and I'm guessing there will be no future attempts eigther. This will likely make the upstream iproute2 maintainer to refuse to merge the userspace part and the debian maintainers would have to manage the maintainance burden. I would say that the time spent on carrying and maintaining a patch in debian would be better spent on getting the features merged upstream into SFQ. -- Regards, Andreas Henriksson
signature.asc
Description: This is a digitally signed message part
