[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 07:33:41PM +1000, Anthony Towns wrote:
> On Fri, Jan 18, 2008 at 09:12:53AM +0100, Bas Wijnen wrote:
> > 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.  
> 
> That seems a pretty bad rationale -- implementing your solution (demoing,
> prototyping, whatever) is a first step in convincing people your idea's
> good, not something you do after everyone agrees with you.

It depends on what the idea is.  How about the social committee thing.
AFAIK it's discussed here on -project, but I have no idea what the
current status is.  I think it's something like "we want it, we don't
really know how exactly, we also don't know how to elect them".  If
there would be a central document where the current state with respect
to this is recorded, that would be nice.

Also, in case of a long discussion, the BTS isn't really that good a
tool.  The bug log would get enourmous, and people who want to know "the
current state" and are not interested in the history don't want to read
through the entire log.

That's the sort of thing that is solved here: there should be an url
where people can check how the current proposal is, with a link to the
place to discuss it.  That link can very well point to the BTS if the
drivers want it to.  But let's not force them to do that.  If they
prefer discussing on a mailing list, allow them to do that.  It's all
about "let people do what they want, the way they want it, and if others
like it, let them use it".

> > Obviously this doesn't guarantee that the work is used, but it improves
> > chances, which may be enough to just go and do it.
> 
> Sure, getting a second opinion before starting is useful; but you'd do
> that before a DEP anyway?

You'd probably do that a little bit before a DEP, but mostly during the
DRAFT phase, I suppose.  Such as in this case (DEP0), nobody has yet
written anything to deal out the numbers.  I proposed to do it, but I'll
wait to see if we're actually going to do anything like this.  If not,
I'd be wasting my time.

> > > 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.  
> 
> It certainly has been in the past.
> 
> Reasons to use it again would be: it already exists, it integrates well
> with lots of other things we do in Debian.
> 
> Reasons not to use it would be that it doesn't do something that's needed.

I'm not saying (and AFAICS DEP0 isn't either) that we _shouldn't_ use
the BTS.  I'm only saying we shouldn't _mandate_ it.  I like that
approach very much.  Things work pretty well now.  People do things the
way they like.  Some parts could be improved, in particular related to
tracking the current state of an issue and having a document when it's
final.  That's what DEP0 is adding.  And it does this elegantly, without
forcing a new (or old) system on people.

> > 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.
> 
> Well, that's an issue with how -policy is working,

No, it isn't.  Changes in policy shouldn't be made unless there is
consensus that it's a good idea.  We're still at the state that we want
to know if there's consensus.  In this case, proposing a policy change
should not happen before the DEP has at least become CANDIDATE (assuming
that the drivers choose to use the DEP system for it).

> not an issue with the BTS.

No, there isn't an issue with the BTS, as you described it is very
capable of being a medium for discussing a topic.  If it's used for
that, it can even do most thing (if not all) that DEP0 wants to make
sure are always done.  But if someone wants to discuss on a wiki, or a
mailinglist, then that should be possible, too.

Remember that the drivers can choose to ignore the DEP system
completely.  If you want to propose something and use the BTS to track
it, nothing is stopping you.  The DEP system is only intended to provide
you with a way of organising things, not to force it on you.  Since DEPs
have no formal meaning (in that things which are in a DEP can't be used
to tell people "what you do wrong, and you must change it", like a GR or
policy can), there's really nothing terrible happening.

> > Also, I disagree that the BTS is a usable "storage place" for completed
> > proposals.  [...]
> 
> bugs.debian.org/100000 is a much more reliable reference for a closed
> report than most wikis, or even mailing lists.

Yes, it's reliable, but not very usable. :-)  The DEP storage should
obviously also be reliable, and for that reason it's using the unique
numbers.  I'm not saying it's more reliable than the BTS.  It's as
reliable.  This is not the reason to use DEPs, it's just not a reason
not to. :-)

> > And IME they are much harder to find when they
> > are, which makes the system less useful as an archive.
> 
> That's mostly because people tend not to look through old bugs. They're
> certainly searchable, eg:

I know, but it doesn't look nice.  Of course another option would be to
use usertags and create some extra web pages so you can simply click on
links.  But that also doesn't exist yet, and if we're building new
things, I prefer to do them the best way possible.  And DEP does have
advantages over the BTS IMO.

> > Right.  The BTS is one place where these things can happen.  
> 
> The BTS is a *tracking* system -- it helps you keep track of where a
> bug fix is up to. If you're wanting to track feature requests (which is
> what the states and unique id assignment is about), then the BTS is a
> useful tool.

Ehm, yes.  That's what I said, it's a proper tool for the job...

> > 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. 
> 
> If you leave all options open, you're not doing anything.

