On Mon, Aug 02, 2004 at 11:23:37PM -0500, Joe Wreschnig wrote: > > opinions aren't going to work for policy. For non-program files such as > > multimedia or publications, there should be a master list of MIME types > > and a voted-on list of acceptable source code formats for each MIME > > type, in the case that upstream does not certify that the file was > > created as-is from scratch (example: capturing directly via hardware or > > via a software filter to a MPEG-4 or Vorbis file). > > This is insane. Do you want to vote for every MIME type (I'm curious if > you know how many there are)? What's the source for > application/octet-stream? What if the original source is outright gone?
Read please, I said non-program files. The list of MIME types would correspond to actual media files which are present in Debian packages. What would be the point of extending the proposal to every MIME type in the world, besides to try to shoot it down? > (Oh, and this 40MB application/postscript? Upstream wrote it by hand. > Really. Just like this 4MB application/x-executable.) If upstream says he wrote it by hand, are you going to call him a liar? > Have you thought about your proposal at all? If you have, I'll be more > scared than if you haven't. Oh, chill out. In fact, it's been the most reasonable conclusion of various local heated discussions that manages to satisfy almost everybody involved. Please be aware that there are other people with brain cells besides those who participate on this list. > > It's a matter of practicality, and should be up to the package > > maintainer, with policy such as described above to decide borderline cases. > > If the package maintainer makes a bad/impractical decision regarding the > > source > > format, nobody is going to host his package for download. So it ends up > > being a Darwinian filter. > > If we go with a "if people download it, it's preferred" then we can > include an awful lot of non-free software. Again, re-read what I said. The people whose machines, network connections, and hard drive space are in jeopardy by hosting these packages are going to have the final say in any decision of this sort. > I agree a lot of it should fall to the package maintainer, but that's > because she better understands upstream's work habits and preferences, > and what kind of ways people might want to modify the software, than > J. Random DD. Of course. And the package maintainer knows exactly how the file was created, in the case the validity of the currently provided source is ever called into question. > I think we're sane enough to work towards a definition of "source" that > will do the right thing for all formats when interpreted by humans. Go ahead. I've seen a lot of people try and get shot down mercilessly. > I also think that the GPL's is a very good place to start, and I think > most everyone agrees with me on this point. Compiling software can be thought of as a lossy conversion process. The difference between this is that the compiled object code frequently ends up being larger than the source code, if not the same size. This cannot be said for lossy compression on media files, which typically shaves orders of magnitude off the raw source. Again, it's a practicality thing. > But your idea, and criteria, are stupid. Fine, however, your short-tempered and ill-prepared condemnation has even less merit than any half baked idea I could post here. -- Ryan Underwood, <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
