Maintainers
team...@freemail.c3.hu
".... please it's polite not to take
things over without making at least
some attempt to contact the original
author, EVEN IF YOU DON'T FEEL THAT
THEY ARE VERY ACTIVE. ... "
The thing between Andrea and Michael does bring out this question :
Just what is "POLITE" and what is not?!
I am not siding with either Andrea or Michael on this matter, but my thinking is
that if someone wants to maintain something, someone at least _ought_ to be
active to do the job, or at least be known to still be _ALIVE_ and still willing
to carry on that function. Else he or she should reliquish their "maintainer"
status.
It is utmostly ridiculous to force people in doing a netwide trace for the
"ORIGINAL AUTHOR" for any given patch/util if the code hasn't been updated for
ages, and the so-called "maintainers" just aren't around anywhere.
So what should one do if one finds a bug or two in Linux util/patches?
Should one look high and low for the [elusive] "maintainer"
or should one just post out the bug-fixed patch?!
Should there be a centralized clearinghouse for all the maintainers, so to make
it easier for people to find the _UP-TO-DATE_ addresses of the maintainers?
Note: The _UP-TO-DATE_ addresses of the maintainers
_is_ an important point because there exist
several addresses of the "maintainers" which
are no longer valid.
*I am _not_ refering to Mr. Johnson, btw.
Michael's address _is_ valid.*
IMHO, it is too silly to insist that people must adhere to the "POLITE DOCTRINE"
if the maintainers did nothing to announce their presence.
To the maintainers:
Please announce your presence, at least once-in-a-while,
in appropriate fora.
Please tell us which packages you are maintaining, and
what you expect us to do when we change/fix the code
of the packages you are maintaining.
Any comments?
Sincerely,
Pete
team...@freemail.c3.hu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Gerard Roudier
On Sun, 9 May 1999 team...@freemail.c3.hu wrote:
> "Michael K. Johnson" <john...@redhat.com> sez:
>
> ".... please it's polite not to take
> things over without making at least
> some attempt to contact the original
> author, EVEN IF YOU DON'T FEEL THAT
> THEY ARE VERY ACTIVE. ... "
> The thing between Andrea and Michael does bring out this question :
>
> Just what is "POLITE" and what is not?!
The main task for having software usable is _maintainance_. What is the
most impolite behaviour with software is to make some development or some
tempering and then, to go away. This apply to commercial companies and to
individual as well. If one knows it will be unable to maintain his
software or find another maintainer, he should not provide anything.
The second thing that I consider impolite it to shoe-horn one's name in
any source one has made some change. A minute or hour change is a detail
compared to the time needed to develop and to to maintain a whole
software.
> I am not siding with either Andrea or Michael on this matter, but my thinking is
> that if someone wants to maintain something, someone at least _ought_ to be
> active to do the job, or at least be known to still be _ALIVE_ and still willing
> to carry on that function. Else he or she should reliquish their "maintainer"
> status.
There is a difference between the claimed maintainer status and the actual
maintainer status. A software that is either not officially or not
actually maintained should not be used anymore, in theory, since user
might just be stuck at the first failure he will experience. In practice,
having the source code, allows to try to fix the problem and it seems that
this generally succeed. A software you have the source is _ALIVE_ for you
even if it is temporarily not maintained or not well maintained. A
binary-only software is perhaps just dead for you and you don't know it is
so.
> It is utmostly ridiculous to force people in doing a netwide trace for the
> "ORIGINAL AUTHOR" for any given patch/util if the code hasn't been updated for
> ages, and the so-called "maintainers" just aren't around anywhere.
The original author still maintaining a software is an ideal situation,
not the reality we observe for all softwares. What you point out as
'so-called maintainers' are people that actually spend much time to make
software work. Without any maintainer a software is dead if binary-only
and in comma-mode if source-available, regardless the performance of the
original author(s).
> So what should one do if one finds a bug or two in Linux util/patches?
>
> Should one look high and low for the [elusive] "maintainer"
> or should one just post out the bug-fixed patch?!
>
> Should there be a centralized clearinghouse for all the maintainers, so to make
> it easier for people to find the _UP-TO-DATE_ addresses of the maintainers?
>
> Note: The _UP-TO-DATE_ addresses of the maintainers
> _is_ an important point because there exist
> several addresses of the "maintainers" which
> are no longer valid.
>
> *I am _not_ refering to Mr. Johnson, btw.
> Michael's address _is_ valid.*
>
> IMHO, it is too silly to insist that people must adhere to the "POLITE DOCTRINE"
> if the maintainers did nothing to announce their presence.
The more appropriate place for the address of maintainers is trivially the
source code or some file that is tightly attached to the source code. Any
other place may contain a invalid or not up-to-date address. People that
want to use free software and donnot want to even look into the sources
must purchase a supported O/S package and pay for a commercial support.
For example, I receive, at least once a week, questions from end-users
that have problems with their RedHat installation and that think the
problem is related to the software I maintain. I donnot reply to these
people and am _not_ going to do so.
> To the maintainers:
>
> Please announce your presence, at least once-in-a-while,
> in appropriate fora.
Why not to also pay for advertisements in all technical reviews and
end-user reviews that exist on the planet.
> Please tell us which packages you are maintaining, and
> what you expect us to do when we change/fix the code
> of the packages you are maintaining.
>
> Any comments?
Some people should immediately stop drinking tequilla.
Regards,
Gérard.
Rogier Wolff
> It is utmostly ridiculous to force people in doing a netwide trace
> for the "ORIGINAL AUTHOR" for any given patch/util if the code
> hasn't been updated for ages, and the so-called "maintainers" just
> aren't around anywhere.
> So what should one do if one finds a bug or two in Linux util/patches?
As a maintainer, you should mark the sources with your Email
address. That way people can contact you when they find a bug.
As "someone who has found a bug" you are expected to contact the
maintainer by Email. If you don't get a reply in a week, it is
appropriate to perform a quick "who's where" or "bigfoot" search, to
see if this Email address has become stale. If a week later there
still isn't any answer, it becomes appropriate to post the patch
together with a remark like "Does anybody know where .... went?"
When that doesn't turn up an active maintainer, I guess you're
welcome to take over.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
Khimenko Victor
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
john...@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...
Michael K. Johnson
team...@freemail.c3.hu writes:
>I am not siding with either Andrea or Michael on this matter, but my thinking is
>that if someone wants to maintain something, someone at least _ought_ to be
>active to do the job, or at least be known to still be _ALIVE_ and still willing
>to carry on that function. Else he or she should reliquish their "maintainer"
>status.
>
>"ORIGINAL AUTHOR" for any given patch/util if the code hasn't been updated for
>ages, and the so-called "maintainers" just aren't around anywhere.
The source code includes my email address. Andrea clearly saw it; he
dropped in a similar line below it. I have done EVERY piece of
maintenance that I have EVER been asked to. Some software simply does
not require a lot of maintenance because it is relatively simple.
Doing regular noop releases just to assert ownership is childish.
I'm here, my CURRENT email is in the source code, I own the copyright,
no one ever told me that I'm dead, no one ever sent me a patch or asked
me to make a change.
All that said, if I'd simply been asked to relinquish maintainership to
Andrea, I might well have agreed. Andrea has now actively refused to
so much as send me a patch. How rude can you get?
>So what should one do if one finds a bug or two in Linux util/patches?
>
> Should one look high and low for the [elusive] "maintainer"
> or should one just post out the bug-fixed patch?!
If Andrea had even posted the patch, that would have been better,
even if he didn't bother to tell me about it, if I found out about
it, I could look at it and decide whether to apply it as it stands
or to rework it.
By contrast, Andrea
o knew my email address
o couldn't bother himself to drop me a note
o now actively refuses to send me a patch
o castigates me for being unhappy about this
o insists that his doing so is appropriate
> Please announce your presence, at least once-in-a-while,
> in appropriate fora.
That's silly. The established convention is to put contact information
in the package. Putting the burden on the maintainer to say over and
over to the whole world, "Hey, look at me, look at this software I
maintain!" is ludicrous.
...
This whole thing is way overblown, and I didn't mean to make a huge deal
of it. tunelp is, by design, a small program. I'm not unwilling to
consider handing it off if that's appropriate. The only reason I keep
talking about this is that I'm worried about a general uncooperative
spirit here damaging the whole community. I can lick my wounds and shut
up -- that's what I did for months until the problem was brought up by
someone else and my opinion asked...
michaelkjohnson
"Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
Andrea Arcangeli
>so much as send me a patch. How rude can you get?
I _hope_ to be still allowed to choose what to do in my spare time. As
just said right now I choose to not send you tunelp patches in my limited
spare time simply because I want to do other kernel things that are taking
my mind busy for all my spare time.
While now I am been amazed reading your email, I won't be surprised if in
the near future you'll tell me that I am rude because I won't donate 1
billion of dollars to you.
Andrea Arcangeli
Theodore Y. Ts'o
From: Andrea Arcangeli <and...@e-mind.com>
>so much as send me a patch. How rude can you get?
I _hope_ to be still allowed to choose what to do in my spare time.
Andrea,
You certainly have the right to do so. However, not dropping
Michael a note when his name was clearly listed in the sources was
indeed very rude. Your further claims about how you can't be expected
to search the entire web looking for the maintainer, and ignoring the
fact that his name and copyright were on the sources --- and that maybe,
JUST MAYBE, he was the maintainer --- wasn't rude per se, but it was
lame.
No one is claiming that what you did was somehow illegal;
however, what you did did contradict the general customs of our
electronic society. You can choose to be antisocial if you wish, but
then you have no right to complain when people choose to call you
antisocial.
That being said, it sounds like you might have a legitimate beef
if you think that Michael hasn't been a responsive maintainer. If that
were the case, the right thing to have done was to send a private note
to him asking what the status was. If you had done that, he might very
well have given the maintainership over to you, and that would have been
that. If you then don't get a response from the maintainer, it would
have been appropriate to send an e-mail message to the list asking about
who the maintainer was, and so on. But there are a set of customs that
you have to follow if you don't want people to think you are a loser.
These customs have been informally codified and people have
lived by them for a very long time. More recently, Eric Raymond has
done a fairly good job of formally describing them, if you're not
already familiar with them; please read Homesteading the Noosphere if
you want to see a treatment of these customs from the point of view of a
net.anthropologist.
The main thing, though, is that courtesy is really good thing
for everyone. So may I suggest that we just drop this. Let's assume
that Andrea simply didn't understand the rules and accidentally
transgressed them without meaning to hurt anyone, and let's move on.
We're all trying to work together, remember? Let's remember who the
real enemy is; this in-fighting serves no purpose.
- Ted
Riley Williams
>> So what should one do if one finds a bug or two in Linux
>> util/patches?
>> Should one look high and low for the [elusive] "maintainer"
>> or should one just post out the bug-fixed patch?!
> If Andrea had even posted the patch, that would have been
> better, even if he didn't bother to tell me about it, if I found
> out about it, I could look at it and decide whether to apply it
> as it stands or to rework it.
> By contrast, Andrea
> o knew my email address
> o couldn't bother himself to drop me a note
> o now actively refuses to send me a patch
> o castigates me for being unhappy about this
> o insists that his doing so is appropriate
I wouldn't worry about that, I stopped reading mails from that luser
ages ago as well over 90% of them were just flamebait with nothing
worth reading in them...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
Zygo Blaxell
Gerard Roudier <grou...@club-internet.fr> wrote:
>The more appropriate place for the address of maintainers is trivially the
>source code or some file that is tightly attached to the source code. Any
>other place may contain a invalid or not up-to-date address.
This implies that if you change jobs or ISP's, you have to re-release
new versions of all the software you have ever released as a primary
author or maintainer. This can be onerous if you've written a lot of
small packages. Imagine pushing out a megabyte of new .tar.gz files
with a changelog entry like:
foo 1.4.2: Exactly the same as foo 1.4.1, except that in the
source code comments and README file the address is now
'zbla...@furryterror.org' instead of 'zbla...@myrus.com'.
Except for timestamps, the binary images are byte-for-byte
identical.
Users don't want that upgrade. Archive maintainers would probably like
to avoid using up bandwidth for it, especially those that are the targets
of thousands of mirror programs that will download the entire file just
because it has a different name.
If you're actually making changes to the code, then you can include a
change of address anyway, and the incremental cost of that change
is trivial and more than compensated by the benefits of whatever it is
you are extending or fixing other than your email address. But if your
code has been quiet for a year or two, issuing a trivial update isn't
all so trivial.
In the specific case of tunelp I don't really understand why it, and
several utilities like it, like kbd, modutils, setserial, etc. don't
get maintained along with the kernel device driver. tunelp is a trivial
command-line program that doesn't do _anything_ other than configure a
Linux-specific device driver with some ioctl()s. If it did as much as
a scan for external devices on the parallel port I would agree that it
may be complex or non-Linux-kernel-specific enough to need to be
maintained outside of the kernel sources, but that's not the case...
--
Zygo Blaxell, Linux Engineer, Corel Corporation. zy...@corel.ca (work) or
zbla...@furryterror.org (play). Corel may disagree with my opinion (above).
Size of 'diff -Nurw [...] winehq corel' as of Tue May 11 15:14:00 EDT 1999
Lines/files: In 54144 / 292, Out 16700 / 154, Both 48717 / 329
Michael Cunningham
Maybe we should set up a central server that all package
maintainers and kernel coders can get an email alias at.
Then.. when someone moves they can just ssh in and change
their .forward file. I would offer to do it, but a 56k
modem connection wouldnt cut it:) and adsl is 6 months
away in my area.
Mike..
--
Speed of Lightning, Roar of Thunder!
Fighting All Who Rob and Plunder...
UnderDog.. Ahhahah UnderDog!