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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
