Re: Security upgrade for potato by new major version and distro change?
On Tue, Jan 23, 2001 at 10:13:33PM +0100, Tollef Fog Heen wrote:
> * Matt Zimmerman
>
> | Not necessarily. The core of the code is written in C, and the maintainer
> | should be able to read and write C comfortably in order to effectively maintain
> | the package. The interfaces for other languages are generally small bits of
> | glue that don't have very many bugs and don't change very often.
>
> 35960 lines of code for the jdbc interface is not what I call 'small
> bits of glue'. 2000 lines of perl glue (about 650 lines perl, the
> rest C) isn't necessarily little either - depending on the perl
> style.
If the Java portion of the code really is that extensive, then I would say yes,
the maintainer should be familiar with Java programming. AFAIK, there is no
standard way to call C code from Java (and indeed this would violate the Java
platform model), so I can imagine that the code is nontrivial.
Perl XS modules are C code, but once working, are generally pretty trouble-free
in my experience.
Libraries, it seems, underline my point. If you maintain a library package,
the users of your package are very often programmers. They will report bugs
against the library if it isn't working as they expect, sometimes due to the
user's own errors. The maintainer needs to be able to recognize that the user
is using the library correctly in order to close the bug.
I'll say that the maintainer should be at least as knowledgeable as the average
user about his/her package. A good maintainer will know his/her packages very
well indeed. I see this as one of Debian's strengths: since packages are
maintained by volunteers who take an active interest in them, they tend to be
well cared for.
> | In the event that a problem arises with the Tcl bits, I imagine I
> | could post a message here or elsewhere and ask for help.
>
> of course. As you could if the problem was not knowing enough C or some
> other language.
The difference is one of scale. If I didn't know enough about the core of a
package that I had to post to debian-devel about most issues with the code, I
wouldn't be maintaining the package anymore; -devel would, with me as a
sponsor.
> | If I needed to do this every time a change was necessary in a C
> | source file in one of my packages, my progress would be very slow
> | indeed.
>
> I guess that depends a lot on the package. Many packages which use autoconf
> and automake do only need dh_make and then some minor adjustments.
In order to be packaged initially, sometimes it's this easy. But to be most
useful to Debian's users? To be best integrated with the rest of Debian? To
be maintained in the long term?
--
- mdz
Reply to: