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

Re: Packaging ACT-R -> Answers from upstream



On 18-May-2005, François-Denis Gonthier wrote:
> I would like to know what I should do about this email I received
> from the maintainers of a upstream package I would like to package.

The topic of other parties redistributing one's software can be
touchy. Above all, remain polite and calm in your correspondence. It
seems that you have been doing that so far; I encourage you to
continue.

> I understand his reasons for not supporting third-party package.  I
> won't pull their arms into changing the way they release updates.

I think they have somewhat misunderstand your question.

Many software vendors have a limited interpretation of "support" as
meaning only "direct support to end users for software bugs", since a
large part of their time may be spent supporting end-users directly.
Perhaps if you were to avoid the term "support" when referring to
assistance in packaging, you may meet fewer psychological barriers.

On the other hand, they do seem to be directly addressing the question
of support for re-packaging (with a "no sir, we don't like it").
They're not quite saying that you *must not* redistribute it, nor that
you *must* label it as "not an official version"; however, it's clear
they would prefer those restrictions.

This is a problem. To my reading of their response, it seems they want
their users to have less freedom than their license specifically
grants.

> I just think users would benefit from having this package integrated
> with their favorite common lisp environment. Getting that software
> to work has been quite painful to me without a Debian package.

You might try emphasising that Debian GNU/Linux (please refer to it
with that name, not the archaic "Debian Linux") places responsibility
on its package maintainers to mediate end-user requests and bug
reports. They would benefit from having a single, experienced point of
contact (you!) for interacting with a large base of potential end
users.

You could contrast this (gently) with the alternative: that their
software is distributed ad-hoc by other parties, but is not maintained
by those parties; leaving the recipients of those distributions to
bring packaging problems home to the upstream authors. You might even
find that this scenario is all to familiar to them, and they have
reacted negatively -- hence the "label yours not official" request.

> I replied to him saying that I would think about going on without
> their explicit support, but I don't really like doing that.

I think your services *to the upstream authors* are potentially quite
valuable, and they may be able to see that with the right discussion.

> I also suggested him that it was doable to build a package that
> builds a package using freshly downloaded sources.

Do-able, but hardly desirable. The package maintainer becomes a mere
middle-man in that situation, and is far more limited in how she can
contribute.

Much better to help both the end-users *and* the upstream authors, by
managing bug reports and feature requests, fixing them for your users
if possible, and establishing an ongoing relationship with the
upstream authors to get those changes integrated.

Good luck, and let us know how you go.

-- 
 \     "Homer, where are your clothes?"  "Uh... dunno."  "You mean Mom |
  `\   dresses you every day?!"  "I guess; or one of her friends."  -- |
_o__)                                     Lisa & Homer, _The Simpsons_ |
Ben Finney <ben@benfinney.id.au>

Attachment: signature.asc
Description: Digital signature


Reply to: