On Wed, 2003-10-01 at 22:12, Barak Pearlmutter wrote:
> - the enormous number of snippets. I would be surprised if fewer
> than 10% of our source tarballs contain snippets. Maybe a lot more.
I wouldn't. I'm not aware of any besides in emacs. A quick grep of
/usr/share/doc (where else should snippets be?) for 'not modify' didn't
find any relevant results through the point where I gave up, after pages
of irrelevant hits.
> - the difficulty of finding them. enormous task.
That is irrelevant. No one is proposing we halt all work to go on a
quest to find all snippets. Rather, it is being proposed that
A. Bug reports filed about specific ones be handled by removing
those specific 'snippets'
B. Maintainers should make a reasonable effort to look at their own
packages, just like they do (in theory) for licensing issues.
>
> - the difficulty of removing them when found.
>
> + removing them in a patch file, or not putting them in the
> binary, is not enough! since they are not part of the software,
> whatever property they have that makes us unwilling to
> distribute them applies equally to distributing them inside
> source tarballs.
"tar" is SUCH a hard command to use!
>
> Currently we to my knowledge have one (1) package containing
> "dingleberries", which I will define as materials that we feel
> must be removed for license reasons from the upstream tarball in
> order to make the debian .orig.tarball. This is the linux
> kernel,
That's not the only package. I'm pretty sure there are a lot more
packages like that; one that comes to mind in XFree86.
> which contains binary firmware sans source which must be
> removed. As the kernel packagers will I'm sure confirm, that is
> a pain in the tush. Now imagine that 10% of debian source
> packages had dingleberries in their upstream tarballs. And not
> just one dingleberry, but often a couple. Changing with time.
Huh? I thought the whole point of snippets were that they were static
information about things like why they author wrote the software. They
shouldn't change over time.
>
> This would be a logistic nightmare.
Not really. If it were really a problem, simple tools could be developed
to deal with it.
>
> For one thing, our mechanisms are not set up to support
> dingleberry removal. So new mechanisms would be needed all over
> the place: .../debian/clip-from-upstream files listing them,
> probably the list would need to go into the .dsc files in order
> for cvs-upgrade to work properly, etc.
That's silly. All that needs to be done is remove a file from a tarball.
> All kinds of confusion
> would ensue, as people wonder why so many of our "pristine"
> source tarballs differ from the actual upstream source tarballs.
I haven't heard much confusion, and I'm sure many already do. And to
answer all that confuses would take all of what, one paragraph?
>
> + lots of bickering would start to happen, as people complain
> about missing snippets. upstream authors would get pissed off:
> "why did you take out the heartfelt email from my dead sister?
> i want it in to help inspire other to join me in this great
> endeavor to fight cancer!"
Well, maybe a maintainer should, uh, I don't know, talk to upstream
every once and a while? You know, maybe do things like tell upstream
what's going on with the Debian package? Perhaps send a mail saying
something like:
It has been pointed out to me in bug #xxxxx that your email from
your sister has a license statement on it[1] that allows
verbatim copying only. Debian, however, can not distribute
things that do not follow our Free Software guidelines, the
DFSG. Could you please allow that email to be used under the
same terms as the rest of the package, or possible [whatever].
If not, I'll put in a statement briefly summarizing the message,
and link it to [the copy on your website/wherever]
> Urkle. response: "well put it back
> with the stipulation that anyone can edit it a little to make
> their own heart-rending email. Then i will put it back and not
> change it but other people might." Yeah right. It's his dead
> sister dude!
Hmmm, come to think of it, under modern copyright law, the author of an
email message has copyright over it. Most likely his sister did not
assign copyright, or grant him a license to redistribute that email. So,
actually, IT'S ILLEGAL FOR US TO DISTRIBUTE IT.
>
> + many patch files would be incompatible, and we'd have to deal
> with these manually all the time.
What? I thought we were talking about snippets here?
>
> - the problems with double standards
>
> + if we remove snippets (ie consider them dingleberries) whenever
> we find them, then some will be removed and others won't. This
> will engender a sense in people that we hold different upstream
> sources to different standards.
What? When we find problems, we fix them. That's a single standard.
Ideally, we'd find and remove every one, we'd confirm the licensing on
every line of code and documentation; on every pixel of every graphic;
on every second of every sound; etc. Practically, we have nowhere near
the time to do that!
It's the same standard we use with _every_ bug. No one expects us to
audit every line of code looking for bugs. The fact that dpkg has more
people testing it, and thus more bugs reported, than dadadodo isn't a
"double standard."
<snip silly slippery slope argument>
> + as a natural human tendency, when snippets are removed from a
> package the people who put them in will get *pissed* about it.
> One common way of responding to a perception of being a victim
> of a double standard (correct perception in this case) is to try
> to apply the standard to others in revenge, ie to level the
> field. Result: snippet-wars, with people looking for snippets
> in packages to complain about, as a matter of revenge/symmetry.
Good! Can we have bug-finding wars, or, even better, bug-fixing wars
while we're at it?
FOOTNOTES:
1. Really? How many emails from dead sisters come with licensing
statements?
Attachment:
signature.asc
Description: This is a digitally signed message part