Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers
>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
Per> Thomas Schoepf <schoepf@informatik.tu-muenchen.de> writes:
Per> Improve the code and merge it back to the original, _instead_ of
Per> distributing your modified version (a contribution).
But that is exactly what we do. *All* patches and bugfixes that are
not debian specific are filed upstream.
Example: I am the Debian maintainer for xisp, a pppd frontend. It has
the default modem device hardcoded. I changed the a file and the
Makefile to use a variable setting in my working copy and tested it,
so that there are no problems. Yesterday, I mailed the upstream the
patch. Let's see what he thinks of it.
If he refuses this change (and I am sure he will not, as I have made
such contributions before to him) and if I believe the change is important
for the integration of the package into the Debian system, I will still
include the fix in the Debian version.
Note that I didn't just change the thing in the Debian version and
that's it. This is what you think we do. This is *not* the way Debian
works with the code.
Xisp has tables to calculate phone costs. I received the data for a
new telco to include by a Debian user. Checked the data and then
forwarded the mail upstream. The data was included by the author,
he was happy, I was happy, and the user as well.
If I get a bug report, I check if it is a packaging bug, or something
in the programm. If it is something in the program, I check if I can
fix it (and have the time and knowledge to do so). If this is the case,
I send the patch upstream, with a pointer to the Bug Tracking System's
archive of the conversation I had with the user about the problem.
The author can then evaluate the problem and maybe come up with a
better fix or he can accept my patch or whatever.
If I can't deal with a problem in the program, I will send the bug
upstream with a pointer to the BTS archiv of the conversation with the
user. This archive does contain valuable information like system
libraries, ldd output, strace output and descriptions how to reproduce
the problem etc. at this point.
In my experiance, the upstream authors appreciate the information they
find in the report, as they don't have to find out these things on their
own, but can go streight ahead to tackle the problem.
What is your problem with such work? I don't understand it. Seriously.
>> > > > "Oh, you need a 64bit clean version. Just use Debian."
>> > >
>> > > "Oh, you need a 64bit clean version. Just ask the maintainer of your
>> > > current distribution to use Debian patches. Or ask the upstream
>> > > author to integrate them - or equivalent. These patches are free."
>> >
>> > Which one is shortest?
>>
>> I don't understand this argument. Is the validity reciprocal proprotional
>> to the number of words in the statement?
Per> The shortest and easy answer is the one most likely to be given
Per> to someone asking for the functrionality, thus lessening the
Per> chance of him actually working with the developer to move the
Per> functrionality back into the mainline code.
Sorry, but I think you missed the point.
- queso was not 64 bit clean.
- the Debian maintainer fixed the code, and has a working patch, that
doesn't produce any problems.
- he sent the patch to the upstream
- the upstream didn't react
- some time after, the upstream sources are still not 64 bit clean.
So what do you think we should do?
We need the functionality. But we don't want to fork. A fork should be
avoided, and I believe most of us don't have the time to do full
developement. We can do small fixes, but we are packagers, we don't
want to replace the upstream.
If a Red Hat user needs a 64 bit version of queso, I will say "use the
Debian version or take the fix from the diff and compile queso yourself".
The upstream version is not useable in a 64 bit environment. What do
you think I should say instead? A working patch was filed upstream,
but it was not used, nor is there a upstream patch for this
problem. The Debian fix is the only way.
Ciao,
Martin
PS: I do think that pgnus shouldn't have been released as a Debian
package. As you see, I have put my gnus package on hold and don't
update it. I also adviced a friend of mine, who installed it without
knowledge of its alpha nature, to downgrade.
But it is Manoj's package, not mine. And it was his decision to put
it into the unstable tree.
I think it was a mistake, but it shouldn't dictate your
view of the Debian processes in general.
Reply to: