Apologies for the delay in this reply.
Before doing so I think we can summarize the state of the affairs as:
- most of the people who commented on DEP0 agrees with the usefulness of
this new tool
- however, there are some technical objections, the most notably
objection seems to me Anthony's about using the BTS instead of the
structure we initially proposed
I first comment on why, in general, I don't think the BTS is the right
tool for managing DEPs, then I will reply point-by-point to Anthony's
comments which are not related to the BTS.
I do think that a pseudo package in the BTS would serve us well in
showing the states of the various DEPs. As a minor problem with that, I
won't like the intrinsic description that the BTS bug listing page would
give: for example accepted DEPs would (I guess) appear as Closed, while
I would like to see them as accepted. This and similar minor
presentation problems I have can probably be solved with carefully tag
naming, but on the other hand won't exist at all in a simple web page
created to the DEP end. (As an intermediate solution one can consider
using the BTS and presenting its content differently in a separate web
page, generated using the SOAP API or something on these lines.)
On the contrary, I don't think that the bug log page (i.e. the per bug
page) of the BTS would be satisfactory for showing the status of a
single DEP. The reason is that the bug log page is meant to be a *log*
i.e. to show all the historical evolutions of a bug. When first seeing a
DEP I want to see the current status, that is a document incarnating all
the changes which have been proposed thus far. Then, I want the
possibility to show the history of changes, but first of all I want to
see the current status. In this sense a wiki page or a version control
system is much more up to the task then the BTS.
If you want evidence of that I can provide pointers to bug report I have
in mind, for example about proposed policy changes, where before being
able to understand what the *current* status is one have to spend a lot
of time, digging into attached patches, patches changing previous
patches et al.
Note how the proposed "summary" feature addition to the BTS would solve
the state overview problem, but would not solve this, ... unless of
course you are welcome to accept that a summary is a full page. And even
in that case, the architecture we have initially proposed is ready to be
used, while this would require changes to the BTS which are not yet in
place.
On Fri, Jan 18, 2008 at 12:34:42PM +1000, Anthony Towns wrote:
> Isn't it useful to have sample implementations before trying to decide
> whether an idea is good or not? PEPs often seem to have patches for
> the feature they're suggesting, before they're accepted.
Yes, and DEPs do not forbid to have an implementation since the
beginning, should they? After all the DEP can't move to the ACCEPTED
state until an implementation is available, so I don't think any arm is
done in postponing to a second stage the implementation availability
requirement.
> > * Deciding on a procedure for the Debconf team for assigning travel
> > sponsorship money.
> > * Formalizing existing informal processes or procedures, e.g.,
> > the procedure for getting a new architecture added to the archive, or
> > getting access to piatti.debian.org to run QA tests.
> Is it really a good idea to merge "this is how we run our distribution" and
> "this is how we organise our project" ?
Not necessarily. But DEP will be a tool: to use it for what is a choice
up to any potential driver. I don't think we need to rule this
possibility out since the beginning.
> > 2. a document that can be referred to later on without having to dig
> > up and read through large discussions.
> What's the benefit of this, as distinct from maintained documentation
> that's distributed with the feature?
The benefit is having a central point which collect on one hand the
historical evolution of the proposal, on the other all the (pointers to)
resources which affected its evolution. Can you ATM find out in the
developer's reference the discussions or blog posts we had about Vcs-*
fields? I can't, and that's why we use wiki pages for that. DEP will
simply make official a point where to store such kind of information.
> > * this period must be long enough that there is a consensus that the
> > enhancement works (on the basis of implementation evaluation)
> Adding delays seems to contradict the previous notes about DEPs not
> changing who gets to make decisions -- if it takes five minutes for the
> maintainer of a package to say "omg, what a great idea", why shouldn't
> it be implemented immediately?
If it only takes 5 minutes for a single maintainer to implement
something, then a DEP isn't probably needed at all, is it?
> You could handle this the same way, or include the latest draft inline
> or as an attachment.
To stress this point: still, the random reader need to walk through the
whole bug log before finding it. IOW I find the BTS prone to excessive
flooding of posts whereas I want per-DEP pages to be immediate to grasp
for the occasional surfer.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the
(15:57:15) Bac: no, la demo scema \/ right keys at the right time
Attachment:
signature.asc
Description: Digital signature