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

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)



On Fri, Jan 18, 2008 at 12:34:42PM +1000, Anthony Towns wrote:
> On Wed, Jan 16, 2008 at 12:18:30PM +0100, Adeodato Sim?? wrote:
> > Currently, when having discussions about improvements to Debian, it is
> > not always clear when consensus has been reached, and people willing to
> > implement it may start too early, [...]
> 
> 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.

If people want to do this, it's useful.  The problem that is described
is that people don't actually want to do this, because they don't know
if their solution will be used.  For such situations, it is useful to
have a way to see that there is a rough consensus.

Obviously this doesn't guarantee that the work is used, but it improves
chances, which may be enough to just go and do it.

> > Secondly, we lack at the moment a central index in which to list such
> > proposals, which would be useful to see at a glance what open fronts
> > there are at a given moment in Debian, [...]
> 
> bugs.debian.org/ gives us a central index of ways in which Debian should
> be improving, along with all of:

Not the sort of things that DEPs are proposed for IMO.  Or at least it
isn't used as such.  For example, the machine-parsable copyright thing
seems (to me) to be pretty much accepted as a Good Thing, but it's
unclear when it would be a good idea to start suggesting or even
mandating it in policy.

> > and who is taking care of them
> > and, additionally, to serve as a storage place for successfully
> > completed proposals, documenting the outcome of the discussion and the
> > details of the implementation.

Also, I disagree that the BTS is a usable "storage place" for completed
proposals.  Or do you suggest to keep a bug open for things which we
have consensus on?  It would of course be an option, but I like bugs to
be closed, personally.  And IME they are much harder to find when they
are, which makes the system less useful as an archive.

> > Workflow
> > --------
> > A "Debian enhancement" can be pretty much any change to Debian,
> > technical or otherwise. Examples of situations when the DEP process
> > might be or might have been used include:
> 
> > * Introducing new debian/control fields (Homepage, Vcs-*).
> > * Making debian/copyright be machine parseable.
> > * Agreeing upon a meta-package name or virtual package name.
> 
> These sorts of issues are already tracked with the BTS, for instance when
> they're dealt with by the tech-ctte or -policy.

Right.  The BTS is one place where these things can happen.  In other
cases, other places are used, for example wiki.debian.org, or mailing
lists.  The proposal is as non-invasive as possible and leaves all these
options open.  Implementors can just use whatever they want.  That's
good, because some people will not like the BTS as a medium for this
sort of thing.  The fact that it can do it is irrelevant.  If people
don't like it, they might hold off working on things.  I would prefer to
avoid that.

> Is it really a good idea to merge "this is how we run our distribution" and
> "this is how we organise our project" ?

IMO it's fine to use the same process for it (especially because with
this process, we can continue to do things the way we did them before),
but I agree that the actual archive might be split with a section for
each.

> > The result of all this is:
> >   1. an implementation of the enhancement and
> 
> That's kind of implied by any process that results in changes happening...

Still quite important, because without it the proposal would be
worthless. ;-)

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

Are you suggesting that each new feature must be implemented by one
person (or a small team with lots of communication), and they can then
present the idea including a full implementation with documentation?
That doesn't really sound like how things usually work in Debian.
Normally, IME, people have ideas, people talk about them, there may be
some implementations of solutions, which get changed, and maybe at some
point things are implemented somehow.  All this is fine, except that
during the process, you can't see where you are, and at the end, people
may "forget" to write proper documentation about it.  Both these
problems are solved by the proposal, without forcing much policy on the
implementors.

> In so far as a DEP is about tracking a feature request, the BTS seems the
> right way to handle it.

No, that would be _a_ right way.  The whole point of DEPs is to not
mandate such a thing.

> >   * 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 the issue is about a single package, then the maintainer can
obviously do that (or accept a solution from someone else).  Also, I
agree with you that the BTS is the proper place for feature requests
which affect only one package.  I understood this proposal to be about
bigger things, which may require mass bug reporting, or changes in
policy, for example.  There is no single maintainer in a position to
just accept it for those.

> Is there any reason to go with all the overhead of this proposal, rather
> than just managing the general/project pseudopackages in the BTS along
> the lines suggested for DEPs -- eg, actually closing old proposals and
> making sure current proposals are actually going somewhere?

Yes.  That people may not want to use the BTS for these things.  In many
current cases, the BTS isn't how we do things.  Your solution seems to
be "force people to use the BTS for it".  DEPs propose as a solution
"keep doing things the way you always did, but document them".  I prefer
the latter.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: