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