[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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: