Old modules

[Jeff Kirsher]

Wow! Lot's of interest/responses on this... would have never figured.

Well let me add my $0.02 on the subject.  First I do not think that
there should be a "extra" mailing list for old modules.  As pointed
out previously, the amount of mail on both Lunar and lunar-dev mailing
list is very low, we can assume the new mailing list will follow suit,
in which case there is no reason to have an additional email list.

Let me also tip my hat to all the current developers.  While being
busy folks, they have still found the time and energy to keep Lunar up
to date while trying to incorporate new modules (i.e XOrg 7.0 and 7.1
for example).  I too am new to lunar, but not new to linux or
developing and I will say that the response I have received in the
lunar-dev mailing list is good and FAR better than other mailing lists
which I have posted patches to.

<soapbox>
Auke shares my pain when it comes to submitting kernel patches on
netdev, and getting a lack of response from the maintainers.
</soapbox>

I can also see the possibility for ways to improve or make Lunar
better.  Some one mentioned that bugs are not being entered on modules
which need to be updated.  While I agree with that process, I also
feel that entering a bug about a particular module is something that a
user who does not which to participate in the developement should do
to get a module updated or fixed.
I personnally would feel that it would not be a good use of my time to
enter a bug on a module when I can create a patch to resolve the issue
in less time and submit it to lunar-dev mailing list.  I also do not
have the expectation that just because I created a patch and sent it
to the mailing list, that the first developer to see it should commit
it.  I personally know that all good developers do not ASSUME
anything, and would validate the work I did in the patch, before
commiting it.  At least that is what I would do, personally I feel a
week or less turn around time to committing a patch is acceptable, and
Lunar has been excellent from my perspective.

While others have not had the same experience that I have in
submitting patches, I would like to find a possible solution that
would agree with everyone.

First, some have elluded to not being able to submit patches/modules
and having the submissions committed.  Possible resolution to this is
to have a developer completely dedicated to responding to
non-developer submissions.  I personally would not mind taking charge
of that, even though I have a very busy schedule.  I am also not
opposed to someone else taking on that responsibility.  This developer
could also ensure that the Wiki information on the "proper" patch
submission is followed and updated for users.  In any down time,
assist the other maintainers in developing and updating modules.  But
the primary focus would be to respond to the users submissions.  That
way when a user submits a module, they can have the expectation that
the patch will either be committed within a reasonable amount of time
or a response will be given to the user why not.

Secondly, for older modules which are no longer being developed
because they are "perfect", maybe we can add a flag in the DETAILS
file.  This is just a thought, that way if a user looks at the details
of a module, they know not to expect a newer version of the module any
time soon.  This also would not prevent the module from being loaded.

As far as getting stats from user installs as to which modules are
being used or installed, I can see a number of issues with that.
First of all, getting data from a user MUST be made an option for the
user to choose to do, unlike Microsoft, who collects information from
every machine which installs their OS.  They have gotten a bad rap for
good reason regarding this issue.  Secondly, if for what ever reason
such a data collecting option were available and was not made to be a
voluntary submission, false statistics will be generated from
developers who just install modules to ensure that that a patch or fix
works properly on Lunar and do not intend to use the module at all.  I
do that quite frequently.  This would generate stats that do not
accurately count the real number of users actually using the program
or module.
A possible resolution to this would be to create a system tool to
allow the user/developer to take inventory of installed
programs/modules and send the data to a repository when and only when
the user/developer chooses to.  (i.e. lunar snapshot)  Again this is
jsut a thought and would need further discussion and definitely
development.

Well I have rambled on too long, what does everyone else think?
Feel free to flame me all you want, it will be nothing in comparison
to what David Miller has done on the kernel mailing list. :)

-- 
Cheers,
Jeff