[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

> 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?


> > 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.

Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :

Reply to: