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

Re: Zoom- best practice?



The Wanderer (12020-06-09):
> (Please stop CCing me on replies - especially to messages which I did
> not actually send - unless you're specifically trying to draw my
> attention to a particular message and think I may not notice it without
> the CC. Not only am I subscribed, I am in fact reading this thread on a
> multiple-times-a-day basis, as my multiple replies to it to date may
> have indicated.)

Instead of writing this periodically, you could include:
Reply-To: debian-user@lists.debian.org
in your headers just like I did. Properly configured mailing-list
software does it by default for subscribed users, but Debian is an
exception. It fixes the issue of annoying ccs once and for all.

> FWIW, I have tried, at least in part.
> 
> For the individual broken-out projects (which may or may not be rolled
> up into the larger "master" project, I can't easily tell), I succeeded
> with one, and failed with another, but suspect that I could succeed with
> the latter with more effort.
> 
> For the apparent "master" project, I admit that I didn't bother to try,
> because of the exact "too many prebuilt apparent-dependency objects with
> no apparent way provided to rebuild them" issue; unless we can rebuild
> those objects, not only can we not be sure we have the source for them,
> we can't be sure that building with a different version of that object
> will even work.
> 
> Even a successful build from a repository like that would not
> demonstrate that you can actually completely rebuild the project from
> scratch; you'd have to actually track down the source for all of those
> individual prebuilt objects, rebuild each one, and pull the result in to
> the build in a way which will get picked up, and that's more effort than
> I'm willing to put in for the sake of a mailing-list discussion like
> this one.

Thank you for these clarifications.

> I don't fault the developers too much for providing a version of the
> project tree with prebuilt dependencies like that; it's a useful
> convenience for those who just want to get it to work and for whom
> farting around with trying to find the right dependencies and get them
> into place would be too much of a hassle. But for (as far as I can tell)
> providing the tree in *only* that form, and not providing (as far as
> I've found) *any* documentation on what these prebuilt objects are and
> why they're needed and how to get them separately and build them and so
> forth, there I do fault them, and consider that a ding against proper
> Free status.

I state it that way: the knowledge of how to obtain and build these
objects is part of the source code of the project, just as much as a
makefile or configure script. Unfortunately, that bit of source code
only resides in the head of the developers, it is not distributed.

Consider a minified javascript program with a GPL license header slapped
on top of it: should we consider it Libre Software? Of course not. The
same happens here: out of negligence probably, the authors keep part of
the source code for themselves. It is not Libre Software.

Regards,

-- 
  Nicolas George

Attachment: signature.asc
Description: PGP signature


Reply to: