Re: To package or not to package?
Charles Plessy wrote:
> I jump in the discussion to react to Zack's point of view about
> packaging:
>
>> However, in many cases, free software developers tend to reinvent the
>> wheel quite often (so two apps can share the exact same goal and have
>> very similar designs, the only difference being that one is of less good
>> quality than the other). It's generally a bad idea to package both
>> apps in this case, because it increases the workload, reduces the
>> users-per-package ratio, etc.
Um, those are Lucas Nussbaum's words, not mine. You didn't quote anything
I wrote.
> In the field I decided to cover, I took another approach: packaging A
> but not B biases the competition towards A, although I do not feel able
> to make a choice between A or B which would be logical and fair.
It seems to me that Lucas is referring to situations where making a logical,
fair choice between A and B is easy (because the only salient difference
is that one "is of less good quality than the other"). In situations like
that, sure, don't package the poorer-quality or less-maintained one. [I am
not suggesting packaging everything that goes by on freshmeat.net.] In cases
where it's less clear cut, though, I'm with you: package them all.
Of course, part of why it's so nice that "apt-get install WHATEVER" almost
always works is that the end-user can trust that WHATEVER, once installed,
will itself work. If there's not enough manpower to make that true, it
shouldn't be packaged. But this brings us full circle: let's have more
DDs, I say, so that there can be more packages and still keep up the quality.
zw
Reply to: