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.
> 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?
> > 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.
> 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, not an issue with
the BTS.
> 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.
> 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:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=yes;package=project
http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;package=project
> 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.
> 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.
> > > 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.
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?
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.
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."
> 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.
> > 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?
> > > * 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
> Also, I
> agree with you that the BTS is the proper place for feature requests
> which affect only one package.
For feature requests that affect multiple packages the BTS supports
cloning bugs to other packages, blocking tracking to indicate when
related bugs are fixed, and usertags to index them across packages.
> 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.
> > 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" ?
> 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. Individual packages,
installer issues, policy, tech-ctte, ... It's *already* there for
tracking issues, and it's already setup for project wide issues, even
if it's not being used for that currently. Why is it being reinvented?
> 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."
If you've already decided you want to invent your own system, or just
want to start from #0 instead of about #461390, I guess that's fine,
but it seems a bit silly to me.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature