OK, thanks all for your encouraging feedback so far! For driving this
discussion, I think it's going to work best if I manage to make regular
updates of the status of the discussion, like this one. As in,
mentioning the actions I'm taking based on feedback, and summarizing the
discussion so far on "open fronts". This should also be a good entry
point to the thread. (If somebody things this way of doing has its
drawbacks, please do speak.)
Handling of d-d-a (possibly closed front)
-----------------
We got several comments about this. I agree with the general feeling
that drafts should not be (separately) announced on d-d-a: discussion
should be fostered in the normal Debian way, by starting threads on
mailing lists, blogging, Debconf talks, etc. (¹) I like Raphael's idea,
though, of using the DeveloperNews initiative to include a paragraph
mentioning creation, and else, of DEPs, so I will try to update that
wiki page when needed.
Additionally, and to address Andreas Tille's concern about DEP0 itself,
I will send a mail to d-d-a once we polish this draft and move it to
CANDIDATE, signaling that people are encouraged to try it out, even if
they haven't been following the discussion on -project.
Finally, Frans Pop raises a couple good points: I agree that when
sending a mail to -project creating one's DEP (²), it would be very good
to include a pointer to where the discussion is happening (with a link
to the thread), or where is going to happen. I've amended the "Creating
a DEP" section to say that in [my branch][].
Secondly, the fact that certain proposals, particularly far reaching
ones, should really be sent to d-d-a to draw attention of the whole
community. The exact point when to do that is tricky, because you want
to send something that is close to a final draft, but not too late so
that it doesn't feel like redoing it all again if valid concerns are
raised.
In any case, I will make a note about this, and add a sentence, when
talking about the draft state, that says something that one should take
care of signaling all possible interested parties of the ongoing effort.
(¹) Of course, developers that are driving a DEP *could* decide that
mailing d-d-a could be good for a particular case, but that'd be their
own decision.
(²) And this mail it's just there as a very unbureaucratic and light
mechanism for obtaining a DEP number.
[my branch]: http://bzr.debian.org/dep/dep0/dep0.dato
History of changes, and VCSen in general (open front)
----------------------------------------
Lucas Nussbaum suggests that the document includes "A history of changes
made to the DEP, with their rationale, or links to emails explaining
giving it". I think that would pollute the document much, but I think we
can divide the issue in three aspects, and solve the issue by addressing
them separately:
1. suggest that each DEP contains a rough changelog/timeline, like:
| 2008-YY-ZZ
|
| * Moving to CANDIDATE. Document sent to d-d-a.
|
| 2008-01-16 to 2008-01-XX
|
| * Changes based on feedback from -project.
|
| 2008-01-09 to 2008-01-15
|
| * Changes based on feedback from various people.
|
| 2007-12-01
|
| * Initial draft from the Extremadura QA Meeting.
2. recommend that DEPs include references to archives of dicussions
(this is already done)
3. finally, about documenting the individual changes themselves, I
believe they more belong to the commit messages of whatever version
control system (or wiki page) the drivers are using.
I wanted to add a note somewhere mentioning that using a VCS is a
good idea, and we could mention there that it would be good
practice to document changes with their rationale and/or links to
the relevant messages.
Then, I also feel that if a VCS is used, a pointer to it should be
given in the document, and maybe suggest, in the History section,
an URL of the changelog view of the file. How does that sound?
Other
-----
* Michael Bank says:
> Did you consider moving dep.d.n over to wiki.debian.org once that is
> run by ikiwiki and DEPs are common practise?
Yes, we talked about this in Extremadura: we too feel it would be good
to move this to www.debian.org or wiki.debian.org once it becomes
widespread. We didn't know we'd be using ikiwiki at the time, so we'll
see how things go with respect to that.
* Bas Wijnen says:
> > As the discussion progresses, the enhancement is assigned certain
> > states, as explaned below.
> s/explaned/explained/
Fixed, thanks.
> Assuming that the number of DEPs will be significant, I think it would
> be a good idea to separate ACCEPTED DEPs into two groups, namely
> "historical" which nobody needs to read, because their text is included
> in some authorative document (policy, devref, whatever) and "current",
> which may be useful to read because they aren't included anywhere (DEP0
> will probably stay there, for example).
OK, this front remains open.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
It is by logic that we prove, but by intuition that we discover.
-- Henri Poincaré
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
