Re: For those who care about their packages in Ubuntu
On Tue, 17 Jan 2006, Anthony Towns wrote: > > What I find very dissapointing is that mdz asked on debian-devel twice > > for a decision from debian how ubuntu should handle the maintainer Field > > without any luck: > > http://lists.debian.org/debian-devel/2006/01/msg00678.html > > http://lists.debian.org/debian-devel/2005/05/msg00260.html > > http://lists.debian.org/debian-devel/2006/01/msg00966.html Debian developers set the Maintainer field to themselves(or a team), when they upload to Debian. The upstream author is only mentioned in the copyright file. Ubuntu should do something similiar. Set the Maintainer field to someone from their group, and mention debian in the copyright(or other appropriate place). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, 17 Jan 2006, Matt Zimmerman wrote: > > Debian developers set the Maintainer field to themselves(or a team), when > > they > > upload to Debian. The upstream author is only mentioned in the copyright > > file. > > > > Ubuntu should do something similiar. Set the Maintainer field to someone > > from > > their group, and mention debian in the copyright(or other appropriate > > place). > > I would very much appreciate if folks would review > http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the > points that I raise there. I put some effort into collating the issues > which came up the last time and presenting them. > > It is important, in particular, to account for the fact that Ubuntu is not > the only Debian derivative, and that proposals like yours would amount to > Debian derivatives being obliged to fork *every source package in Debian* > for the sake of changing a few lines of text. Modify the incoming processor, so that the Packages and Sources files get the correct info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, 17 Jan 2006, Matt Zimmerman wrote: > > Debian developers set the Maintainer field to themselves(or a team), when > > they > > upload to Debian. The upstream author is only mentioned in the copyright > > file. > > > > Ubuntu should do something similiar. Set the Maintainer field to someone > > from > > their group, and mention debian in the copyright(or other appropriate > > place). > > I would very much appreciate if folks would review > http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the > points that I raise there. I put some effort into collating the issues > which came up the last time and presenting them. > > It is important, in particular, to account for the fact that Ubuntu is not > the only Debian derivative, and that proposals like yours would amount to > Debian derivatives being obliged to fork *every source package in Debian* > for the sake of changing a few lines of text. Actually, ignore my last mail. I actually considered that you(ubuntu) would respond thusly. But, it doesn't fly. We don't allow J. Random Upstream to upload unchanged source into Debian. We add meta-data, and set the Maintainer field appropriately. This is so that Debian becomes the contact for the software, when it exists in Debian. Debian derivaties need to do the same. There really is no other way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, 17 Jan 2006, Otavio Salvador wrote: > In my point of view, maintainer field just need to be change when > Ubuntu does a non-trivial change on it. Otherwise, at least to me, is > OK to leave the maintainer field unchanged. Directly imported source > (that will be just recompiled by Ubuntu) doesn't need to be change > since it's the same source code that runs on Debian. But linked against other libraries. The binary is downloaded from another location(or installed from a different cd set). The program used to do the download may be different. While the above list may not be all inclusive, it's enough to warrant changing the Maintainer field to something ubuntu specific. Debian doesn't set the upstream author in the Maintainer field, when the changes only amount to adding a debian directory to the upstream source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Allowing crypto in the main archive
On Wed, 10 Jan 2001, Wichert Akkerman wrote: > > Non-free programs with cryptographic program code need to be stored > on the "non-us" server because of export restrictions of the U.S. What if the non-free program contains source, but is non-free for other reasons? > Programs which use patented algorithms that have a restrictied > license also need to be stored on "non-us", since that is location > on a site where it is not allowed to patent algorithms. Maybe a few examples would help. This part seems vague, and left open to interpetation. Like other vague things in Debian, this would mean we would rather be safe than sorry, so more programs would be in non-us then would really be nescessary. > > A package using a program which is distributed via the non-us > server has to be stored on the non-us server as well. This seems confusing. Why not use the language of dpkg, and say it with depends, suggests, etc? BEGIN GEEK CODE BLOCK Version: 3.12 GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS-- PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z? -END GEEK CODE BLOCK- BEGIN PGP INFO Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID 67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG -END PGP INFO-
Re: Propossed Project: Odyssey
On Wed, 24 Oct 2001, Timothy H. Keitt wrote: > Better yet, lets convince package maintainers not to unnecessarily > update all their dependencies to the latest libs in unstable so that > packages can be easily backported with 'apt-get -b source ...' My guess > is that 60-90% of the packages in unstable do not require the latest lib > versions to build, but that maintainers are defaulting their > dependencies to be >= the latest version in unstable for no reason (of > course, package name changes and package reorganization can throw a > wrench into things). If maintainers default to only depend on what is in > stable whenever possible, many many deb packages would compile just fine > on both stable and unstable. This shows a deep misunderstanding of the way shared libraries work. If a library is changed, and uploaded, it may require an update to its /var/lib/dpkg/info/*.shlibs file. When pkgs are then rebuilt against that library, the pkg-version dependency info is taken from this file. That is what causes newer libraries to be depended on. It is not a conscious effect on the maintainer. Additionally, if a new version of a package comes out, that depends on a new library, do you think that the new package should not be allowed into debian, on the fact that backporting to an older version of debian would be problematic? That line of thinking means nothing would ever be upgraded.
Re: Working on debian developer's reference and "best packaging practices"
On Fri, 3 May 2002, Anthony Towns wrote: > This is rather non-sensical: all packages /are/ left to the whimsy of > the dpkg developers. If you don't believe me, I'm sure Wichert or Adam > will be happy to introduce some random bugs in dpkg 1.10.x to demonstrate. Just say the word, and we'd be happy to comply. :) > If the dpkg authors would like to hand off some of their design decisions > to -policy on a generalised basis, I'm sure they'd say so. It seems a bit, > well, wrong-headed for -policy to be trying to take control of dpkg though. We(Wichert and I) implement features that users want, when we have time. We implement those that are interesting to us when we have free time. I don't think either one of us would feel comfortable being led by another group. > > since potentially large numbers of > > packages would be impacted by such changes. > > The dpkg maintainers are well aware of the likely impact of their changes, > and are quite able to ask for advice when it's needed. I've gotten much better in recent months on this(re last summer). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development
On Sun, 5 May 2002, Raphael Hertzog wrote: > > Given these, if someone can tell me if there's > > anything I can do, Documentation/testing included, > > I'll feel really nice. > > You can do many things : > - bug fixing, you can look for bugs you are able to fix in the > release critical bugs http://bugs.debian.org/release-critical/ > You prepare pacthes and send them to the BTS. Minor nitpick. That url does not include all RC bugs. Some are excluded. However, when people are looking for things to do, it hides this work from them. It'd be nice if there was a list that had no exclusions. cc'd bugscan for their comments on this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#158533: project: qmail is installed on murphy
On Wed, 28 Aug 2002, Brian M. Carlson wrote: > Great! I'm glad you know about it. In fact, I'm elated. Now that you > know, please do something about it. I know you have many machines running > exim, and I've heard from others that you also run postfix on some > machines. I really don't care what mail-transport-agent Debian uses on > murphy, as long as its free. In fact, "apt-cache showpkg > mail-transport-agent" lists 13 available packages in sid main or non-US. What does the mail-transport-agent have to do with it? There is no need to repeat the reasons why to my question above. You can search for them yourself.
Bug#158533: project: qmail is installed on murphy
On Wed, 28 Aug 2002, Daniel Jacobowitz wrote: > It is also not right for us to disrupt our list services. Every time > this argument has come up, there has been a consensus that we need to > switch - but a refusal to do so without a viable list solution. Look > at the graphs; the mail volume is impressive, and we still have just a > few minutes turnaround time on all our lists. We don't want to let > that go; the project as a whole would suffer. And this is all done on a single celeron 400, with 512m of ram. That, combined with the mail volume, and fast turn-around, is what is impressive.
Re: "Bug of the month", or how to get people fixing bugs
On Fri, 30 Aug 2002, Peter Makholm wrote: > Andres Salomon <[EMAIL PROTECTED]> writes: > > > fixing bugs, to simply closing them in the BTS. Sometimes, it's good to > > keep bugs open in the BTS (tagged w/ wontfix, documenting a problem that > > other people may bring up; or tagged w/ unreproducable, as another > > [...] > > Of course this shouldn't change the way we use the BTS. If people > misuse the BTS and close bugs which isn't really fixed or really > proved as non-bugs they shouldn't get credited for the close. We might > even let it have a negative impact on their status. Follow slashdot's ideas. Random people get to approve/disprove/verify other people's work. Slashdot calls it meta-moderating.
Re: Disputes between developers - draft guidelines
Before I comment on any of the actual points below, I'd like to make some statements first. I have been seen in public reopening bugs that have been incorrectly closed by bad changelog entries. I have done this with my [EMAIL PROTECTED] hat on. However, this wrong. I still feel very strongly on this issue, but I should have done it as a converned(very) developer. As an [EMAIL PROTECTED] person, I feel that [EMAIL PROTECTED] should be hands off in any decisions that regard the content of the bugs in our system. We can do code, we can otherwise maintain the system. However, any decisions as to the state of various bugs(other than bugs.debian.org and debbugs) stored in the system should be left to those invovled. Also, for the record, shortly before this email was sent by Ian, I closed a bug(with a rather terse reply) filed by Ian against dpkg(the whole md5sum issue with 1.10). I stand by my email. If Ian would have done the research first, he would have seen that all his complaints had been previously discussed. Also, as part of the above, I am annoyed when other developers don't use(or know how to use) the tools that are available. Especially if so called other developers are part of some semi-functional technical body, and should know better On Wed, 16 Oct 2002, Ian Jackson wrote: > DISPUTES BETWEEN DEVELOPERS > > A *DRAFT* joint recommendation of the the Technical Committee, the > Project Leader and the Bug Tracking System Administrators. As stated above, I do not feel that the BTS Admins should have any say in this. > 2. Distinguish flameage from technical disputes and procedural errors > > Distinguish problems working constructively due to an interpersonal > dispute (`not getting along'), from technical disagreements about how > software should work, or procedural disagreements about whether some > particular thing should or should not be done. Too many large words. Brain on overload. Simplify this whole paragraph. Not to mention it's not a paragraph, but a single runon sentence. > If you feel another Developer has erred, by failing to go about things > in the right way, you should of course tell them about it. But, > please try to make your message helpful and friendly. Probably they > didn't know about the rule in question, or understand it differently. > If you can refer the other Developer to some documentation saying when > they should and should not do something, do so. Yes, by putting "closes: #" or "fixed in nmu. closes: " in changelogs. > 6. Bug report etiquette > > Sometimes bugs are reported inappropriately; likewise, sometimes > maintainers close bug reports inappropriately. Bug reports are `todo > list' items for the whole Project; they should be closed when there is > rough consensus that the whole system is working as well as it could. Yes, like 164889. The issue has been discussed, and resolved. You didn't do any research before sending off your report. I have the right to be annoyed when someone who is supposed to know better doesn't know how to do things the correct way. > * The bug was reported; the maintainer felt immediately that it was a > spurious bug report of some kind, and closed it, but the submitter > disagrees with the explanation and has reopened the report for > discussion. The matter should be debated until both Developers are > happy. The issue at hand has been discussed. You have brought no knew arguments to the table. Absolutely none. Why should we(dpkg developers) waste time beating a dead horse? > At no other time should you play `bug report tag' with anyone else. > If someone makes a change to a bug report status which you disagree > with you should *discuss* the matter with them but *not* immediately > undo their action in the BTS, except to reopen the bug to stop it > getting lost. If you are unable to reach a conclusion through > constructive discussion, you should ask for outside help with > resolving your dispute, as outlined above. Again, you're overstepping the bounds of the package maintainers. As a whole, you'd have some, in your opinion, bad reactions to things you've tried to do. So, instead of trying to find out why, you go and pen this whole long document to try and force your agenda thru political means. For comparison, see Santiago's mail to -vote about GR and spam.
Re: hpt372
On Wed, 30 Oct 2002, Jonas Smedegaard wrote: > On Tue, 29 Oct 2002, Gilbert Martin wrote: > > > I want to know if HPT372 raid controler will be support on the next > > version of debian? > > > > Because i have an ABIT KR7A-RAID, and i can't install linux debian on my > > system. > > According to the URL below (found searching Google) it might be fixed in > Linux 2.4.19 and if so also in the next major release of Debian: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.2/1001.html > > Are you impatient and have access to another Linux machine, then try > grabbing and installing a 2.4.19 kernel package from sid manually (using > dpkg -i), or compile a 2.4.19 kernel yourself... It's not fixed. ac4 attempts to fix it, but there's a half-applied patch. Fixing that, it boots, and sees the device, and the drives run fast. But after a bit of running, dma gets disabled, and shortly thereafter, the bus on the hpt controller goes offline. Even 2.4.19-ac4-ide11 didn't work(this was actually worse for us than plain 2.4.19, with a 2 line patch applied, to get dma working on the mobo ide).
Re: why Ian Jackson won't discuss the "disputes" document draft with me
On Mon, 4 Nov 2002, Manoj Srivastava wrote: > >>"Matt" == Matt Zimmerman <[EMAIL PROTECTED]> writes: > > Matt> On Mon, Nov 04, 2002 at 06:06:44PM +1000, Anthony Towns wrote: > >> -A *DRAFT* joint recommendation of the the Technical Committee, the > >> -Project Leader and the Bug Tracking System Administrators. > >> +A *DRAFT* joint recommendation of the the Technical Committee, and the > >> +Project Leader. > > Matt> As long as we're here, "the the" should be condensed to a single "the". > > As lonfgas we are here, we should actually state: > +A *DRAFT* joint recommendation of the Chairman of the Technical Committee > > Hmm. Joint? with whom? > > +A *DRAFT* recommendation of the Chairman of the Technical Committee. Plus, as I have stated publically(both in email and on lists, and not just on this issue), I(and the most likely the other bts admins) do not want to get involved in these kinds of issues. So, Ian tried to rubber stamp something from groups before he ever even sent out feelers to those groups. Again, this is a 'do as I say not as I do' event. Ian, you may mean well, but please, you are *not* above the rest of us. You do not sign on the ctte so that you can issue decrees from onhigh. You are no better than the rest of us.
Re: why Ian Jackson won't discuss the "disputes" document draft with me
On Wed, 6 Nov 2002, Ian Jackson wrote: > So, in the absence of anything convincing me otherwise, after I think > everyone's had a say here, I'll go back to the tech ctte very shortly > and propose it as a resolution there - and obviously it'll have the > names of the DPL and BTS admins taken off it. Well, as a Debian Developer *AND* a BTS admin, if you do this, I will *NOT* agree with it, *AT ALL*. Period. This is *NOT* something that should be done by buddy-buddy groups, in private, behind closed doors.
Re: why Ian Jackson won't discuss the "disputes" document draft with me
On Wed, 6 Nov 2002, Ian Jackson wrote:
> Adam Heath writes ("Re: why Ian Jackson won't discuss the "disputes" document
> draft with me"):
> > So, Ian tried to rubber stamp something from groups before he ever even sent
> > out feelers to those groups. Again, this is a 'do as I say not as I do'
> > event.
>
> Eh ? I sent you all - all of the people I was proposing might like to
> put their name to it - a draft. Do you think I should have mailed you
> all privately but not posted it on -project ? Surely then Branden and
> Manoj would have accused me even more of secrecy and cabalism !
You shouldn't have put *anyone's* name on it, and sent it to -project
directly. That is were you erred.
Re: Disputes between developers - content, draft #4
On Tue, 5 Nov 2002, Chris Lawrence wrote: > IMHO this is much more likely to be effective if you first get a > consensus that there is, in fact, a problem that needs to be dealt > with. The posts in the other thread suggest you haven't got such an > agreement. Exactly. Point number one. Give that man a gold star. Proceed to the head of the class. You have one 'Get out of jail free card.' Ie, if only one or two or a small group of people are having a hard time communicating, this does not mean the rest of the people in the larger group are also having difficulty discussing matters at hand. And, flammage does not mean you can't communicate. Don't try sticking your finger in a whole to plug it up, and keep it from leaking, when there is no hole to plug. You'll just end up creating a hole yourself. > I also believe the technical committee is an inappropriate organ to be > making such a pronouncement, particularly since this is an inherently > non-technical matter. Then again, since the tech committee best > reflects the concept embodied in our constitution that us mere > developers shouldn't be trusted to run the project in any way, shape, > or manner, I'm hardly surprised. Well, as I understand it, the ctte comes into play when the developer populace can't reach a decision. It appears that Ian is trying to shunt this task away from the ctte, and make everyone else do their(his) job for him. No document can ever hope to fix or guide every person. We are humans, different, and therefore can't be constrained by this type of document under discussion. This is why the ctte was designed. To handle these types of occurances. So, I guess what I am saying, is that this document, while good in idea, is already taken care of, by the ctte itself. We don't need this document. It's all really just common sense, anyways. > My recommendation: either find a consensus that this is needed, or > propose it as a general resolution. For now, I personally don't see > the problem as severe enough to justify such a document, and nothing > in this discussion has convinced me in the least to change this view. A GR is not something that should be used when other avenues are closed. It should be used *sparingly*. I've seen way to much inclination to play the GR card, and this saddens me as to the internal downward spirals it implies.
Re: why Ian Jackson won't discuss the "disputes" document draft with me
On Tue, 5 Nov 2002, Bdale Garbee wrote: > Did that message not reach you, or are you just annoyed that I haven't had > anything particularly useful to inject into the conversation since then? 'useful' in this case is not the common definition, but Ian's own personal spin. Ie, useful in Ian's world means anything that he already agrees with.
Re: Disputes between developers - content, draft #4
On Wed, 6 Nov 2002, Ian Jackson wrote: > I think you must have a different experience to me. I've found that > many developers don't seem to share enough of the context and unspoken > rules. I think writing them down will help. I also think it might > produce some useful pressure on those people who ought to know better > but lapse occasionally. (And I'm not excluding myself here.) Ok, let's go with that idea then. That most developers do not share a common background, or a common upbringing. That means that each developer will interact differently to each situation. So, now you come along, and want to write a document that describes best how to interact. Well, from what I have seen, you have gave this document your own personal spin, have not been willing to let the whole populace at large offer critiques, and when critiques do come, you selectively ignore those that to not fit in with your own view points on the issue. If this document is to be truly cross-civilization compatible, then all such civilizations involved *must* be given complete involvment. Ie, let *everyone* have their say, and become completely impartial. >From what I have seen from you, this has not been the case.
Re: why Ian Jackson won't discuss the "disputes" document draft with me
On Wed, 6 Nov 2002, Ian Jackson wrote: > Perhaps I can help. > > It seems that, despite marking my document DRAFT etc., I've offended > some people by in their view giving the impression that the document > is currently anything more than something I'm working on - with > people's help, of course, but not necessarily their approval. That's the problem. You keep saying it's *you* working on it. If it's for Debian at large, then we *all* should work on it. Stop being so ego centric. Do you not think the rest of the Debian populace can think for themselves, and can come to an agreement? Or do you think that the ctte needs to do the thinking for everyone else? > So, I apologise for giving that mistaken impression. I'd appreciate > it if that apology could be accepted so that we can get on with > talking about what's really important - the substantive content. This is still not an apology. > Would it help if I put `DRAFT PROPOSED' at the top of my next draft > instead of just `DRAFT' ? Would that make it clear that there is not > (yet, anyway) any formal approval from anyone but me ? Proprosed is more official than just draft.
Re: Bug#97671: xutils: why is rstart.real a conffile?
On Mon, 11 Nov 2002, Branden Robinson wrote: > [-project and -policy, I CCed you because I'm raising issues relevant to > you; *please* honor the Mail-Followup-To: header!] Er, why -ctte and the bug only? My response is germane to more than these groups. In fact, this really doesn't have any particular bearing on the bug, nor the ctte. > > Obviously, I, personally, do, and if you want to punt to the release > > manager, you can make use of that. It's not clear that's particularly > > appropriate, since the question is surely as much "was this the right > > thing to do" as "does Anthony have any right to do it". > > My feeling as package maintainer is that, if you as Release Manager > don't regard it is a show-stopper for release, then I should be > permitted to prioritize the bug as I see fit. Hmm. Ponder. Severity should not be changed. It is well defined, as to what it does. However, maybe a second field, that the maintainer has full control over, that signifies the order in which he is looking at bugs, or something. This could be added somewhat easy. It'd most likely be the first new field added to the .status file, since like forever.
Re: Regaining Access to the Control Bot
On Wed, 5 Nov 2003, Branden Robinson wrote: > Well, it's been a week and a half and no one has replied, not even a > member of the BTS administration team. Joy is a member of the team.
[OT] Re: Just a single Question for the Candidates
On Thu, 4 Mar 2004, Craig Sanders wrote: > this "We're a minority, we're special" card you mention is used by those who > feel marginalised or persecuted, i.e. in an inferior social position. > > i don't think any of the australians in this forum could be accused of feeling > that :) Aren't your neighbors sheep lovers? Doesn't that invalidate the austrailians by association?
The Ineffectual DPL?
I have not voted in this DPL election. I didn't vote in last year's. I think I only voted in the first one, but even then, I'm not sure. So, why have I not voted? 1) Lack of time? The actual act of voting takes no time. 2) Lack of knowing the candidates? Possible. See below. 3) Interest? None. 4) Knowing that the DPL will not actually help the project, and just cause more work? Most definately. Ok, so 4) is going to stir the hornet's nest. Let me explain. In the past several years, I have seen a few different DPLs in (in)action. I have not seen the betterment of the Debian Project as a whole(as a result of actions the DPLs have done), yet each DPL has said how well they have improved the situation. Additionally, each candidate has vowed to improving Debian, yet, in all reality, they will not be able to implement what they desire. As we all know very well, this project is a volunteer organization. There is no way to enforce upon those involved any kind of responsibility. The only responsibility that may exist, is that which each person has placed upon themself. There are countless incidents in Debian's past, where some existing developer has left in outrage, because of either some disagreement, or having something demanded of them(this list is not exhaustive). At any point, a developer can decide not to continue work, and there is not a thing the project can do, to make him(her) continue. Which brings me to the DPL's involvment in this particular train of thought. If the developer that is being asked to do something, or asked to discuss something, is themself not motivated to do(discuss), then there is nothing that the DPL can actually do to change that. Motivation is generally a personal thing. Also, the DPL can appoint delegates, or add memebrs to the Tech. Ctte. The DPL can also make descisions when no one else does, and decide what to do with funds held for Debian. In all honesty, having the DPL do these things is not in Debian's best interest. The DPL can change per year, and there are no technical requirements for the post. I would much rather prefer someone to make these appointments/decsisions who actually knows what they are doing, and have experience doing so. The only way one can get experience, is by actually doing similiar/related work, which shows they know what it is they say they do. Saying you want to do something, or saying you know something, is not the proper venue for building yourself up. The only venue is action. As those who actually do the work, get better and better at it, they become more and more qualified to make descisions based on the work that they are doing. Others, who only observe from the outside, are not qualified to decide how the work *actually being done* should proceed. The DPL, by definition(by being voted into office, instead of earning it), is one of those that should not be making such decsisions. In effect, the DPL is nothing more than a figurehead, that can change from year to year. This changing offers no apparent external view of stability, which hurts Debian in the long run. The figurehead itself may succeed in convincing more users to make use of Debian, but any regular developer can do that themself. The DPL is doing nothing special there. The DPL may be invited to attend some conference, or do some talk. It'd be much better, to have someone attend who can actually benefit, or actually can talk about the particular segment being discussed. I consider these more perks of the office, which make me believe the office itself is a reward, and not a duty. So, in summary(I'm rambled on long enough), I see no point in having a DPL. None whatsoever. And I consider all those, past, present, and future, who are associated with the DPL office, suspect for their motivations in seeking it. I consider them only willing to improve their own situation, instead of improving the actual Debian Project itself. ps: Don't send me replies directly. Chances are I won't read them. Don't expect to see me replying much in this thread. There's no point in me wasting my time. I'd much rather be doing real work, then useless bickering. If you agree with this as I do, then a simple "I agree" will suffice, sent in public reply. Then, start doing real work. If you don't agree, then by all means, waste your's and everyone else's time, by actually attempting to discuss and disect this email. But those who really care about the project will ignore the ensuing discussion.
Re: The Ineffectual DPL?
On Wed, 7 Apr 2004, Philippe Troin wrote: > I always vote, probably for the same reasons I vote in my country's > elections (mostly to prevent the people I disagree with the most to > get into office) and without having any trust nor hopes in the system > whatsoever. Voting in real elections makes sense, to stop bad seeds from getting into office. For Debian, the DPL is ineffectual, so voting or not voting really has no bearing on what actually happens.
Re: The Linux Standard Base (LSB) 2.0
On Tue, 14 Sep 2004, A Gibot wrote: > To Debian. I would like Debian to use LSB 2.0. It would help Linux distros > like Linspire. Please do this. : - ) We'll get right on it.
Re: Proposal of new "admin" pseudo BTS package
On Fri, 24 Sep 2004, Christian Hammers wrote: > Hello > > I got the feeling that starting a discussion Cc'd to debian-admin > is senseless as they seem too busy to answer. > (See current mega-threads in debian-private that could have easily > ended by a single definite statement by the admins) > > I therefore propose to create a pseudo bug packages for "mail" issues (and/or > maybe one for general "admin" topics) like the existing "lists.debian.org" or > "www.debian.org". > > This would surely not a way to make them act faster but a way to keep > track of open issues and a place where everybody can make a short comment > to an issue. Also if everybody could see that there are too much open > issues in a special area the one in charge could ask for more or better > volunteers. That's not how it works. You can't create a new place for those who do work to check for things to do. That'll just increase their load. Get those who would supposedly benefit from this to agree. However, if they prefer the current way of doing things, you can't force it down their throat. ps: Speaking both as a member of the bug team, and as a local debian admin.
