On 07/09/09 at 16:01 -0700, Steve Langasek wrote: > One thing I didn't say before is that, /in theory/, I'm willing to help with > maintenance of the devref package if the problem of public-by-default change > process is addressed. I didn't mention this because I don't want to mislead > anyone into thinking I'm committing to being active on the package - rather, > every time I've thought of volunteering to help with the devref (which I > agree is an important document), the lack of public process has been a > blocker for me. While the people who've maintained the devref over the > years are developers whose technical judgement I have a good deal of > confidence in individually, when it comes to deciding "best practices", it's > just too small and self-selecting a set and I'm not willing to be seen as > endorsing this model by putting my own name on it.
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 -pol...@. - Fresh blood for the dev-ref maintainers (even if the process gets more public, there will still be a need for people to coordinate discussions). I think that we need at least one more maintainer for dev-ref (two would be better). I'm not very motivated by working on dev-ref, so I might not be involved for too long. Who wants to help? - Changes process. The policy one (http://wiki.debian.org/PolicyChangesProcess) is too complex and inadequate for dev-ref. I'm proposing the following documentation for the process: <----- 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. (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. Due to the different kinds of content in developers-reference, it is difficult to have a single process that would work fine for everything. For (A) and (B), once a proposal has been made, has been seconded by at least one DD, and some time (e.g one week) has passed to give others the chance to voice their concerns, the change can be made. For (C), non-editorial changes should be discussed more widely (on -devel@ or -project@), and consensus should be ensured before going forward. --------> Comments? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
