Re: [madwifi-project] [RFC] Closing the project

[Stephen Clark]

Luis R. Rodriguez wrote:
> On Wed, Nov 12, 2008 at 7:31 PM, Pavel Roskin <proski@xxxxxxx> wrote:
> > On Wed, 2008-11-12 at 12:24 -0800, Luis R. Rodriguez wrote:
> >
> > > Those who are interested in this should work on it if no one else is,
> > > just take it and go. Bureaucracy gets in the way here IMHO.
> > It's not about bureaucracy.  I need help with porting the code from one
> > branch to another.  In particular, with fixing SMP locking issues in the
> > 0.9.4 branch.  The trunk doesn't have those issues.
>
> If you are not getting help its because there is a lack of interest
> from developers. I expected this once ath5k got upstream and once more
> documentation was available.
>
> > > Distributions will soon prefer ath5k over MadWifi. At that point
> > > MadWifi becomes a relic. Its surely good to keep MadWifi code
> > > somewhere for reference, or maybe for the last few devices maybe not
> > > yet supported, but any other effort put into seems like fruitless
> > > effort spent IMHO.
> > As far as I know, we don't have DFS in mac80211.  In fact, the AP mode
> > in mac80211 has just been enabled.
>
> Right, more notes on this below.
>
> > > I don't have experience with bounties but I do know I get random
> > > requests to support one thing or another for money. I am going to be
> > > redirecting these request more to bounties put up for upstream
> > > development. I know people will work on things anyway but what I want
> > > to try to do is get monetary support one way or another to those
> > > working upstream.
> > OK, let's consider it on the case-by-case basis.
>
> Well I'm just going to direct people towards bounties myself for
> upstream work. That's the advice I will be giving personally. But I do
> think it would be good for the project to also reward upstream work
> too, wasn't that the whole point behind the project?
>
> > > I'd like to encourage the money left for the project for similar
> > > purposes. Reward upstream development.
> > Maybe we could have a bounty for DFS implementation in mac80211?  Just
> > to try how it would work.  I also this that there should be a strong
> > moral incentive for the winner.  Not just a name in the log, but a web
> > page about the winner on kernel.org.  This way, we would attract people
> > striving to improve their resumes, not just get extra money.
>
> We will be working on DFS on mac80211, I will start first with STA
> DFS. Also expect a lot of work from us on AP support.
>
> > > I think MadWifi has become a big bureaucratic entity and this large
> > > bureaucracy is simply not needed.
> > I agree that we have a lot of documentation that is becoming irrelevant.
> > I prefer to keep documentation to the minimum, as it stimulates
> > developers to write software that just works, without lengthy
> > instructions.
> >
> > But the bug tracking system has some important information that we still
> > may need.
> >
> > I think the biggest impediment to MadWifi development was not
> > bureaucracy.  It was the non-free HAL.
>
> Not really, even with an alternative people are still used to coding
> with it and find it easier to commit into an svn repository than
> submit  patches upstream. Maybe our process is move involved but there
> its also why Linux code has a certain quality in it. We tend to frown
> upon crap. If MadWifi ever were to touch Linux it would be tainted
> with CRAP.
>
> > Many bugs are too hard or
> > impossible to solve without having access to HAL.  As the easy bugs get
> > fixed, the ratio of HAL-related bugs grows further.
> >
> > We have HAL sources, but it's not the sources we could use in Madwifi
> > without losing some functionality.  Sure enough, the HAL sources could
> > help with some issues.  But it's still impossible to put debug
> > statements into the HAL uses in MadWifi.
> >
> > I'm thinking of having "MadWifi free edition" with limited hardware
> > support specifically to address the issue of "debuggability".  Also,
> > some users may free code plus MadWifi features.
>
> I really think this is good for those interested and I respect it but
> I am going to be very very honest here: this is a complete fucking
> waste of time. People, MadWifi is dead, stop trying to keep it a live
> by injecting its heart with adrenaline, it won't work, just pull the
> plug already. If any feature is missing I think it would be more
> productive to identify it and point it out and those interested in
> upstream work will add it.
>
> >  Some users may want
> > support for exotic CPUs not supported by any non-free HAL.
>
> For that you can use the Linux kernel which will get you support on
> the largest number of CPUs possible.
>
> > >  We wanted free drivers, we have them
> > > now, we have opened up the HAL and have even opened up more drivers
> > > and continue to do so. What I find useful from MadWifi from an
> > > upstream perspective is the mailing lists and a central place for
> > > people to get information/news regarding Atheros devices supported
> > > upstream but I guess we can just keep this in the wireless wiki.
> > I agree that it's better to start anew with the documentation for the
> > free drivers.
> >
> > > Mailing lists are pretty useful though.
> > Yes.
> >
> > > I agree there is some useful information present but a lot of it is
> > > purely historical and I don't think much resources is needed to keep
> > > that around. I suspect distributions will start preferring ath5k over
> > > MadWifi around December if not already so I'm indifferent in closing
> > > MadWifi. In my head MadWifi is dead already though and would recommend
> > > we only promise users it will be in maintenance mode, meaning the
> > > MadWifi driver will only get submitted bug fixes and security fixes.
> > I agree with you.  We should fix the code already in MadWifi branches.
> > It means we should not be _closing_ the project now.
>
> Just my advice: let MadWifi die already, stop wasting your time.
Yeah but ath5k doesn't work on my zyxel ar5212 based wireless card only
madwifi works!
>   Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/