lkml.org 
[lkml]   [1999]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Maintainers
In <Pine.LNX.3.95.990509083703.357A-100000@localhost> Gerard Roudier (groudier@club-internet.fr) wrote:

I'll try to summarize discussion. Firstly for "general case" then for tunelp.
I can be wrong here of course.

1. Forking of any software (GPL'd or not) is REALLY BAD THING. This is
undisputable. (Take a look on Unix -- it's not GPL's code but idea is
the same).

Now, why GPL allows it in first place ? Simple:

2. Forking of tree is not the worstest thing in the universe and if it's
needed to solve more important problem this is exactly what's must be done.

Which problems are worse then forking (or probability of forking) ?
One of them:

3. If software in not actively maintained and bugfixes or important improvements
are not made public for long time then someone must step up and take
maintainership. Aven if this will lead to risk of forking.

If working e-mail address of "official mantainer" (and/or primary author
or software if in sources or documentation not written that you should not
bother original authors anymore -- GIMP is example) is known then at least
e-mail with explanation should be sent: mantainer can be just temporarily
unable to actively mantain util/patch/whatever (I was in hospital for almost
the whole April and I was clearly unable to mantain my alternative version
of mod_ssl's EAPI)

Now back to tunelp. Was it actively maintained ? I'll say "CLEARLY NOT".
Looks more like it was not maintained at all... Why ? Let's look on two
versions: Andrea's one and RedHat 6.0's one. We can see changelog in
Andreas's version:
-- cut --
* Revision 1.6 1995/03/29 11:12:15 johnsonm
* Added third argument to ioctl needed with new kernels
*
-- cut --
and we CANNOT see this change (and this note) in RedHat 6.0's version
(spring 1999!). RedHat 6.0 includes version without this [minor] bugfix.
I'll say: if FOUR YEARS was not enough to make version with [even minor]
bugfix available on public ftp and if the same bugfix change from
johnsonm@redhat.com is not even included in RedHat 6.0 then this is NOT
^^^^^^ ^^^^^^^^^^
called "maintainment". If this line was faked by Andrea (god, I hope not!)
and if FOUR YEARS was not enough to make this bugfix then again this is
NOT called "active maintainment".

Now back to Andrea's behaviour. It's inadmissible as well. At last mail with
message: "since for last three years there are was no public versions of
tunelp and since new kernel (2.1.131) has new ioctl to help some peoples
and since tunelp must be changed to help them and I had no time to get your
approval before releasing fixed version (kernel 2.2 is REALLY close now!)
I decided to took over maintainership of tunelp; if you still maintaining
tunelp then here is my version -- take look on it" MUST be sent (better more
polite version of course, but no message at all is unappropriate behaviour).
It's clearly better to have version with "trust the IRQ" option publically
available before new stable kernel (2.2.0) is out not from official mantainer
but it's clearly unappropriate to not try to resolve "forking problem"
afterwards.

P.S. And about linux-parport: it's not clear to me how anyone can maintain
such programm (the sole purpose of which is to tune /dev/lp? via Linux-specific
ioctls!) without even being subscribed to list where changes to this ioctls
are discussed... Peoples from there can send your required changes of course
but better and more effective way in such case is just pass maintainership
to them... IMHO anyway...




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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.426 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site