Re: State of developers-reference
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 -policy@.
- 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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: