Re: Question to all candidates: GDPR compliance review
]] Adrian Bunk > Who will fulfill the request within the legal limit of one month if > a person sends an email to data-protect...@debian.org asking whether > Debian is a (joint) controller of any data about this person, and > if yes requests a copy of all data? To make this easier for services and users, we recommend that services use contributes.debian.org and that they then request the data from the individual services and then point people at that. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Question to all candidates: GDPR compliance review
]] Adrian Bunk > Would you commit to something more specific, like that our Data > Protection team will reply to debian-project within 3 months discussing > all issues mentioned in the discussion at [1] so far, and with their > reply having been proof-read by our GDPR lawyer? I don't think that's something the DPL could commit to, even if they wanted to. First of all, what you're asking for is not what the data protection team is there for, secondly, neither the DPL nor anyone else has the ability to commit to anyone in Debian doing anything on any particular timeline. If that's what you're looking for, you're looking for a company with staff, not a volunteer project. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Question to all candidates: GDPR compliance review
]] Jonathan Carter > So, I would appreciate it if the data protection team could look into > all of the issues we know of in Debian, but I'd also like there to be > a process where people can file issues with the data protection > team. I'll admit I had to search a bit to find the data-protection > email address, it doesn't seem to prominently feature anywhere on our > website. www.debian.org → Contact → privacy (not sure why the footer is missing from the front page) and it's there, so while not _very_ prominently, it's not very hidden either. > But it would be great if it was clear that someone could file > a bug with a tag, or whether they should use the data-protection > alias, so that it's possible to file and keep track of data protection > issues that need to be resolved. This isn't the role of the data protection team, though, any more than owner@bugs is responsible for fixing all the bugs in all the packages. I'm quite happy to act as a redirector (as per the first part of the delegation) as well as advising service owners. I have below-zero interest in auditing all our services and tracking everything relevant to data privacy throughout Debian. I can't speak for the other team members, but I have not seen them express enthusiasm about this idea either. Even if you got a team that would perform that tracking and auditing, what good would it be? They wouldn't be able to compel any service owners to fix their service. Cheers, -- Tollef Fog Heen, for himself UNIX is user friendly, it's just picky about who its friends are
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
]] Philip Hands > Tollef Fog Heen writes: > > > ]] Stefano Zacchiroli > > > >> I'm hereby formally submitting the GR proposal included below between > >> dashed double lines, and calling for seconds. With respect to past > >> discussions on the -vote mailing list, this is the proposal code-named > >> "2-S"; see [1,2] for (the last known versions of) alternative proposals. > > > > I like the term limit concept. I'm wondering if we should have a wider > > proposal in which we just make the CTTE an elected body. I'm not sure > > it's a good idea, but I'm also not sure if it's been discussed at all > > (only having followed some of the -vote discussions around this from the > > web archives). > > Wouldn't it have been great if the various factions around the systemd > issue had got the idea early on to try to stuff the committee with their > respective friends before the decision. If we assume four-year terms, that'd have been, at max, two members out of the eight. > Personally I think there's more than enough voting going on as it is, > and adding reasons to have more regular votes will just promote the idea > (that is already rather hard to dissuade people of) that all one needs to > do is vote for a thing, and somehow it will magically do itself. I'm not seeing people having that idea. > It does not strike me as obvious that popularity correlates to > competence. Also, it would not be helpful if members of the committee > were tempted to take the popular side of an argument, against their > better judgement, because they were coming to the end of their term, and > they would like to be reelected. If that's the only reason, make it so people can sit for a maximum of one term before being off the committee for a full term and that effect more or less vanishes. I'm not saying «We should absolutely have an elected TC», I'm saying that I think it's something that's worth discussing. As for Zack's point about this process being underway already: yes, that's the point. If we want to change things about the TC, let's put out a comprehensive proposal instead of changing one thing now and another thing in six or twelve months. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d28168qi@xoog.err.no
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
]] Stefano Zacchiroli > I'm hereby formally submitting the GR proposal included below between > dashed double lines, and calling for seconds. With respect to past > discussions on the -vote mailing list, this is the proposal code-named > "2-S"; see [1,2] for (the last known versions of) alternative proposals. I like the term limit concept. I'm wondering if we should have a wider proposal in which we just make the CTTE an elected body. I'm not sure it's a good idea, but I'm also not sure if it's been discussed at all (only having followed some of the -vote discussions around this from the web archives). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvcyh2tr@aexonyam.err.no
Re: Proposal - preserve freedom of choice of init systems
]] Russ Allbery (Dropped DAM and personal Ccs) > Second, Matthew's proposal explicitly doesn't change the TC decision, so > I'm not even sure what you think would be aborted here. It wouldn't have > any effect on the choice of default. It dictates in a top-down manner to > individual developers how to do their work and undermines the flexibility > of Debian contributors in ways that I think are unnecessary and a little > condescending, and requires work be done without identifying anyone who is > going to do the work, which is why I voted against it. But it's not some > sort of end-run around the previous decision. The previous decision does say that it is replaced completely by the text of such a position statement and I do note that the proposed GR does, very carefully, not refer to systemd as the default. It makes for a clumsier construction, which when combined with the level of legal-ish arguments being made here, makes me suspicious. It feels like we're way past rough consensus and working code and running at full speed into a courtroom. > Third, even if it were, as Andreas points out, we put that clause in there > intentionally. If the project wants to change the decision about the > default init system, it can do so with a 1:1 majority. I don't think anybody has a problem with the non-cornercase interpretations of the GR. > I think the way this GR is phrased is odd, and I agree with Bdale that I > see no reason why it couldn't just be a straight statement on issues of > the day without being attached to a TC decision. Currently, it's attached > to a decision about the default init system while not actually saying > anything about the default init system, which I think is strange. I > concur with Kurt that while procedurally this may be allowed, I don't > think it's a particularly good idea. I think it's a terrible idea. Ian writes that he specificially made it as broad as he did in order to create this situation so that anything could be included. > Also, separately, please don't attack Ian for things that Matthew > proposed, or for clauses in previous decision that Bdale drafted in > conjunction with the project secretary. This is not a situation of Ian's > creation. https://lists.debian.org/debian-vote/2014/03/msg00020.html, by Ian: That GR override clause was written by me. I specifically drew it widely precisely so that, amongst other things, a GR could answer questions that the TC has failed to answer. I don't think pointing at Ian for the clause is particularly unfair. Ian's also seconded the proposed GR, which generally means you agree with whatever you're seconding. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhws1kp7@xoog.err.no
Re: GR: Selecting the default init system for Debian
]] Daniel Pocock > E.g. if we choose systemd, who will implement all the things that need > to be changed outside the Gnome related packages? What will immediately > fail if not adapted to systemd? In general, nothing should fail. sysvinit scripts are first class citizens in the systemd world and you can have native → sysv → native dependencies. There are some bugs, both in systemd and in init script (such as cycles), but in general this hasn't been a big problem so far. I believe that the ease of maintenance and the ability to do more with native systemd units (private /tmp, network namespacing, etc) will make it interesting for maintainers to move towards native units by themselves, but there's no flag day involved for a switch-over. So, I'm not sure what you mean by «all the things that need to be changed outside the GNOME related packages». If you have any particular things in mind, please feel to enumerate them and I'll answer to the best of my ability. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877g9ws2q0@xoog.err.no
Re: [all candidates] Removing or limiting DD rights?
]] Russ Allbery (Cc to owner@bugs, M-F-T to -project.) > Note that we already did do something about it by deprecating close in the > BTS in favor of sending a real email message to -done that is copied to > the submitter. The Debian BTS now nags the maintainer about telling the > submitter something if they use the close command. We did this ages ago. Perhaps it's time to retire the close command entirely? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sj38p1tc@qurzaw.varnish-software.com
Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller (Sorry for Cc-ing you on the last post; it was not my intention.) | On Sat, Jul 17, 2004 at 03:33:17PM +0200, Tollef Fog Heen wrote: | > You're jumping through a lot of hoops to get to somewhere which is a bit | > like multiarch, but not quite. And you'll end up with something less | > capable, more ugly and a lot more work to support properly when | > upgrading to multiarch. Doing the full dance is less work. | | You don't know that. Multiarch isn't designed yet. You are wrong on this respect. I designed it, with lots and lots and lots of input from many other DDs over the last half year. Matt Taggart did a lot of the file system layout work, which was needed for LSB multiarch. It doesn't have a full-scale implementation yet, but it does have a design. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller | > | It's fairly simple for the port to be built to support both 32 and 64 | > | bit LSB apps, and still allow for migration to multiarch. | | On Fri, Jul 16, 2004 at 06:45:17PM +0200, Tollef Fog Heen wrote: | > As others have said -- it's not easy to support both 32 and 64 bit. If | > you want to do that properly, you should implement multiarch. | > | > Please keep migration to multiarch out of the equation -- as long as you | > stay out of /lib/$arch-$os (i[34]86-linux, x86_64-linux), you are fine. | | Is it just me or are these two paragraphs contradictory? They're not. | Every upgrade up till now has managed to deal with replacing files in | the same directory as what the new package supplies. Uhm, which of the two glibc packages are you talking about? libc6:amd64 or libc6:i386? For them to be coinstallable, they need to have no file overlaps. | What is it about multiarch that makes it such a pancea for the future, | and such a horrible thing to start moving towards? It will probably cause some instability which we _really_ don't need when we're trying to get sarge out the door. Our core tools need fixing for multiarch: dpkg, apt, DAK, glibc, gcc. I don't think breaking them at this time is wise. | > | [For example: Have /lib64 be a symlink link to /x86_64-linux/lib and have | > | /lib be a symlink to /i486-linux/lib (similar for /usr/lib*). Make sure | > | that the libraries explicitly mentioned in LSB are installed in the 64 | > | bit library, leave the others as known bugs, to be fixed when people have | > | the time and inclination. Make sure your patches respect some env var | > | (perhaps MULTIARCH_HOST), and have that be set at a fairly high level.] | > | > If you're going to do this, then why not do the full multiarch dance? | | Because you can't do everything at once. You're jumping through a lot of hoops to get to somewhere which is a bit like multiarch, but not quite. And you'll end up with something less capable, more ugly and a lot more work to support properly when upgrading to multiarch. Doing the full dance is less work. | Also, maybe it's good to keep some distinctions in mind here. There's the | system on which the packages are installed (where lib and lib64 are | symlinks to multiarch lib dirs), and there's the packages themselves | (which install into /lib, /lib64, etc.). Huh? Where have you gotten the idea that lib and lib64 will be symlinks? Have you actually _read_ the proposal? | > If you do that, you'll end up with fixing packages once, not twice. | | Assuming I make no mistakes, and am capable of fixing everything at the | same time, sure. | | I don't know about you, but I'm just not that competent. The minimum number of times you'll break something is less with multiarch than with biarch + multiarch. The amount of potential breakage when going from uniarch to multiarch is less than going from uniarch to biarch to multiarch or uniarch and biarch to multiarch. Biarch is an unneeded step which complicates things. | > | > Uh, multiarch *will* be painful. biarch *would* have been painful too. | > | > We're not disputing that, that's why we're *NOT* asking for biarch or | > | > multiarch to be part of sarge. Not even close. We're interested in | > | > having pure64 released with sarge so that Debian users can use their | > | > amd64 systems reasonably. | > | | > | In my opinion, the only thing painful about my above example | > | implementation is that it make the things that need to be fixed painfully | > | obvious. | > | > Have you made a biarch package yet? If not, please do that and come | > back when you have. It's painful, to do it the right way. | | What do you mean by "the right way"? And, why is that way right? I assume that means "no". The right way is one which works properly on both uniarch and biarch systems, always installing into the correct directories, handling file overlaps properly and so on. | > | My current objections are that you're not planning for compliance with | > | LSB and you're not planning for migration to multiarch. Both will be | > | a lot easier to achieve with just a little forethought. | > | | > | [Before you explained about multiarch, my only objection was the lack | > | of 32 bit LSB support.] | > | > .. and the multiarch migration is independent of this and will happen | > for all arches, not just multiarch-capable ones. (Because even though | > $random_arch might not be able to run some binaries doesn't mean that | > $some_other_random_arch can't run $random_arch's binaries.) | | I've never claimed otherwise. You're claiming, for some reason, that amd64 needs to prepare for multiarch
Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller | It's fairly simple for the port to be built to support both 32 and 64 | bit LSB apps, and still allow for migration to multiarch. As others have said -- it's not easy to support both 32 and 64 bit. If you want to do that properly, you should implement multiarch. Please keep migration to multiarch out of the equation -- as long as you stay out of /lib/$arch-$os (i[34]86-linux, x86_64-linux), you are fine. | [For example: Have /lib64 be a symlink link to /x86_64-linux/lib and have | /lib be a symlink to /i486-linux/lib (similar for /usr/lib*). Make sure | that the libraries explicitly mentioned in LSB are installed in the 64 | bit library, leave the others as known bugs, to be fixed when people have | the time and inclination. Make sure your patches respect some env var | (perhaps MULTIARCH_HOST), and have that be set at a fairly high level.] If you're going to do this, then why not do the full multiarch dance? If you do that, you'll end up with fixing packages once, not twice. | > > But this is reminding me of some of the pain from the /usr/doc -> | > > /usr/share/doc/ transition. [Where most everyone thought it was easy | > > right up until it became a big hairy mess.] I'd rather not go through | > > something like that again. [And why did we go through that at all? | > > For LSB compliance.] | > | > Uh, multiarch *will* be painful. biarch *would* have been painful too. | > We're not disputing that, that's why we're *NOT* asking for biarch or | > multiarch to be part of sarge. Not even close. We're interested in | > having pure64 released with sarge so that Debian users can use their | > amd64 systems reasonably. | | In my opinion, the only thing painful about my above example | implementation is that it make the things that need to be fixed painfully | obvious. Have you made a biarch package yet? If not, please do that and come back when you have. It's painful, to do it the right way. | My current objections are that you're not planning for compliance with | LSB and you're not planning for migration to multiarch. Both will be | a lot easier to achieve with just a little forethought. | | [Before you explained about multiarch, my only objection was the lack | of 32 bit LSB support.] .. and the multiarch migration is independent of this and will happen for all arches, not just multiarch-capable ones. (Because even though $random_arch might not be able to run some binaries doesn't mean that $some_other_random_arch can't run $random_arch's binaries.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller
| > Everyone knows that. If it was, we'd be doing it and sarge would be >
| released in 2006 at best. That does NOT provide justification to not >
| support AMD64 at *all*.
|
| The question is, what's the upgrade path to an amd64 system which supports
| 32 bit code? Is that going to be easier from i386 than from amd64?
It will be the same (both path-wise and difficulty-wise).
| First, you'd have to build a system which references /lib64 instead
| of /lib, once you've upgraded to that system you could then get rid of
| /lib and replace it with a 32 bit /lib/. Which means we'd be ready take
| advantage of amd64 native support for i386 binaries sometime around 2010.
| Maybe.
Please, go read http://raw.no/debian/amd64-multiarch-3 and
http://www.linuxbase.org/~taggart/multiarch.html . Multiarch does not
require a full migration, it can be done piecewise (though, libc needs
to be done first, for obvious reasons).
| That's not a very exciting prospect to consider if the reason we're
| trying to get amd64 in sarge is that not offering the support for the
| architecture that other distributions do would make us a "laughingstock".
I haven't seen anybody laugh at gentoo for not providing 32 bit AMD64
support.
| I can guarantee you'd get more support for a 64/32 bit system than a
| pure 64 bit system. [As in, I'd contribute.]
I wouldn't. Not until you do it the right way, which is to do it
multiarch.
| > Right, so you'd be able to run AMD64 Debian and i386 Debian. What
| > you're proposing is that we only offer i386 Debian. How is that better?
|
| Less complex upgrade path to AMD64 with 32 bit support.
All libraries are going to move _no matter what_ for multiarch, they'll
move to /{,usr}/lib/$arch-$os, so it won't matter.
| And that's aside from problems like "ok, I've got my 64/32
| environment running X, and now I want to run a debian X app
| inside a chroot cage."
Then bind-mount /tmp and it will just work.
| Last time I checked [two days ago], the trivial change to dpkg to support
| amd64 hadn't happened. I think making sure that the debian package tools
| work right for the architecture should be considered pre-requisites for
| using the package system to present the rest of the packages.
http://cvs.debian.org/dpkg/archtable.diff?r1=1.21.2.11&r2=1.21.2.12&only_with_tag=v1_10&cvsroot=dpkg
Seems to have been applied about three weeks ago.
--
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Subject: Proposal - keep non-free, but commit to actively encouraging making individual packages obsolet
* Raul Miller | Also, since my pgp key is so ancient people with recently installed | systems probably won't be able to verify it, and since I haven't submitted | my new gpg key yet, could someone who can verify my signature please post | a signed statement to the list indicating whether or not the signature | on my propoal appears in the key ring? Seemed to work fine with unstable's gpg: : [EMAIL PROTECTED] ~ > gpg --keyring /usr/share/keyrings/debian-keyring.pgp --verify < Mail/linux/debian/vote/2004/662 gpg: Signature made søn 11-01-2004 19:42:14 CET using RSA key ID 9ECB8809 gpg: Good signature from "Raul Miller <[EMAIL PROTECTED]>" gpg: aka "Raul Miller <[EMAIL PROTECTED]>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0F 0B C0 6B 13 DD 15 FE C9 84 73 CF 84 16 8E 13 : [EMAIL PROTECTED] ~ > -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: [Proposal] Updating the Social Contract
* Anthony Towns | 1. Debian Will Remain 100% Free Software | | We promise to keep the Debian GNU/Linux Distribution entirely free | software. | | so that we can avoid having to claim that What about the Hurd and the BSDs? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Subject: Proposal - keep non-free, but commit to actively encouraging making individual packages obsolet
* Raul Miller | Also, since my pgp key is so ancient people with recently installed | systems probably won't be able to verify it, and since I haven't submitted | my new gpg key yet, could someone who can verify my signature please post | a signed statement to the list indicating whether or not the signature | on my propoal appears in the key ring? Seemed to work fine with unstable's gpg: : [EMAIL PROTECTED] ~ > gpg --keyring /usr/share/keyrings/debian-keyring.pgp --verify < Mail/linux/debian/vote/2004/662 gpg: Signature made søn 11-01-2004 19:42:14 CET using RSA key ID 9ECB8809 gpg: Good signature from "Raul Miller <[EMAIL PROTECTED]>" gpg: aka "Raul Miller <[EMAIL PROTECTED]>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0F 0B C0 6B 13 DD 15 FE C9 84 73 CF 84 16 8E 13 : [EMAIL PROTECTED] ~ > -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Proposal] Updating the Social Contract
* Anthony Towns | 1. Debian Will Remain 100% Free Software | | We promise to keep the Debian GNU/Linux Distribution entirely free | software. | | so that we can avoid having to claim that What about the Hurd and the BSDs? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q for candidates: the ALS issue
* Bdale Garbee | There might be something we could do to raise the visibility of the | calls-for-papers from various events that would help this, like | getting them mentioned in DWN? please submit items which you want included in DWN to [EMAIL PROTECTED] We take everything (nearly) that we can get. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Q for candidates: the ALS issue
* Bdale Garbee | There might be something we could do to raise the visibility of the | calls-for-papers from various events that would help this, like | getting them mentioned in DWN? please submit items which you want included in DWN to [EMAIL PROTECTED] We take everything (nearly) that we can get. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian services and responsibility
* Ean Schuessler [snip explaination] | This might be a good time to think about how many times you have ever | said "thanks" to Brainfood for our years of effort and support. You know | how often we hear that from anyone? Almost never. All we get is bitching | and complaining, speculation about how we are some evil cabal, and | formal SPAM complaints to our service providers. Just some message like this helps a lot -- it keeps us other developers a little bit in the loop. We do understand that you have to pay your bills, but when you have a service which suddenly turns into a black hole and the only place with any information is the topic on #debian-devel, that causes confusion, which in turn may cause FUD. I am not saying that you should give us a complete by-the-minute update of what's going on, but saying something like you did stop speculation and calms people down. And, thanks for the service you are providing. We are all appreciating it. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: debian services and responsibility
* Ean Schuessler [snip explaination] | This might be a good time to think about how many times you have ever | said "thanks" to Brainfood for our years of effort and support. You know | how often we hear that from anyone? Almost never. All we get is bitching | and complaining, speculation about how we are some evil cabal, and | formal SPAM complaints to our service providers. Just some message like this helps a lot -- it keeps us other developers a little bit in the loop. We do understand that you have to pay your bills, but when you have a service which suddenly turns into a black hole and the only place with any information is the topic on #debian-devel, that causes confusion, which in turn may cause FUD. I am not saying that you should give us a complete by-the-minute update of what's going on, but saying something like you did stop speculation and calms people down. And, thanks for the service you are providing. We are all appreciating it. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSED] Michael Bramer must stop spamming or be expelled
* Glenn McGrath | By the same argument i should be able to opt out of recieving mail from the | bug tracking system about any future bugs in the package i maintain, Nope, because part of your duties as a maintainer is to fix those bugs, and/or pass them upstream. | or opt out of receiving mail from debian-private. Which you can. You should be on d-d-a, though. -- Tollef Fog Heen Axiom #1: You Can't Win
Re: [PROPOSED] Michael Bramer must stop spamming or be expelled
* Glenn McGrath | By the same argument i should be able to opt out of recieving mail from the | bug tracking system about any future bugs in the package i maintain, Nope, because part of your duties as a maintainer is to fix those bugs, and/or pass them upstream. | or opt out of receiving mail from debian-private. Which you can. You should be on d-d-a, though. -- Tollef Fog Heen Axiom #1: You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
