Re: Update #1 [RFC: Introducing Debian Enhancement Proposals (DEPs)]
On Wed, 16 Jan 2008, Adeodato Simó wrote:
> 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.)
Thanks for the follow up.
> 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.
d-d-a may not be needed, but at the very least, one should announce
far-reaching DEP that are about to reach CANDIDATE status on a generic
list, either -devel for technical stuff or -project for non-technical
stuff.
Very specific list are good for drafting, but they are not always good
enough for getting wide review.
> (²) And this mail it's just there as a very unbureaucratic and light
> mechanism for obtaining a DEP number.
Why can't we manage the DEP list just like the rest in a VCS ? A VCS
commit is atomic. :)
Posting a mail to get a number is not an adequate process IMO. Or are we
supposed to post a first draft without number and get the number
afterwards?
> 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:
>
> 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.
That looks sensible. In that case, it would be nice if the ikiwiki setup
would provide a link to the commit log of the associated file. This would
(sometimes) avoid the need to tell people to add a link to it inside the
DEP itself.
> 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?
Good!
> > 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.
I tend to agree. This is the kind of stuff that we can fine-tune when we
start having "historical" DEP, but it makes sense to me.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: