All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: Michael Renzmann <mrenzmann@madwifi-project.org>,
	madwifi-project@lists.madwifi-project.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [madwifi-project] [RFC] Closing the project
Date: Thu, 13 Nov 2008 15:48:36 -0500	[thread overview]
Message-ID: <1226609316.2904.18.camel@dv> (raw)
In-Reply-To: <43e72e890811131142p3f72c964t802d424b0ddb3456@mail.gmail.com>

On Thu, 2008-11-13 at 11:42 -0800, Luis R. Rodriguez wrote:

> 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.

That's great news!

> >> 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.

OK, HAL was not the only reason.  Let's say there is good bureaucracy
and bad bureaucracy.  The difference is the former is helpful and the
later is not.  The kernel is an excellent example of good bureaucracy
that we should learn from.

It would be great to have a detailed analysis why MadWifi failed.  It
would be useful for other projects.  I'm short on time to do it right
now, but I may do it later.

I think we should have done more to prevent incomplete or broken changes
from being committed.  The reason I cannot backport SMP fixes is because
they were committed as series of commits that involved other issues as
well.  Such sloppiness should have been prevented.

> Just my advice: let MadWifi die already, stop wasting your time.

I understand what you mean, but I have to deal with MadWifi anyway.  As
I said before, I'd rather share my fixes that keep them to myself.

-- 
Regards,
Pavel Roskin

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Roskin <proski@gnu.org>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: Michael Renzmann <mrenzmann@madwifi-project.org>,
	madwifi-project@venema.h4ckr.net,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [madwifi-project] [RFC] Closing the project
Date: Thu, 13 Nov 2008 15:48:36 -0500	[thread overview]
Message-ID: <1226609316.2904.18.camel@dv> (raw)
In-Reply-To: <43e72e890811131142p3f72c964t802d424b0ddb3456@mail.gmail.com>

On Thu, 2008-11-13 at 11:42 -0800, Luis R. Rodriguez wrote:

> 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.

That's great news!

> >> 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.

OK, HAL was not the only reason.  Let's say there is good bureaucracy
and bad bureaucracy.  The difference is the former is helpful and the
later is not.  The kernel is an excellent example of good bureaucracy
that we should learn from.

It would be great to have a detailed analysis why MadWifi failed.  It
would be useful for other projects.  I'm short on time to do it right
now, but I may do it later.

I think we should have done more to prevent incomplete or broken changes
from being committed.  The reason I cannot backport SMP fixes is because
they were committed as series of commits that involved other issues as
well.  Such sloppiness should have been prevented.

> Just my advice: let MadWifi die already, stop wasting your time.

I understand what you mean, but I have to deal with MadWifi anyway.  As
I said before, I'd rather share my fixes that keep them to myself.

-- 
Regards,
Pavel Roskin

  parent reply	other threads:[~2008-11-13 20:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2576.194.45.26.221.1226491274.squirrel@webmail.madwifi.org>
     [not found] ` <1226511194.9952.38.camel@dv>
     [not found]   ` <43e72e890811121224w4fc53e1s29080a42111186e9@mail.gmail.com>
     [not found]     ` <1226547092.11785.49.camel@dv>
2008-11-13 19:42       ` [madwifi-project] [RFC] Closing the project Luis R. Rodriguez
2008-11-13 19:42         ` Luis R. Rodriguez
2008-11-13 20:21         ` Stephen Clark
2008-11-13 20:38           ` Luis R. Rodriguez
2008-11-13 20:48         ` Pavel Roskin [this message]
2008-11-13 20:48           ` Pavel Roskin
2008-11-13 20:54           ` Luis R. Rodriguez
2008-11-13 20:54             ` Luis R. Rodriguez
2008-11-13 21:11             ` Pavel Roskin
2008-11-13 21:11               ` Pavel Roskin
2008-11-13 23:26               ` Derek Smithies
2008-11-13 23:26                 ` Derek Smithies

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1226609316.2904.18.camel@dv \
    --to=proski@gnu.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=madwifi-project@lists.madwifi-project.org \
    --cc=mcgrof@gmail.com \
    --cc=mrenzmann@madwifi-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.