On Sun, Jul 30, 2006 at 08:06:51AM +0200, Martin Schulze wrote: > > (a) they'll listen to their users and do their best to incorporate > > that input in future releases > > (b) they'll cooperate with the free software community, both > > in making every effort to make any free software they write > > easy to include in other products, and in complying with > > the licenses of the free software they use and distribute > I wonder if it's only me who is missing several pieces: So what would it look like if you added them? > No link to the Debian Bug Tracking system. For example "(c) Should link to bugs.debian.org" wouldn't really be a very useful requirement. The other complication is that generally we want people to look after bugs in derived distributions themselves first, and only forward them to us (or upstream in general) when they've checked to see it's not a bug they've introduced in their derivative (by using different kernels, libraries, packaging, etc). My suspicion is we'll end up with a much more satisfactory result if we look at external bug trackers ourselves (as per [0]) rather than expecting derivatives (or their users) to meet our standards for reporting and resolving bugs. > No mention to work together with the Debian maintainer. I don't think that should be a requirement; particularly if it's a one person derivative who's making changes to many packages on their own. > No mention to discuss development aspects on Debian mailing lists. Development that's not happening in Debian is off-topic for most of those lists. Cf the response to [1]. That said, I'd like to see /something/ of this nature -- it would be really nice for there to be some reasonable way of following the changes derivatives make without having to essentially be a developer of the derivative. Maybe some combination of Planet <Derivative> or <Derivative> Weekly News or patch archives like Scott James Remnant does for Ubuntu, or something would make sense; but it will likely have to vary depending on, at least, the scope of the derivative -- having all those things is probably legitimate to expect of something as large as Linspire, or as popular as Knoppix, but probably not to expect of Damn Small Linux. It's also possible that there isn't a good answer on this score yet, and it'll just be something we have to revise later when we work out a good way of doing it. > No mention about making incompatible changes that will result in the > derivate becoming incompatible with its root. Of course not, that's a fundamental right of all free software licenses. For comparison, Debian GNU/Hurd and Debian GNU/Linux are more "incompatible" than Debian i386 and Ubuntu i386, afaics, eg. > No mention to let patches flow back into Debian or the Free Software > community via official means (i.e. BTS, mailing lists). Cf the BTS/development stuff above. > No mention to not use steganographic means to hide real patches in > loads of changes that affect what the world knows as branding. Steganography is an entirely different thing to just collating unrelated changes. But "making every effort to make any free software they write easy to include in other products" was meant to cover both those cases anyway. > No mention that the derivate should (really should, pretty please) > stay to its roots, i.e. Debian and promote Debian. Just using the Debian brand is already promoting Debian, afaics. > No mention that the derivate should link to the Debian website (only > vice versa). That's easy to add; but doesn't seem all that interesting... We're already pretty easy to find, aren't we? We're certainly already linked from [2], and we could pretty easily provide the logo with a recommended place to link to when using it on your website. Cheers, aj [0] http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html [1] http://lists.debian.org/debian-devel-announce/2006/01/msg00008.html [2] http://www.ubuntu.com/ubuntu/relationship
Attachment:
signature.asc
Description: Digital signature