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
Re^4: ideas regarding a conflict management strategy
> > > I had reasons why I dont fill the pipe with E-Mails that contain 20 > > > pages long efforts if the expectation is pretty hostile feedback. > > As you can see, posting generalities didn't really fare much better. > Right - 20 pages of anything, from someone who doesn't appear to be > contributing to the community which he insists should change to his > standards, is not going to be particularly well-received. Steve Langasek, exactly that is a general misunderstanding of you and a few other Debian Developers. "I have three world-class operating system releases to my credit, and you dont" is cause for respect and fame, but it does not justify the attitude, that anybody else has no right to voice his opinion, if he cant show up with similar credit. Conciousness, awareness, understanding and practise of non-violent communication. The Debian Bug Tracking System is open, the developer and project lists are open, the entire structure is open. And this has a reason. It is exactly what makes Debian special and attractive compared to other distributions. But open structures also have their downsides compared to communities that are lead by companies. We see in real life every day how democratic processes are a real challenge to all involved people. Most of us are conscious about the fact that democracy is not a perfect system. But we are aware that it is the best mechanism available to keep huge groups of people together in a peaceful way. A few smart people with a good understanding of social ethics made up the Debian Social Contract. And one of the main points of this Debian Social Contract is "we will not hide problems" and "our priorities are our users". Thank you for keeping that in mind through all your actions. Some people obviously value tribalism much higher than the Debian Social Contract, when they went to attack "Patrick Frank" some months ago only because he was voicing a concern, that the current Debian Project Leader used defacements of other Debian Developers during his electoral compaign. And I am not making up this entire case again, just to cause another destructive flame war. Feel reminded on the electoral compaign lead in the US mass media between Hillary Clinton and Barack Obama: mud fighting instead of dealing with facts. And the reference to "Patrick Frank" was made up by you, Steve Langasek. When I have a look at this public conflict from that time around "Patrick Frank", then I come to the conclusion that "we will not hide problems" is not taken very serious. And observations of behaviour from Debian Developers on chat rooms on Internet Relay Chat from the last years show, that many people take "our priorities are our users" not very serious. A few smart people with a good understanding of social ethics made up the Debian Free Software Guidelines. And one of the main points of these Debian Free Software Guidelines is "No Discrimination". What is the point of making software that does not discriminate other people, but the behaviour of several Debian Developers does? Did you sign the Debian Social Contract and agree to the Debian Free Software Guidelines to get as much reputation as possible for being one of the best hackers, or do you enjoy giving people great tools so they can have the most benefit from using their computer? The Debian community is not about your ego and not about mine. Its about the desires of many people. To cover as many desires as possible is the main philosophy of Debian ever since. And exactly that was my point in my first E-Mails, when some people chose to try to give my name a bad reputation instead of dealing with the facts. Most of the Debian Developers need to get conscious about their own personality, the personality of other Debian Developers and the personality of all the people they have to deal with in general. I tried to explain why I am convinced about that requirement. GNU/Debian Linux is used and supported by companies like Hewlett Packard, Intel and many others. Shouldnt that create good self confidence for all the people who help to make GNU/Debian Linux what it is? Why do some people use that self confidence against small people like me, instead of trying to catch the message that I try to voice? The problems that I see and try to express are problems that are seen by other people, too. Some people deal with it in a different way. A really smart way of dealing with some of these problems of the Debian community was, when Mark Shuttleworth gave birth to the Ubuntu project. Much smarter people than me will write a book about his life sooner or later. So again, I dont aim to give a scienctific work here. But one of the reasons why Ubuntu catches much of the fame that would usually be due to the work of many Debian Developers is, that Mark Shuttlerworth was giving the Ubuntu community a clear and clean structure which is kept together by the company Cannonical. While many Debian Develo
Re: RFC: Introducing Debian Enhancement Proposals (DEPs)
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/10 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/msg3.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 t
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/10 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
Re: Re^4: ideas regarding a conflict management strategy
Hi, This is my first and only mail on this subject. > Subject: Re: Re^4: ideas regarding a conflict management strategy Why do you start new threads all the time? It breaks mutt's threaded view, and it makes sure that your message shows as a new thread. This also makes it impossible to ignore the rest of the thread without specifying that you really want to ignore it with every message from you. The only reason I can see for doing this, is that you want to make sure people don't ignore you, even if they want to. If that is indeed the intention, that makes you a spammer IMO. And thereby even less sympathetical. On Fri, Jan 18, 2008 at 10:02:12AM +0100, Lars Versen wrote: > > Right - 20 pages of anything, from someone who doesn't appear to be > > contributing to the community which he insists should change to his > > standards, is not going to be particularly well-received. > > Steve Langasek, exactly that is a general misunderstanding of you and > a few other Debian Developers. "I have three world-class operating > system releases to my credit, and you dont" is cause for respect and > fame, but it does not justify the attitude, that anybody else has no > right to voice his opinion, if he cant show up with similar credit. I can't show similar credit, and Steve doesn't do that to me. That's because I do actually do things in Debian. I wasn't release manager, and I'm not a maintainer of important packages, but I am active in the community, and do some things. The only thing I've seen from you is e-mails about how to change things. You are not listed as the maintainer of any package, I don't know you as someone who is active in translations or ports or infrastructure. In short, I don't know you at all. You seem to be a total outsider to the project. I fully agree with Steve: as an outsider, you should not expect positive responses to a proposal to radically change the project. (Although you didn't really do any proposal so far, you just mentioned some things nobody contested, and complained about being mistreated.) > Conciousness, awareness, understanding and practise of non-violent > communication. I'd like to add one: no useless communication. Please don't post to a list if you have nothing useful to say. > A few smart people with a good understanding of social ethics made up > the Debian Social Contract. And one of the main points of this Debian > Social Contract is "we will not hide problems" and "our priorities are > our users". Thank you for keeping that in mind through all your > actions. You seem to read that as "you guys promised to do anything any user asks". Guess what? That's not what we think it means. > What is the point of making software that does not discriminate other > people, but the behaviour of several Debian Developers does? Who is discriminating, on what grounds, and how is that unacceptable? Do you mean Steve shouldn't be allowed to tell you that you're annoying, because he doesn't tell others the same thing? If so, get serious. > Why do some people use that self confidence against small people like > me, instead of trying to catch the message that I try to voice? Because Debian is driven by a community. People who do things tend to be taken more seriously, especially when it is about large changes. If you really want to help make Debian better, you should start by getting involved. Build packages, for example. As long as you're not willing to do actual work, don't expect people to welcome your advice about changing Debian. That's all I have to say about this. If you want a reply from me, please post off-list. I shall not reply to anything which is (also) sent to the list. And certainly not if it's sent as a new thread. 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 signature.asc Description: Digital signature
Re: RFC: Introducing Debian Enhancement Proposals (DEPs)
Anthony Towns <[EMAIL PROTECTED]> wrote: > On Wed, Jan 16, 2008 at 12:18:30PM +0100, Adeodato Sim?? wrote: > > * 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. Aside: where is "Making debian/copyright be machine parseable" in BTS? Where would it go? It's a good point that much of this could be done in the BTS, but maybe it's worth a DEP explaining how to map DEPs onto BTS. Or maybe it's perverting the BTS. I dunno. Sounds good though. Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re^4: ideas regarding a conflict management strategy
"Lars Versen" <[EMAIL PROTECTED]> wrote: > Steve Langasek, exactly that is a general misunderstanding of you and > a few other Debian Developers. > "I have three world-class operating system releases to my credit, > and you dont" [...] I don't believe Steve Langasek ever wrote that. Please try to quote accurately and give references where appropriate. If no quote or reference is available, that might suggest the point should be cut. [...] > What is the point of making software that does not discriminate other > people, but the behaviour of several Debian Developers does? I don't know. There is a difference between discriminating against a person and judging a person according to their actions. > Did you sign the Debian Social Contract and agree to the Debian Free > Software Guidelines to get as much reputation as possible for being > one of the best hackers, or do you enjoy giving people great tools so > they can have the most benefit from using their computer? Neither. > [...] GNU/Debian Linux is used and supported by companies like Hewlett > Packard, Intel and many others. > Shouldnt that create good self confidence for all the people who help > to make GNU/Debian Linux what it is? Not necessarily. They are just companies and most companies act in their narrow self-interest. > Why do some people use that self confidence against small people like > me, instead of trying to catch the message that I try to voice? To stop you doing the harm to the project that they forsee. Hope that helps, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Introducing Debian Enhancement Proposals (DEPs)
On Fri, Jan 18, 2008 at 12:15:33PM +0100, Bas Wijnen wrote: > > > 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. Yes, and you get that consensus by proposing a change and addressing any problems people raise with it. You propose the change by filing a bug report against the debian-policy package. > > 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. So this all sounds like changing things for the sake of changing things, rather than actually solving any problems to me. Count me as not interested. Cheers, aj signature.asc Description: Digital signature
Using the BTS instead of a different system? (Was: RFC: Introducing Debian Enhancement Proposals (DEPs))
On 18/01/08 at 12:15 +0100, Bas Wijnen wrote: > > 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. ;-) I'm not convinced either. It will make sense that discussion about some DEPs happens on the BTS. However, the big improvement I see with DEPs, is that we have a single document to read, that summarizes the state of the issue. Let's take bug #209008 (debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS) as an example. There are already 50 mails in that bug report, split in 5 threads. If you want to know the status of this pseudo-DEP, you basically have to read them all. Having a separate document with summarizes the motivations and the state of this issue would be really useful, and would allow other people to contribute to the thread without going through the 50 mails. However, there might still be something to address in DEP0: maybe we should allow the discussion about DEPs to happen in a different place, specified by the DEP itself. In the case of a pseudo-DEP about parallel building, the DEP could specify that discussion should happen on the BTS. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Usage of linda
Hi James recently merged a little branch from me into mainline dak code, its changelog having: * dak/examine_package.py (check_deb): Remove linda call. It provides no added benefit to lintian anymore. Iow - while you are free to use linda, NEW doesn't use it anymore. During the last few months I did file bugs against lintian requesting the things linda knew that lintian did not knew. All that I noticed got included into lintian (thanks to its maintainers), so we now live without a linda on the ftp-master host.[1] Note that you should check your packages with the *latest* available lintian version. Either by checking on a system running an up2date unstable - or by using the etch-backport of lintian that I maintain on backports.org. That backport is also installed and kept at the latest version on the ftp-master host. I reject based on it. :) [1] Yay, no annoying eastereggs anymore. They arent funny if you see them a hundred of times.. :) -- bye Joerg * maxx hat weasel seine erste packung suse gebracht, der hat mich dafür später zu debian gebracht .oO( und jetzt ist der DD. jeder macht mal fehler.. ) du hast 2 gemacht du warst auch noch advocate :P pgpwJ8KEyb6DJ.pgp Description: PGP signature
Re: Using the BTS instead of a different system? (Was: RFC: Introducing Debian Enhancement Proposals (DEPs))
Lucas Nussbaum wrote: > Let's take bug #209008 (debian-policy: [PROPOSAL] common interface for > parallel building in DEB_BUILD_OPTIONS) as an example. There are already > 50 mails in that bug report, split in 5 threads. If you want to know the > status of this pseudo-DEP, you basically have to read them all. So FWIW, this is a limitation of the BTS, that it would be valuable to fix in the BTS. I sometimes find myself retitling a bug report to summarize the outcome of a particularly long discussion in it. Such summaries tend to make poor titles though, since they're often many lines long. I sometimes see a bug report that starts out being about many issues, and ends up being only about one simple change (such as #452640), but if you're not careful, you'll have to read the whole bug log to figure that out. In these sort of cases, and the case of storing something like a DEP in the BTS, you want a field that's like the title in that it can be changed and appears near the top of the bug page, and that's like the body of a message sent to the bts, in that it can contain arbitrary freeform text, links, etc. If we called this field a summary, one interface to use it could be to mail [EMAIL PROTECTED] to set a new summary. This would add the message to the detailed bug log, so that old historical summaries would be available, and the newest summary would be displayed at the top of the bug report. It would probably also be useful to have a way to get a bug report's newest summary out of the bts and into $EDITOR so minor modifications can easily be made and sent back to the bts. FWIW, while I of course like that the DEP system is using ikiwiki, I've so far found aj's arguments about using the BTS instead more convincing. -- see shy jo signature.asc Description: Digital signature
Re: Using the BTS instead of a different system? (Was: RFC: Introducing Debian Enhancement Proposals (DEPs))
On Fri, Jan 18, 2008 at 01:16:29PM -0500, Joey Hess wrote: > If we called this field a summary, one interface to use it could be to > mail [EMAIL PROTECTED] to set a new summary. This would add > the message to the detailed bug log, [...] That more or less means having a particular message in the bug log be the "summary", so adding: Summary-Mail: 6 to db-h/nn/nn.summary, a -summary alias that updates the Summary-Mail field to that mail's number, and probably a "summary " control command as well. Presumably Summary-Mail: should either default to unset (there is no summary), or the initial bug report. Not sure what the display should look like. It could be just a link to the particular message, or it could be the entire summary message separated by 's or similar, or it could be the first paragraph or n lines of the summary message. > would be available, and the newest summary would be displayed at the top > of the bug report. It would probably also be useful to have a way to get > a bug report's newest summary out of the bts and into $EDITOR so minor > modifications can easily be made and sent back to the bts. In that case it'd probably be good for the summary messages themselves to be considered "boring". Cheers, aj signature.asc Description: Digital signature
Re: Re^4: ideas regarding a conflict management strategy
On Fri, Jan 18, 2008 at 02:35:57PM +, MJ Ray wrote:
> "Lars Versen" <[EMAIL PROTECTED]> wrote:
> > Steve Langasek, exactly that is a general misunderstanding of you and
> > a few other Debian Developers.
> > "I have three world-class operating system releases to my credit,
> > and you dont" [...]
> I don't believe Steve Langasek ever wrote that. Please try to quote
> accurately and give references where appropriate.
Thanks for the vote of confidence in my moral character, but aside from the
attribution of uncharacteristically sloppy punctuation, that is AFAICR a
direct quote. To be sure, I don't in any sense regard those releases as
exclusively mine; a Debian release is certainly a huge committment on the
part of the release manager, but even if we were to discount the significant
efforts of all the individual package maintainers who make unstable
something worth trying to release, every release I've been involved in has
been a group effort on the part of the release team and other motivated
developers.
The context for that comment was that, during a series of IRC ban evasions
one night on the part of our soliloquist ("Frank"? "Lars"? "Sybil"?[1]), I
had the honor of kickbanning him from #debian-devel; at which point he chose
to message me privately about my action, and I obligingly engaged him in the
most insulting way possible to distract him from his previous activity of
disrupting Debian's official IRC channels. I think there may also have been
some comments in there about sex with his mother. None of those comments
should be taken as indicative of anything besides my disdain for a
particular disruptive non-contributor.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
[1] Attempting to avoid the consequences of his past actions by changing
identities seems to be a pattern with Frank. Aside from his long history of
ban evasion on two IRC networks and several Debian channels, we see in his
latest message that he persists in the charade that Lars and Patrick are not
the same person -- in spite of telling coincidences of style, topic, word
choice, and misuse of English, and in spite of the fact that he himself was
the first to name "Patrick Frank" in this thread. I for one think those
actions speak much louder -- and with greater brevity -- than his words.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Introducing Debian Enhancement Proposals (DEPs)
#include january 16, 2008, Michael Banck wrote: > Personally, I think DEP should go to d-d-a *once accepted* (dunno about > obsoleted, maybe as well), but initial drafts should go to either > debian-devel (DEP touches development, I assume this will be the vast > majority of DEPs, also the case for most examples from DEP0), or > debian-project (DEP does not touch development, the `finding > sponsorship' example from DEP0 and DEP0 itself). ...or both - I'd say -, if DEP touches both development and project. (It's so straightforward... why instead flooding d-d-a with *drafts*?) > Otherwise, I think this is a good idea. Did you consider moving dep.d.n > over to wiki.debian.org once that is run by ikiwiki and DEPs are > common practise? IMHO wiki.debian.org should, as the generic domain name suggests, be about somewhat random news, tips, ideas, coordination, teams stuff, and so on. DEPs, when agreed upon and well formalized, would be worth their own subdomain, of course a d.o. one. Just my 2 ¢. -- Luca
