Gentlemen, as I had remarked in another thread, about the viability of depending on FreeBSD for device drivers, this reversal of commit is indicative of the fact that whatever might have worked on FreeBSD need not necessarily work on Haiku. Am I correct?
FreeBSD will not keep Haiku in mind when they write their drivers…
Will the core team re-think about this point…or just go ahead with FreeBSD, living with these small issues?
I think you should understand that writing drivers from scratch is quite hard. Trying to port drivers from Linux is also quite hard, as they have a very different mentality when it comes to code. FreeBSD on the other hand is quite similar, so the effort is much easier. So with a very small developer team it is the best option.
Also you should note that trying to tell devs how they do their work is likely to make them less motivated, not more motivated. I think encouraging remarks, and suggesting ideas is the way to go.
We all wish we had more time and money to devote to working on Haiku, but the fact is that it is a lot of complex unpaid work.
Please do not get offended…I have great respect for you developers…I am not undermining your efforts…sorry if my post conveys such a meaning…
I, as a end user, just wrote my feelings, when I saw the reversal of the commit…
I am well aware that you people devote your time and work unpaid for…
I have seen FOSS projects die due to lack of funding…
Maybe, my wordings should have been better…
tbh, please accept my humble heart felt apologies since my post has hurt you…hence forth…
I will be more careful in whatever I post
My sincere apologies to all the developers, team of Haiku…
SORRY…
I don’t think anyone is, so no need to apologize. I might also misread your question a bit. As a bit of more info we started with our own drivers, but most are now based on FreeBSD as it is easier and works better.
Oh and FreeBSD devs have been helpful sorting out issues and we fixed a bug or two for them.
What makes you think so? They have in the past integrated our fixes to the drivers and been very supportive of our reuse.
This change was merged too early because of a misunderstanding (my fault once again): I reviewed the code and assumed that the other developer submitted the change had tested it. He assumed that I would test it before merging. As a result, no one tested it and debugged it.
We will identify who in the developer team has a wifi card using this driver, and will do a test run and find the problems, and then submit the change again.
I’m happy to help test, I have that card.
If you mean my net80211 change, i actually tested it, and it works with three WLAN drivers. And I mean as good as before. Now a user reported a regression with this change. It is reverted for now until the user can elaborate about it.
Ok, then we “just” need to test it more on more hardware and the problem is not as bad as I thought.
There is a trend of us reverting changes too quickly to be honest. Nightly images are unstable by definition. If someone reports a regression, it would be beneficial to spend a few days to investigate the complaint instead of immediately reverting the change. (especially when the pros of the change are huge such as on this one)
While i’m not involved in this issue, I can relate because it’s a battle i’ve fought multiple times now 
now if there were complaints, and nobody had the time / energy to investigate them (or they’re unwilling to)… then yeah, a revert is warranted.
Specially now that we can boot an older version. In case I always hav two partition, one that I “backup” my current installation to before updating my system.