[Please continue to CC me on any replies.] Raphael Hertzog <[EMAIL PROTECTED]> writes:
> Le Tue, Apr 30, 2002 at 02:24:14PM +0900, Junichi Uekawa écrivait: > > I was hoping to get libpkg-guide (library packaging guide) into > > Developers Reference, although the terms and language is quite > > different. > > Agreed ... it fits well within "Debian Best Packaging Practices". Ok, I'll take a look. Sounds fine to me. Do we want to adapt it to fit into the terminology of the DDR or just cram it into a chapter? Junichi, are you able to work on integrating it or should I seek another party for that? On to the content additions... I'm going to cover the little points there with speculation on the priority. - Debian Best Packaging Practices This item is vague. I assume we're talking about tips and developer materials not contained in policy? Anyhow, I have to wonder what exact bits have been identified which should be added, and also, whether anyone volunteers... Some ideas: Charles Briscoe-Smith used to have some maintainer script boilerplates which were very useful. I think this is more of an ongoing issue rather than a milestone we can hit. - Collaborative Maintenance of Packages [1] This is a high priority item, represents not too much text, and should be pretty easy to fit in. - Going further than simple maintainer [1] I would just call this "Other Tasks You Can Do". Assume this is a pretty small chapter. Is this high priority? - the content mentionned in the bug reports Yes, the various and sundry. Some easy and some hard. I'd like to add a chapter: - working with the upstream maintainers I think there's a whole best practices of working with the upstream maintainer that needs to be written. Talking about when to fork and when not to fork -- when to patch a bug in your package, and when to wait for the new upstream version. Also included in this would be a document that upstream maintainers can read so they know what their reasonable expectations should be, and where to go for help if the debian package maintainer for their software is misbehaving. I think this document would help Debian's reputation among free software developers -- which sometimes is not great for our flagrant forking and such. I wish I could work on only this until I was done, leaving the other bits to other co-maintainers. Unfortunately I do not yet have any other co-maintainers -- volunteers, anyone? Again, [1] == <URL:http://lists.debian.org/debian-qa/2002/debian-qa-200201/msg00062.html> -- ...Adam Di Carlo..<[EMAIL PROTECTED]>...<URL:http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
