Re: Policy for removing working code
Hi Doug Barton! On Fri, 17 Sep 2010 13:27:02 -0700; Doug Barton wrote about 'Re: Policy for removing working code': You either not understanding that this situation is about entire project (not ISDN, but policy) I think at this point that you've made your concerns clear. What you don't seem to be understanding is: 1) The policy is, and always has been, those who are interested in keeping code alive work on it. 2) No one was interested (by the definition above) in keeping the ISDN code alive. Not quite. There are those who are interested in keeping code alive but can't work on it, i.e., users, not programmers. But they, if notified, could convince another people, programmers, to do the work (such events of volunteer calls are not often), e.g., hire someone. But announcements, may be, should be more clear about this, for the case such people wouldn't _guess_ such possibility exists. BSD tries to be more business-freindly, ain't it? :) Now you have raised a valid point on how we can do the volunteers needed notifications better in the future, and I think that those will be taken to heart, and acted on the next time we face this situation. Indeed. Thanks for understanding. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi Andriy Gapon! On Fri, 17 Sep 2010 15:09:54 +0300; Andriy Gapon wrote about 'Re: Policy for removing working code': You either not understanding that this situation is about entire project (not ISDN, but policy) or assert that users just running FreeBSD should not care about the way things happen, which is wrong. And thus your stop provoking sounds like ostrich policy, which is even worse. You either don't understand the situation or are a troll. People who actively participate(d) in the project/community were very well aware of the issue. Following the generalized principle of locality it was not expected that much help would come from people who didn't already sufficiently participate. This much belated and non-productive thread is a perfect demonstration. No, that is you who actively refuse to understand the main point, while several other people on this list already agreed with me. I've given arguments, valid arguments, but you din't answer them, repeating the same statement reworded. Moreover, you were wrong several times, e.g. at requirement for all users to read stable, while I've found that handbook/eresources.html agrees with me: === freebsd-announce Important events / milestones This is the mailing list for people interested only in occasional announcements of significant FreeBSD events. This includes announcements about snapshots and other releases. It contains announcements of new FreeBSD capabilities. It may contain calls for volunteers etc. This is a low volume, strictly moderated mailing list. === And Project actually did the things as documented, I've counted and wrote in another message 12 such letters in announce@ from 2002, then things stopped to go this way. Why you ignored this argument just as I didn't say anything? After all, your impolite accusements of non-productiveness and trolling. Should I answer the same way and say something about your self-conceit? I'll not come down to this but rather quote committers-guide: === Do not impugn the intentions of someone you disagree with. If they see a different solution to a problem than you, or even a different problem, it is not because they are stupid, because they have questionable parentage, or because they are trying to destroy your hard work, personal image, or FreeBSD, but simply because they have a different outlook on the world. Different is good. Disagree honestly. Argue your position from its merits, be honest about any shortcomings it may have, and be open to seeing their solution, or even their vision of the problem, with an open mind. Accept correction. We are all fallible. When you have made a mistake, apologize and get on with life. Do not beat up yourself, and certainly do not beat up others for your mistake. Do not waste time on embarrassment or recrimination, just fix the problem and move on. Ask for help. Seek out (and give) peer reviews. One of the ways open source software is supposed to excel is in the number of eyeballs applied to it; this does not apply if nobody will review code. === -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi jhell! On Thu, 09 Sep 2010 12:51:06 -0400; jhell wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': The situation was: an announcement was made that in X months, all network drivers need to be made to run Giant-free so that FreeBSD can drop Giant from the neworking stack to move forward. Within that period, most of the drivers were updated. Repeated postings were made to the mailing list that the following drivers still have not been converted, and need to be updated or they will be dropped. They weren't; they were droppped. No. See my answer to vwe@ that there were no proper announcements. With them, for example, someone could get sponsored to update these drivers which were needed by those FreeBSD users who can't maintain code themselves. That's a last resort, more likely volunteers will come, but you get the idea. So while it could still work, it was slowing down progress. If it is not ideology, then what is it?.. The fact of the matter is, FreeBSD is a big project with a finite number of developers. We try to keep as much coverage of systems as we can, but a reality of any large software engineering project is that older features sometimes have to be dropped to make progress. From time to time such critical cases could possibly be handled by another ways, I've mentioned one possible above. The code still exists in the repository for any interested party to pick up and modernize. I hope that for this particular case alternative from ports will be enough. But policy is not tied to one particular case, alas. Would you please stop provoking a situation for which you are no more involved in other than running FreeBSD. You either not understanding that this situation is about entire project (not ISDN, but policy) or assert that users just running FreeBSD should not care about the way things happen, which is wrong. And thus your stop provoking sounds like ostrich policy, which is even worse. PS: The website in your signature is broke. This should give you enough to do for a while. You may have noted in whois that I am not that site admin. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi Julian H. Stacey! On Fri, 10 Sep 2010 11:20:10 +0200; Julian H. Stacey wrote about 'Re: Policy for removing working code': If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a errata fix branch), then they should be reading the stable@ list. True for RELENG_X, but not for RELENG_X_Y. They shouldn't, because all information for security/errata fix branch go to announce@, they don't need to read all noise in stable@ just for this. And, what is more important, they in fact don't do. So announce@ is the only choice from purely practical means. One option could be a new list perhaps called eg one of features@ advisories@ notifications@ feature-notifications@ to carry heads up notification of future feature changes / removals. Its would be more traffic than announce@ but much lower traffic than stable@ FreeBSD already has the precedent of security-notifications@ Umm, no: security-notifications@ is not an addon to, but rather a subset of announce@ for those who don't care about anything except the most important events - security. So announce@ would be sufficient - and Handbook already states that things like call for volunteers go to announce@ (and many feature removal notifications may be not certain if there will be volunteers then). But perhaps your idea is applicable to www.freebsd.org, though. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi jhell! On Sat, 11 Sep 2010 23:26:04 -0400; jhell wrote about 'Re: Policy for removing working code': Just send these notices to -announce. The removal of stuff like this doesn't happen often, and as long as we're careful with the frequency and content of the messages I can't imagine people would complain too much. I agree with Doug on this. No need to add another layer of complexity to the already existing lists. Just use them properly. Besides wouldn't it make sense to publish the top three or five recent posts to announce@ to a reserved space on the CMS rather than relying on consumers to subscribe to the list at all. I know errata notices get announced I would think a heads up around the board about big changes like removing portions of code completely should be announced as well. Good idea. I think the web site is viewed by more people than read annou...@. FreeBSD-CA-??? Change Announcement? for that are constructed much of the same way the SA EN are ?. No, as this is not certain - if volunteers will answer the call, feature may survive instead of removal. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
on 17/09/2010 12:14 Vadim Goncharov said the following: You either not understanding that this situation is about entire project (not ISDN, but policy) or assert that users just running FreeBSD should not care about the way things happen, which is wrong. And thus your stop provoking sounds like ostrich policy, which is even worse. You either don't understand the situation or are a troll. People who actively participate(d) in the project/community were very well aware of the issue. Following the generalized principle of locality it was not expected that much help would come from people who didn't already sufficiently participate. This much belated and non-productive thread is a perfect demonstration. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
On 9/17/2010 2:14 AM, Vadim Goncharov wrote: You either not understanding that this situation is about entire project (not ISDN, but policy) I think at this point that you've made your concerns clear. What you don't seem to be understanding is: 1) The policy is, and always has been, those who are interested in keeping code alive work on it. 2) No one was interested (by the definition above) in keeping the ISDN code alive. Now you have raised a valid point on how we can do the volunteers needed notifications better in the future, and I think that those will be taken to heart, and acted on the next time we face this situation. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
per...@pluto.rain.com wrote: [...] Beyond that, I suspect that dropping an HBA or three would have been far less burdensome on users of the hardware in question than dropping ISDN is on its users. One can always replace a no-longer-supported HBA with a supported one, or (worst case) replace the whole box. In contrast, someone located beyond DSL range may have no other viable option than ISDN. It is a common misconception that ISDN is only used by people who can't get DSL or other connectivity. I can only guess that ISDN is very uncommon in the USA, but it isn't in other parts of the world. In Germany (and possible other countries), ISDN is still very popular. I have ISDN at home (in addition to DSL at 18 Mbps); it costs almost the same as a normal telephone line while providing many useful features. Many (most?) companies here do have ISDN, including the one I work for. We use FreeBSD's I4B stack to implement an answering machine and fax services. This is the reason why we still have to run FreeBSD 6.x on one machine, but when 6.x runs EOL we will have to make a decision (which might end up putting a different OS on that machine, depending on the choices at that time). At home I used ISDN as a fall-back when the DSL line didn't work for some reason. I lost that feature about two years ago when I updated beyond 6.x. Fortunately DSL outages are very rare at my provider, so the decision wasn't difficult in this particular case. Don't get me wrong -- I understand very well why the I4B code had to be removed from FreeBSD. It was an unfortunate, but necessary decision. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2010 14:24, Doug Barton wrote: On 9/10/2010 2:20 AM, Julian H. Stacey wrote: One option could be a new list Just send these notices to -announce. The removal of stuff like this doesn't happen often, and as long as we're careful with the frequency and content of the messages I can't imagine people would complain too much. I agree with Doug on this. No need to add another layer of complexity to the already existing lists. Just use them properly. Besides wouldn't it make sense to publish the top three or five recent posts to announce@ to a reserved space on the CMS rather than relying on consumers to subscribe to the list at all. I know errata notices get announced I would think a heads up around the board about big changes like removing portions of code completely should be announced as well. FreeBSD-CA-??? Change Announcement? for that are constructed much of the same way the SA EN are ?. Just some thoughts, Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMjEhMAAoJEJBXh4mJ2FR+7tEH/3IazQgUv/JubsuzKLVnCLER oYg1Ws/dvWPC0Tdizm7QIqp+WvFYGz/c9Udihl8jAMW5CVLkNSba/THcpcVbp4hY utHhC88EsPZjgKjGnCpbfOar2cZoBL1nPv16+pL2Ur+NjU9s+PAY31SmFJ6I3fq4 yTMjU+/fsjalBClZYzy90/f0E8jj45la66VrZhEAgMPEWYdIRY1akAOAiZxx9vhM 1M/l9uLuanGhS+4rkM9Tz7ZrCmfLmzV6K3OhEWagTJPbK8DH1WPKk41HhHiW+ef1 p7YDuQYi+CCFg9QB/erhXDXJT5BBOctXOTN4UdNkfC78g5vV+7FZa3CWsSzstss= =L7sZ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Vadim Goncharov wrote: Hi Scot Hetzel! On Thu, 9 Sep 2010 04:18:52 -0500; Scot Hetzel wrote about 'Re: Policy for removing working code': We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. That may depend on how often something substantial is removed :) I do think stable@ is a good place to e-mail ... Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a errata fix branch), then they should be reading the stable@ list. True for RELENG_X, but not for RELENG_X_Y. They shouldn't, because all information for security/errata fix branch go to announce@, they don't need to read all noise in stable@ just for this. And, what is more important, they in fact don't do. So announce@ is the only choice from purely practical means. One option could be a new list perhaps called eg one of features@ advisories@ notifications@ feature-notifications@ to carry heads up notification of future feature changes / removals. Its would be more traffic than announce@ but much lower traffic than stable@ FreeBSD already has the precedent of security-notifications@ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
On 9/10/2010 2:20 AM, Julian H. Stacey wrote: One option could be a new list Just send these notices to -announce. The removal of stuff like this doesn't happen often, and as long as we're careful with the frequency and content of the messages I can't imagine people would complain too much. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
John Baldwin j...@freebsd.org wrote: We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. That may depend on how often something substantial is removed :) I do think stable@ is a good place to e-mail ... Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? I do think that the general rule is that stable@ should be on the list. It is true that that did not happen in this case (and probably should have), but it does happen in the typical case. I would chalk this up to a one-time slip-up, not a systemic problem. In light of this slip-up having now resulted in at least one user having the rug yanked out from under him, perhaps the security officer should be approached WRT continuing support for 6.4 until ISDN is resurrected (which, to judge from other postings in this thread, seems unlikely to amount to indefinitely). ... we lost a few SCSI HBA drivers during the transition to CAM (e.g. wds(4) was not present in 4.x but was eventually CAM-ified and reappeared in 5.0). I suspect there was far less notice given for those drivers than for ISDN (multiple notices to arch@ and current@ spread out across many months). But, as noted previously, not to any list that someone following a security branch would be expected to read. Beyond that, I suspect that dropping an HBA or three would have been far less burdensome on users of the hardware in question than dropping ISDN is on its users. One can always replace a no-longer-supported HBA with a supported one, or (worst case) replace the whole box. In contrast, someone located beyond DSL range may have no other viable option than ISDN. Perhaps it would be advisable to e-mail announce@ when something is to be removed _and_ there is no recommended migration path. That should reduce the frequency of such postings considerably compared with the strawman suggestion that ... every time something is going to be removed would overload the list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
On Thu, Sep 09, 2010 at 01:22:22AM -0700, per...@pluto.rain.com wrote: John Baldwin j...@freebsd.org wrote: We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. That may depend on how often something substantial is removed :) If mails to announce@ were only sent at the point significant stuff actually is removed it might not be all that much traffic, but at that point it seems a bit late for people to protest against the removal since it has already happened. OTOH, if mails were sent to announce@ everytime something was proposed to be removed then there would probably be far too much traffic for that list. (Most discussions regarding removing stuff tend to end up with status quo being maintained.) I do think stable@ is a good place to e-mail ... Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? That depends on what they want to know. If they are concerned about things affecting the branch they are following, then announce@ is probably sufficient since all security advisories are sent there and there are essentially no other changes made to a security branch. If, on the other hand, they are interested in what will be included/not included in future major releases, then current@ is pretty much a must-read. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
On Thu, Sep 9, 2010 at 3:22 AM, per...@pluto.rain.com wrote: John Baldwin j...@freebsd.org wrote: We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. That may depend on how often something substantial is removed :) I do think stable@ is a good place to e-mail ... Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a errata fix branch), then they should be reading the stable@ list. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
on 09/09/2010 11:22 per...@pluto.rain.com said the following: Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? People, who care, are expected to read current@ and stable@ even if they use only releases and security branches. At the very least, to see what's cooking up for them and what to expect. P.S. I am surprised that this thread isn't over yet and is being kept alive by people who do not seem to use the feature in question or offer any work on it. While people, who really need it, have already found a way forward for themselves. P.P.S. Please, please, let it go now. Watch current@, watch stable@ and speak up next time such an announcement is made. Do it on time, don't wait until a few years later :-) -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi Andriy Gapon! On Wed, 08 Sep 2010 17:13:29 +0300; Andriy Gapon wrote about 'Re: Policy for removing working code': network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X we have no resources to maintain feature X - we announce theis need, but only to _limited_ audience, not wide circles - nobody responds - the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. So, get to work, become a committer, get elected to core and have a control over these procedures. [And maybe your perspectives will change along the way] Until then, please, let's stop wasting time on this issue. And, after several years for all of this, to see that FreeBSD have lost many old users? That's will be too late. You retort here ad hominem, while the policy quoted above is true. Nobody has to be core@ member to predict this policy will eventually harm FreeBSD userbase. Anybody could say that meal is bad, he don't need to be head-cook for this to taste and say. P.S. If I couldn't explain why you were wrong here, there is an article in another language that does this much better: http://lurkmore.ru//%D0%A1%D0%BF%D0%B5%D1%80%D0%B2%D0%B0_%D0%B4%D0%BE%D0%B1%D0%B5%D0%B9%D1%81%D1%8F -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi John Baldwin! On Wed, 8 Sep 2010 10:21:47 -0400; John Baldwin wrote about 'Re: Policy for removing working code': No, that would require maintaining two network stacks, not just one. The shims to allow unlocked code to run were not trivial. The choices were this: 1) Moving forward on work to allow the network stack to scale on SMP systems (e.g. modern x86 multi-core servers) and support higher rate protocols such as 10GB, 40GB, and 100GB. 2) Stop all progress on making the network stack scale on SMP. I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a modern, relevant system. If it is the only variants, then I'll agree (but only on this part). Are there really no other variants? What do other OSes to which, as was said, we have to compete? E.g. Linux? Yes, other OS's (Windows, Linux, Solaris) all are working on the multi-core problem. OS's that aren't working on this will soon be obsolete. Even modern embedded systems are multi-core (e.g. many MIPs chips now include multiple cores on a chip, even SMT similar to Intel's HyperThreading on RMI's MIPs SOCs). My question is not quite the same as that to which you've answered. I agree that non-SMP OS's will be obsolete, but what that OSes do in such particular cases? Also, despite your claims to the contrary, there _was_ adequate notice: http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html This was also documented in the release notes for 7.0: http://www.freebsd.org/releases/7.0R/relnotes.html No, my claims were that there was no _adequate_ notice, and this links acknowledge this. 7.0 Release notes state about broken ISDN as an already happened fact, user can't do anything about it already. As I've shown in message to vwe@, it wasn't in announce@ and even in sta...@. Number of users/subscribers of lists can be expressed as: # devel lists # current@ # stable@ # announce@ # of total FreeBSD users While we can't do anything with those who not subscribed even to announce@ (though should it be duplicated on www may be?), number of announce@ readers is still MUCH more than that of current@, not even mention devel lists. We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. No, not everytime and everything, of course. That will go to far to other end. I mean every major event, e.g. each ordinary driver is not worth noting (too much spam), but in this case there were TWO not drivers, but subsystems (ISDN and netatm). One symptom that could indicate this is major event, not minor, is call for volunteers. This is definitely happens not too often. I do think stable@ is a good place to e-mail, and I did in fact mail my locking patches for the various NIC drivers to sta...@. In some cases I did only find testers via stable@ and not via curr...@. I do think that the general rule is that stable@ should be on the list. It is true that that did not happen in this case (and probably should have), but it does happen in the typical case. I would chalk this up to a one-time slip-up, not a systemic problem. You said about testers, and testers are already involved somehow to the project, at least are subscribed to lists. But testers are in general for testing new features (positive), but not all FreeBSD users need new fetures that fast. They are more concerned about feature removal (negative). Such announcements need to be made at least for them to have migration plan - just like Security Officer informs about EoL before that happens, for people have time to plan maintenance and upgrade. If you wish to help work on ISDN support, I suggest you offer to test hps@' ISDN stack. hps@ recently became a committer so I think there is a very good chance his code will be brought into the tree. We do have a policy for removing code in that it only gets removed if no one is able to maintain it and/or test patches for it. I locked several of the remaining NIC drivers during the push to remove Giant and a few of them were removed from the system because no one had the hardware around to test the patches to add locking (think of really old ISA NICs that only do 10Mbps). Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X we have no resources to maintain feature X - we announce theis need, but only to _limited_ audience, not wide circles - nobody responds - the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. Actually, things have worked this way far longer than 5 years ago. For example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. wds(4) was not present in 4.x but was eventually CAM
Re: Policy for removing working code
Hi Scot Hetzel! On Thu, 9 Sep 2010 04:18:52 -0500; Scot Hetzel wrote about 'Re: Policy for removing working code': We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. That may depend on how often something substantial is removed :) I do think stable@ is a good place to e-mail ... Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a errata fix branch), then they should be reading the stable@ list. True for RELENG_X, but not for RELENG_X_Y. They shouldn't, because all information for security/errata fix branch go to announce@, they don't need to read all noise in stable@ just for this. And, what is more important, they in fact don't do. So announce@ is the only choice from purely practical means. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi Andriy Gapon! On Thu, 09 Sep 2010 12:33:57 +0300; Andriy Gapon wrote about 'Re: Policy for removing working code': Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? People, who care, are expected to read current@ and stable@ even if they use only releases and security branches. At the very least, to see what's cooking up for them and what to expect. Hey, by whom expected? They are NOT expected to do this! Can you quote some official docs or statements for this? P.S. I am surprised that this thread isn't over yet and is being kept alive by people who do not seem to use the feature in question or offer any work on it. While people, who really need it, have already found a way forward for themselves. Because this thread is not about this feature but about policy which will slowly bring FreeBSD project to troubles if nothing will be changed. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
on 09/09/2010 17:07 Vadim Goncharov said the following: Because this thread is not about this feature but about policy which will slowly bring FreeBSD project to troubles if nothing will be changed. Your opinion is noted. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)
On 09/08/2010 06:44, Vadim Goncharov wrote: Hi Mark Linimon! On Wed, 8 Sep 2010 07:30:19 +; Mark Linimon wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': The reason is performance for overall network stack, not ideology. For a practical reasons, it works but slow is better than doesn't work at all (due to absence of code in the src tree). Make it work. Make it right. Make it fast. In that order, know this? Sacrificing work for fast?.. Hmm, if it is not ideology, then what is it?.. It wasn't it works but slow. It was it works, but networking throughput is limited on the modern hardware that the majority of our users employ. In particular, IIUC, 10GB network drivers were suffering under the old strategy. We simply were not competitive with other OSes, and we have many multiples more users interested in 10GBE than in ISDN. I understand that we need to support modern fast hardware but that doesn't mean we should drop working features for that. And... You do not understand the problem. It is not in notices volunteers, but rather in the Project's policy - delete something which could still work. You do not understand how this was handled. ...and how this is handled in other OSes to which we have compete, er? They all also do dropping features to frighten away old users? Are there no alternative ways to handle? Put network Giant code into bunch of #ifdef's, after all. The situation was: an announcement was made that in X months, all network drivers need to be made to run Giant-free so that FreeBSD can drop Giant from the neworking stack to move forward. Within that period, most of the drivers were updated. Repeated postings were made to the mailing list that the following drivers still have not been converted, and need to be updated or they will be dropped. They weren't; they were droppped. No. See my answer to vwe@ that there were no proper announcements. With them, for example, someone could get sponsored to update these drivers which were needed by those FreeBSD users who can't maintain code themselves. That's a last resort, more likely volunteers will come, but you get the idea. So while it could still work, it was slowing down progress. If it is not ideology, then what is it?.. The fact of the matter is, FreeBSD is a big project with a finite number of developers. We try to keep as much coverage of systems as we can, but a reality of any large software engineering project is that older features sometimes have to be dropped to make progress. From time to time such critical cases could possibly be handled by another ways, I've mentioned one possible above. The code still exists in the repository for any interested party to pick up and modernize. I hope that for this particular case alternative from ports will be enough. But policy is not tied to one particular case, alas. Would you please stop provoking a situation for which you are no more involved in other than running FreeBSD. Thank you. PS: The website in your signature is broke. This should give you enough to do for a while. -- jhell,v ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Date: Thu, 09 Sep 2010 12:33:57 +0300 From: Andriy Gapon a...@icyb.net.ua Sender: owner-freebsd-sta...@freebsd.org on 09/09/2010 11:22 per...@pluto.rain.com said the following: Good, perhaps even necessary, but is it sufficient? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? People, who care, are expected to read current@ and stable@ even if they use only releases and security branches. At the very least, to see what's cooking up for them and what to expect. P.S. I am surprised that this thread isn't over yet and is being kept alive by people who do not seem to use the feature in question or offer any work on it. While people, who really need it, have already found a way forward for themselves. P.P.S. Please, please, let it go now. Watch current@, watch stable@ and speak up next time such an announcement is made. Do it on time, don't wait until a few years later :-) The point is that people running release code and release+security are NOT expected to be reading either stable or current. They should be reading the release notes, but the dropping of ISDN support was only mentioned in the 7.0 release notes and it stated: ISDN4BSD and netatm have been temporarily disconnected from the build. These modules all require the Giant kernel lock for their operation; disconnecting them allows the removal of the NET_NEEDS_GIANT compatability (sic) shim. It is planned to convert these modules to fine-grained kernel locking and re-connect them for FreeBSD 7.1-RELEASE. Even if you read this, (ignoring the spelling error) you would not expect them to be gone in 7.3 or 8.1. soapbox I must say that this was very poorly documented for the typical user who happens to need ISDN. Yes, the code needed removal, but when a major capability is removed, it really needs to be better noted. Since the 7.0 release notes said that ISDN4BSD would be back in 7.1, the 7.1 notes should have mentioned that it was not and might not be back. I also think that, once the decision to remove all devices that required GIANT and most of the dust had settled (i.e. jhb and others had converted most of the drivers to not use GIANT) and the plea went out for people to test/patch the remaining devices, it would have been appropriate to send a message to that effect to announce. Let's face it, the removal of GIANT from the network stack was a major change and it was likely to impact users of the sub-systems removed. If they did the usual and skipped the .0 release, they never installed 7.0 and probably did not read the release notes. It was never mentioned in the announcements, either. While the removal was needed, it really needed to be better publicized. ISDN is still in use. We support it (not with FreeBSD) and, if it fails, the mail comes pouring in, usually from outside of the US and the often from places where other forms of broadband Internet are not readily available or from those using appliances that use ISDN for network connectivity. This is a volunteer effort. When we screw up, and we do, we should say sorry and try not to do it again, not spend time sending responses that the users are at fault. Leave that to the commercial operations who do it regularly. Personally, I think we screwed up. /soapbox -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)
On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: Because the original I4B code didn't work without the Giant lock, and because no one stepped forward to fix that, the code had to be removed. No. The code needn't removal, the stack should be modified to be fast without I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness is their problem, not of the Project. No, that would require maintaining two network stacks, not just one. The shims to allow unlocked code to run were not trivial. The choices were this: 1) Moving forward on work to allow the network stack to scale on SMP systems (e.g. modern x86 multi-core servers) and support higher rate protocols such as 10GB, 40GB, and 100GB. 2) Stop all progress on making the network stack scale on SMP. I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a modern, relevant system. Also, despite your claims to the contrary, there _was_ adequate notice: http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html This was also documented in the release notes for 7.0: http://www.freebsd.org/releases/7.0R/relnotes.html If you wish to help work on ISDN support, I suggest you offer to test hps@' ISDN stack. hps@ recently became a committer so I think there is a very good chance his code will be brought into the tree. We do have a policy for removing code in that it only gets removed if no one is able to maintain it and/or test patches for it. I locked several of the remaining NIC drivers during the push to remove Giant and a few of them were removed from the system because no one had the hardware around to test the patches to add locking (think of really old ISA NICs that only do 10Mbps). Even in that case, the code will always live on in the source code control repository's history. That means it can always be resurrected if someone shows up who will maintain it and keep it up to date. At this point I think this thread has reached the end of its usefulness. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Hi John Baldwin! On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: Because the original I4B code didn't work without the Giant lock, and because no one stepped forward to fix that, the code had to be removed. No. The code needn't removal, the stack should be modified to be fast without I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness is their problem, not of the Project. No, that would require maintaining two network stacks, not just one. The shims to allow unlocked code to run were not trivial. The choices were this: 1) Moving forward on work to allow the network stack to scale on SMP systems (e.g. modern x86 multi-core servers) and support higher rate protocols such as 10GB, 40GB, and 100GB. 2) Stop all progress on making the network stack scale on SMP. I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a modern, relevant system. If it is the only variants, then I'll agree (but only on this part). Are there really no other variants? What do other OSes to which, as was said, we have to compete? E.g. Linux? Also, despite your claims to the contrary, there _was_ adequate notice: http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html This was also documented in the release notes for 7.0: http://www.freebsd.org/releases/7.0R/relnotes.html No, my claims were that there was no _adequate_ notice, and this links acknowledge this. 7.0 Release notes state about broken ISDN as an already happened fact, user can't do anything about it already. As I've shown in message to vwe@, it wasn't in announce@ and even in sta...@. Number of users/subscribers of lists can be expressed as: # devel lists # current@ # stable@ # announce@ # of total FreeBSD users While we can't do anything with those who not subscribed even to announce@ (though should it be duplicated on www may be?), number of announce@ readers is still MUCH more than that of current@, not even mention devel lists. If you wish to help work on ISDN support, I suggest you offer to test hps@' ISDN stack. hps@ recently became a committer so I think there is a very good chance his code will be brought into the tree. We do have a policy for removing code in that it only gets removed if no one is able to maintain it and/or test patches for it. I locked several of the remaining NIC drivers during the push to remove Giant and a few of them were removed from the system because no one had the hardware around to test the patches to add locking (think of really old ISA NICs that only do 10Mbps). Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X we have no resources to maintain feature X - we announce theis need, but only to _limited_ audience, not wide circles - nobody responds - the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
on 08/09/2010 17:01 Vadim Goncharov said the following: Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X we have no resources to maintain feature X - we announce theis need, but only to _limited_ audience, not wide circles - nobody responds - the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. So, get to work, become a committer, get elected to core and have a control over these procedures. [And maybe your perspectives will change along the way] Until then, please, let's stop wasting time on this issue. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
[ Trimming cc's a bit ] On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: Hi John Baldwin! On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: Because the original I4B code didn't work without the Giant lock, and because no one stepped forward to fix that, the code had to be removed. No. The code needn't removal, the stack should be modified to be fast without I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness is their problem, not of the Project. No, that would require maintaining two network stacks, not just one. The shims to allow unlocked code to run were not trivial. The choices were this: 1) Moving forward on work to allow the network stack to scale on SMP systems (e.g. modern x86 multi-core servers) and support higher rate protocols such as 10GB, 40GB, and 100GB. 2) Stop all progress on making the network stack scale on SMP. I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a modern, relevant system. If it is the only variants, then I'll agree (but only on this part). Are there really no other variants? What do other OSes to which, as was said, we have to compete? E.g. Linux? Yes, other OS's (Windows, Linux, Solaris) all are working on the multi-core problem. OS's that aren't working on this will soon be obsolete. Even modern embedded systems are multi-core (e.g. many MIPs chips now include multiple cores on a chip, even SMT similar to Intel's HyperThreading on RMI's MIPs SOCs). Also, despite your claims to the contrary, there _was_ adequate notice: http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html This was also documented in the release notes for 7.0: http://www.freebsd.org/releases/7.0R/relnotes.html No, my claims were that there was no _adequate_ notice, and this links acknowledge this. 7.0 Release notes state about broken ISDN as an already happened fact, user can't do anything about it already. As I've shown in message to vwe@, it wasn't in announce@ and even in sta...@. Number of users/subscribers of lists can be expressed as: # devel lists # current@ # stable@ # announce@ # of total FreeBSD users While we can't do anything with those who not subscribed even to announce@ (though should it be duplicated on www may be?), number of announce@ readers is still MUCH more than that of current@, not even mention devel lists. We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. I do think stable@ is a good place to e-mail, and I did in fact mail my locking patches for the various NIC drivers to sta...@. In some cases I did only find testers via stable@ and not via curr...@. I do think that the general rule is that stable@ should be on the list. It is true that that did not happen in this case (and probably should have), but it does happen in the typical case. I would chalk this up to a one-time slip-up, not a systemic problem. If you wish to help work on ISDN support, I suggest you offer to test hps@' ISDN stack. hps@ recently became a committer so I think there is a very good chance his code will be brought into the tree. We do have a policy for removing code in that it only gets removed if no one is able to maintain it and/or test patches for it. I locked several of the remaining NIC drivers during the push to remove Giant and a few of them were removed from the system because no one had the hardware around to test the patches to add locking (think of really old ISA NICs that only do 10Mbps). Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X we have no resources to maintain feature X - we announce theis need, but only to _limited_ audience, not wide circles - nobody responds - the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. Actually, things have worked this way far longer than 5 years ago. For example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. wds(4) was not present in 4.x but was eventually CAM-ified and reappeared in 5.0). I suspect there was far less notice given for those drivers than for ISDN (multiple notices to arch@ and current@ spread out across many months). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
John Baldwin wrote: [ Trimming cc's a bit ] On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X we have no resources to maintain feature X - we announce theis need, but only to _limited_ audience, not wide circles - nobody responds - the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. Actually, things have worked this way far longer than 5 years ago. For example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. wds(4) was not present in 4.x but was eventually CAM-ified and reappeared in 5.0). I suspect there was far less notice given for those drivers than for ISDN (multiple notices to arch@ and current@ spread out across many months). On top of which, I'd say that the general philosopy is always that you stick with the release that works for you. Surely the people who need those ISDN drivers, simply stay with the release that works for them. If they need new features as well as ISDN, they do a cost-benefit analysis on writing drivers to fit the new framework. - Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
On Wed, Sep 08, 2010 at 03:31:11PM +0100, Mark Blackman wrote: John Baldwin wrote: [ Trimming cc's a bit ] On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X we have no resources to maintain feature X - we announce theis need, but only to _limited_ audience, not wide circles - nobody responds - the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. Actually, things have worked this way far longer than 5 years ago. For example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. wds(4) was not present in 4.x but was eventually CAM-ified and reappeared in 5.0). I suspect there was far less notice given for those drivers than for ISDN (multiple notices to arch@ and current@ spread out across many months). On top of which, I'd say that the general philosopy is always that you stick with the release that works for you. Surely the people who need those ISDN drivers, simply stay with the release that works for them. If they need new features as well as ISDN, they do a cost-benefit analysis on writing drivers to fit the new framework. Only problem with that is that eventually those old releases stop receiving security fixes at which point it might become downright dangerous to continue using the old release. I think that is exactly the situation now which started this discussion - the last release supporting ISDN was 6.4, which is to be EOL soon. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Policy for removing working code
Erik Trulsson wrote: On Wed, Sep 08, 2010 at 03:31:11PM +0100, Mark Blackman wrote: On top of which, I'd say that the general philosopy is always that you stick with the release that works for you. Surely the people who need those ISDN drivers, simply stay with the release that works for them. If they need new features as well as ISDN, they do a cost-benefit analysis on writing drivers to fit the new framework. Only problem with that is that eventually those old releases stop receiving security fixes at which point it might become downright dangerous to continue using the old release. I think that is exactly the situation now which started this discussion - the last release supporting ISDN was 6.4, which is to be EOL soon. Fair point, although I'd say that's part of the cost-benefit analysis too, where features includes up-to-date security fixes. Anyway, I finally reviewed the thread and an actual I4B user, Julian, seems to have concluded that investing a bit of time in the hps code is a net benefit, so all's well. :) - Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