Oh, but you are.  DEP0 nicely summarizes what it intends to do: Make
sure things get done (as opposed to being ignored because nobody knows
if it's time to move on yet) and make sure that there is a document
describing how it's done when it's done.

It doesn't describe how to do things, and that's intentional.  Let
people who want to do thing choose their own method.

> > > >   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?
> 
> Huh? I've no idea where you'd get that from.

I got it from the line I quoted.  There seems to magically be maintained
documentation when a feature is implemented.  Perhaps you expected this
to happen when nobody really knows who does what, but I thought you were
talking about a person doing something and documenting it.  For that
case, I can see that it works fine.  For bigger plans, someone needs to
write down what the idea is, and others have to agree with it.  When
starting such a plan, I don't expect any "maintained documentation" to
exist.

DEP0 is exactly about creating it.  After that, it can be used, of
course.

> If you have documentation that describes what was originally proposed,
> but not what was implemented, let alone changes that've been made since,
> what's so great about it?

That's not the idea. :-)  As long as things are being implemented, the
DEP isn't going to be ACCEPTED, so it can still change.  If things were
good, but changes are made anyway, there's a mechanism to supersede them
with a new DEP.  In other words, they are (or at least can be)
maintained.

> For example, if a proposal for changing debconf travel funding was made,
> what's the great advantage of having the original proposal, when it will
> have almost certainly changed as soon as it's actually tried, and will have
> changed further later.

It will not be ACCEPTED before it's tried, I'm sure.  You seem to think
that ACCEPTED DEPs have some formal meaning that they have to be
followed, while DRAFT or CANDIDATE DEPs may not be followed yet.  This
is not the case at all: DEPs are purely informational.  If the Debconf
organisers like the idea in a DRAFT DEP, they can implement it.  Or they
can implement it with some changes (which can then be put in the DEP if
they turn out to be good).

And if these things need other changes in policy, or in SPI matters, or
a statement from the DPL, or whatever, then having an ACCEPTED DEP is
not a replacement for that.

> Another example. The original proposal (well, one of them) for the current
> new maintainer process, was
> 
>     http://lists.debian.org/debian-project/1999/10/msg00003.html
> 
> But the current documentation for the n-m process is
> 
>     http://www.debian.org/devel/join/newmaint
> 
> The original discussions are interesting for historical reasons, but I'm
> not seeing what the win is in having "a document that can be referred
> to later on without having to dig up and read through large discussions."

The DEP that would be produced in this case would be the second link,
not the first one.  The first one would be the DRAFT initial proposal,
which is to be discussed.

And even after it's ACCEPTED, it's still not unchangable.  A new DEP can
be proposed (or if front desk wants, they can just do things
differently).

> > 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.
> 
> It's not writing documentation in the first place that's hard; it's
> writing it so it's useful for the people who'll use it (not the people
> who're implementing it), and keeping it up to date as changes are made.

For things which keep changing, DEPs shouldn't be used.  For things
which have some (semi-)final state, the DEP is only ACCEPTED when it has
reached that state.

> > > 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.
> 
> It's instead mandating deps.debian.net for indexing, a new rfc822 format,
> a bunch of manually managed states, posts to lists to manually claim a
> number, all of which we already have a tool for?

Yes.  That's not a lot, really.  You're suggesting to force people who
have a proposal to discuss it on the BTS.  That sounds a lot more
invasive to me.  Perhaps a bit less work to implement, but the result is
also much less pleasant IMO.

> > > >   * 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).  
> 
> Supposedly DEPs aren't changing who decides anything -- if there isn't a
> single maintainer, the same collection of maintainers still get to decide.
> If all of them happen to think it's a good idea, they can still do it
> straight away. If some of them do, they can too. For instance, see the
> responses to:
> 
>     http://lists.debian.org/debian-devel/2008/01/msg00612.html

This is an excellent example of why the BTS is not the right tool for
the problem DEPs are solving.  This is a huge pile of e-mail, where I
cannot see the start or end.  There doesn't seem to be a summary about
anything.  There probably was a discussion about this on -devel, but it
isn't referenced...  Or is this mail itself the entire discussion?

I suppose you mean that when individual maintainers are notified about
a problem in their package, they usually solve it.  That is a good
thing.  But it's not what DEPs are about.  DEPs are about reaching the
point that this e-mail can be sent.  Finding out that we do actually
consider this a bug, and that we want it fixed.  For this case, there
appearantly wasn't a lot of discussion about that.  But if there is, and
there's no good way of knowing if there is consensus, the solution may
never be implemented.

> > 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.
> 
> Changes in policy are already done via bugs against the policy
> package.  Mass bug reporting is obviously already done via the BTS.

It's about reaching the point that the proposal can be accepted, not
about making the proposal.

> > > Is there any reason to go with all the overhead of this proposal, rather
> > > than just managing the general/project pseudopackages in the BTS [...]
> > Yes.  That people may not want to use the BTS for these things.  
> 
> Uh, "We don't want to use the BTS because people might not want to use
> the BTS" ?

Yes.  If some people may not want to use it, we shouldn't mandate it's
use.  People are free to use it, they're just not forced to use it.

> > In many current cases, the BTS isn't how we do things.
> 
> Uh, what I'm saying is it *is* the way we do things. [...] even if
> it's not being used for that currently.

It seems you're contradicting yourself here...

Sure we're using the BTS for things.  But not for all things, and AFAICS
not for most things that DEPs would be useful for.  We can use it for
those things as well, but why should we force people to do so if they
prefer other ways?

> Why is it being reinvented?

To allow people to do things (almost) the way they always did them.

> > Your solution seems to be "force people to use the BTS for it".  
> 
> Uh, no. I'm saying "The BTS is already there -- if you want to do this
> stuff, use the BTS for it." 

What's the difference?

> If you've already decided you want to invent your own system,

Oh no, it's not decided at all.  I'm not convinced by you, but if many
others are, this isn't going to happen I suppose.  That's why we're
discussing it. ;-)

That's how it should work with other DEPs as well: as long as they're
DRAFT, they can change, and be REJECTED.

> or just want to start from #0 instead of about #461390,

That is a nice feature IMO, yes.  I suppose some of the DEPs will be
used like RFCs and 6-digit numbers are very hard to remember.

> I guess that's fine, but it seems a bit silly to me.

I don't have a problem with that. :-)  The whole point of the proposal
is to allow people to do things however they want to do them (including
ignoring the proposal).

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: