Heya, As I'm one of the people who have at some point volunteered to help with the dev-ref, but mostly failed to actually do work, I guess I could say a few words, without any pretense of actually knowing better than all the other people who have already commented... Lucas Nussbaum <lucas@lucas-nussbaum.net> writes: > OK, let's try to change the way it is maintained by moving to something > similar to policy. Several questions need to be addressed. > > - Where should discussions occur? Should we re-use debian-policy@, since > both documents are a bit related? Or use another list? I would > personally prefer to use another list (-policy@ is already quite > busy), but I could be convinced to use -policy@. I think moving discussions to -policy is a good idea, as these discussion sometimes decide whether a specific change is implemented in policy or dev-ref. > Developers Reference gathers several kinds of information: > > (A) Purely informational documentation of Debian infrastructure and procedures. > This is the easiest kind of content. Once correctness has been verified, > not much debate can happen about the information. Should such information actually be part of the developers reference? It seems this could easily be moved onto www. or wiki.debian.org. > (B) Best practices about Debian packaging > This is harder to handle, but it isn't normative: maintainers are free > to do things differently: besides raising a few eyebrows, nothing will > happen. If something about developers-reference sounds normative, it's > a mistake and should be moved to debian-policy. > > (C) Policy-like information about some procedures > This is the hardest part. The developers-reference documents some > processes that are not standardized by Debian policy, because they are > not related to Debian packaging. An example of such processes is the NMU > procedure. Not following those procedures correctly is likely to result in > complaints from other maintainers. I've checked the current dev-ref and had quite a few problems to decide to which of the two categories the current content belongs. Handling (B) like (C) seems not too problematic. If (A) is moved out of dev-ref, this would give a simple, coherent change process completly analogous to policy. Marc -- BOFH #240: Too many little pins on CPU confusing it, bend back and forth until 10-20-- are neatly removed. Do _not_ leave metal bits visible!
Attachment:
pgpeJUDDWXmrk.pgp
Description: PGP signature