Re: Debian decides to adopt time-based release freezes
On Thu, Jul 30, 2009 at 12:16 AM, Marc Habermh+debian-proj...@zugschlus.de wrote: Hi, On Thu, Jul 30, 2009 at 08:45:41AM +0200, Carsten Hey wrote: Why not freeze in June 2010 instead of December 2009 and then freeze again in December 2011*? Mark Shuttleworth seems (at least seemed) to be fine with delaying Ubuntu LTS by half a year to get Ubuntu and Debian in sync [1]: | The LTS will be either 10.04 or 10.10 - based on the conversation that | is going on right now between Debian and Ubuntu. I don't think that we shouldn't time our releases according to what Mark Shuttleworth says. We are not Ubuntu's slave even if they try hard to make it look like that. In fact, I would prefer if Ubuntu had to change _their_ scheduled to accomodate us, if they want to have the advantage of being in sync with us. It's _their_ advantage after all, not ours. Our 18-to-24-month release cycle was a nice vehicle to stay asynchronous with Ubuntu, which _I_ consider a desireable feature to prevent Debian from perishing. We are not only major supplier to Ubuntu, we have our end customers ourselves. I'd prefer that it stayed that way. I don't get why do you consider 18-to-24-month release cycles a desirable feature to prevent Debian from perishing. Is this just to stay out of sync with another deb-based distro? We are definitely not only major supplier to any other deb-based distro, and you act our end customers are really happy with not even knowing the date when we will freeze to our next release. Could you please also point out why that's bad to a set of our end customers? regards, -- Gustavo stratus Franco -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Otavio, let me make it clear for all readers that you're talking on behalf of debian installer team. I'm sure d-i team is very important to RM team. Communication is far from being a strong quality of this project, with that in mind could you please try to dissociate a little from the whole thing and raise points against a time-based release freeze from d-i team point of view? I really want to know, but from your previous message all I see is screw you RM team, you talked to Ubuntu folks and didn't talk to our direct peers so we will make that fail. I'm sorry if it wasn't the statement you wanted to share. On Wed, Jul 29, 2009 at 11:10 AM, Otavio Salvadorota...@ossystems.com.br wrote: On Wed, Jul 29, 2009 at 1:32 PM, Bernhard R. Linkbrl...@debian.org wrote: * Stefano Zacchiroli z...@debian.org [090729 18:22]: Please, everybody, stop this kind of you evil DebConf attendees have decided for us all arguments. The time-based freeze has been announced/proposed during a talk at DebConf; it was fresh news for the attendees as it was fresh news for everybody else receiving it via -announce a few hours later. Well, it was not totally fresh news. After all there was already http://derstandard.at/1246541995003/Interview-Shuttleworth-about-GNOME-30---Whats-good-whats-missing-what-needs-work (which was linked from slashdot and other sides). It is quite nice to notice that _our_ /dear/ Release Team was in touch with Ubuntu (nothing wrong with that) but forgot to get in touch with us ;-) There's nothing wrong and discuss plans with other projects and share ideas; what is completely wrong is to not discuss it with us specially because WE ARE THE ONES THAT ARE GOING TO MAKE IT (NOT) HAPPEN. Not sure if this makes the situation much better. But it was not actually totally surprising. Sure it helps; it makes clear the importance we have for RM people. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org regards, -- Gustavo stratus Franco -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Micros*ft deal
On 6/20/07, Robert Millan [EMAIL PROTECTED] wrote: Hi, Since every GNU/Linux distributor seems to be positioning with regards to possible patent deals with Microsoft, I thought we could do the same. Actually, it's totally unthinkable that a non-profit organization could do this kind of deal, in which Microsoft pays you to perform hara-kiri by losing the right to distribute GPLv3 software. This is exactly what a positioning statement would reflect: that our community model is invulnerable to this kind of threats (and also to going out of bussiness, etc). Thoughts? I believe our silence says it all, no? If they want to donate us money for no 'carte blanche' back good, otherwise I don't think it's worth write a PR and help them spread their FUD, IMHO. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developers vs Uploaders
On 3/16/07, Simon Huggins [EMAIL PROTECTED] wrote: On Fri, Mar 16, 2007 at 04:26:15PM +0100, Pierre Habouzit wrote: Well, I'm still not sure wether DM is a good thing or not in fact. But I'd say it has te be experimented yes. If we are going that road, Then I've two people to recommend for this: Fathi and Yves-Alexis Perez that is our one-man xfce-team (at least judging the XFCE Team recent activity I think he is doing 99% of the job), and that is truck in NM because is AM has still not sent his AM report (for almost 4 monthes). For Corsac (Yves-Alexis) it's not the best solution, but at least he would not depend upon a sponsor anymore for the XFCE uploads, and I'm sure it will be a spine out of his foot. I've worked with Yves-Alexis on xfce packaging and sponsored some of his work into the project or uploaded work that was from the team with large contributions from him. I can't fault his work or dedication and when I've pointed things out to him or raised issues in general he's been very responsive in getting things in our repository - certainly more responsive than I've been of late. He certainly deserves to get a key in a keyring. As far as I'm aware, he's just waiting on a report from his AM (daf) currently having passed all the NM tests before he waits on DAM. I'm sure Emanuele Rocca who works on xfce with us would have similarly nice things to say. I'm not sure how aj's 30 sponsored uploads works for teams. I've signed and uploaded packages (having tested them and built them in pbuilder) for the xfce project where the actual packaging work done by a particular person is at times hard to tell. Given xfce has many source packages to upload when upstream just rolls out a new release this might count or might not but I can certainly attest to corsac's bug processing and packaging skills. In any case, Yves-Alexis deserves to be pushed through NM or get his key in this DM keyring whichever comes first. I'm unable to sign this message now, but can resend it after if needed. I second Fathi and Yves-Alexis as DM's or DDs, whatever comes first, due to their work for a better Debian Desktop as key contributors. Fathi into pkg-kde and debian-desktop and Yves-Alexis into pkg-xfce and debian-desktop. thanks, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/27/07, Francesco P. Lovergine [EMAIL PROTECTED] wrote: On Fri, Feb 23, 2007 at 10:06:47AM -0300, Gustavo Franco wrote: Exactly Martin, if the plain is a publicly accessible interface to track requests for DSA, we've our BTS! The security argument sells the idea that a RT (not publicly accessible) would be better. That's why #408150 wasn't solved as i have requested. I disagree. RT has a very flexible and complex ACL management which lacks in BTS. So it can be potentially used to to ensure public view of some information without full disclosure. I know and use RT daily. I've asked use-cases where we need to use this 'complex ACL management'. What do you want to hide? Two different tracking systems for only one project is a bad idea, if somebody show a real use-case then what we need is a developers only accessible BTS, not RT. I still fail to see a need for a second BTS setup though. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/28/07, Joerg Jaspert [EMAIL PROTECTED] wrote: On 10944 March 1977, Gustavo Franco wrote: I disagree. RT has a very flexible and complex ACL management which lacks in BTS. So it can be potentially used to to ensure public view of some information without full disclosure. I know and use RT daily. I've asked use-cases where we need to use this 'complex ACL management'. What do you want to hide? Get a new machine sponsored somewhere. The sponsor will send you the initial root login which usually includes a password. You dont want anyone to see that. Hi Joerg, This use-case was already covered above without RT and BTS usage. Do you really want that initial root login password flying in plaintext until it reaches a private RT? What's the point of a private RT then? mitm attack here is trivial, to say the least. As i said, nobody should send it to BTS, RT or email directly in plaintext, these sensible information might be sent by mail, out of the tracker and encrypted. The tracker is still valid here because the issue title would be something like sponsored machine setup and its status should be available for anyone (not the server password itself, come on), or at least any Debian developer, IMHO. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/24/07, Mark Brown [EMAIL PROTECTED] wrote: On Fri, Feb 23, 2007 at 12:16:52PM -0300, Gustavo Franco wrote: That's up to the person behind the *my* you wrote, disclose $ADDRESS and $NUMBER. The same can't be said about our email address, so what's the point really? I don't think the DSA members will want to disclose this kind of information and if somebody does, they won't be forced to do so. Let me rewrite what would happen IRL, IMHO: Please send the machine to my home address - I'll drive out to the DC and put the machine on-line ASAP. Give the sipping company my phone number. I'll send you *my personal details* privately. You are assuming that the person sending the e-mail is aware that the information they are sending is going to end up publically visible. With a lot of tracking systems this may not be the case. In the particular case of RT the work flow appears to involve generating e-mails to which anyone can reply, with replies causing information to be added to the ticket. This means that it's easy for someone to put information in there without ever realising that there's a public archive. Well, based on what you wrote we don't need a new tracking system but just a new feature into BTS. If a user send a report (or reply) to the pseudo-package $FOO, it will return a message to him warning that if replying to that auto-generated message will forward his message into a public archive. That's up to him avoid reply the message and rewrite it, if needed. It won't cover the case where the private information goes through non trusted pipes. It can't be easily solved with BTS nor RT though. I still disagree with a private tracking system for DSA. Almost all the information isn't sensible and can be there, the details can be passed privately and it's up to the message submitter and nobody else. It isn't like a person out of DSA can disclose sensible information that will put DSA stuff at risk. I do agree that we should make an effort to make information available but we need to be aware of the problems that could arise and take steps to mitigate them. The case with keyring-maint is even worse for this since people might decide to do things like send scans of ID documents. I agree, but the answer isn't a private (DSA or visible by DDs only) tracking system even if it's RT or a new debbugs setup, IMHO. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/23/07, martin f krafft [EMAIL PROTECTED] wrote: also sprach Kalle Kivimaa [EMAIL PROTECTED] [2007.02.23.1054 +0100]: You did notice that the DSA team is about to install a request tracker for issues like you described? I would think that takes care of most of the current communication related issues. Does it say anywhere that this will be publicly accessible? Exactly Martin, if the plain is a publicly accessible interface to track requests for DSA, we've our BTS! The security argument sells the idea that a RT (not publicly accessible) would be better. That's why #408150 wasn't solved as i have requested. I don't see anyone opening a bug against a new debian-admin pseudo-package containing sensible information and the pseudo-package maintainers are smart enough to avoid add such thing in the answers, and it would be valid for public BTS or private RT anyway. If you disagree please answer with examples and remember that we've enough sensible information into our BTS (eg.: security issues in the softwares) and anyone is free to open bugs with debsecan output and stuff like that. Don't tell me that hey, what's the alpha machine status? and keyring-maint requests will leak information. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On 2/23/07, Mark Brown [EMAIL PROTECTED] wrote: On Fri, Feb 23, 2007 at 10:06:47AM -0300, Gustavo Franco wrote: softwares) and anyone is free to open bugs with debsecan output and stuff like that. Don't tell me that hey, what's the alpha machine status? and keyring-maint requests will leak information. Off the top of my head Please send the machine to my home address $ADDRESS - I'll drive out to the datacentre and put the machine on-line as soon as possible after I get it. Give the shipping company $NUMBER (my mobile phone number) as the contact number in case there are problems. That's up to the person behind the *my* you wrote, disclose $ADDRESS and $NUMBER. The same can't be said about our email address, so what's the point really? I don't think the DSA members will want to disclose this kind of information and if somebody does, they won't be forced to do so. Let me rewrite what would happen IRL, IMHO: Please send the machine to my home address - I'll drive out to the DC and put the machine on-line ASAP. Give the sipping company my phone number. I'll send you *my personal details* privately. I still disagree with a private tracking system for DSA. Almost all the information isn't sensible and can be there, the details can be passed privately and it's up to the message submitter and nobody else. It isn't like a person out of DSA can disclose sensible information that will put DSA stuff at risk. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Criteria for a successful DPL board
On 2/13/07, Raphael Hertzog [EMAIL PROTECTED] wrote: On Mon, 12 Feb 2007, Gustavo Franco wrote: - more momentum to the leadership: clearly a single leader is swamped with administrivia and even the addition of a 2IC didn't let Anthony finish his first proposal (about giving single-package upload rights to some people which don't want to become full DD but want to maintain just one or two packages) Could you elaborate about the administrivia comment? I already elaborated somewhere else in the thread. It's more that the DPL is probably too much sollicited (mediation, press, various CC to [EMAIL PROTECTED]) which let him not too many time to do the projects that he might have presented in his campaign. It would be good ask for past DPL input on this then. - better decision taking: when you have a big discussion, it's difficult to take a decison alone, you take the sole responsibility of it... whereas when you're 10 which are deciding, it's easier to assume the outcome. Which kind of decision? Technical? The kind of decision that you expect a DPL to take: decide if a new idea is worth trying, decide of some guidelines for internal teams, decision of new appointments, decide how to spend our money, ... Doesn't it makes part of the various CC to [EMAIL PROTECTED] you pointed out above? Nothing new here, i don't see a problem being solved but new ones being created due to concurrency problems i will explain below. It's also a form of leadership that fits better our own internal workings. If a board member goes MIA, we still have 9 others who are there. We've group examples that actually work this way and others that simple don't work if one board member is MIA. That's all about how much work from others one of the members can block. I don't see how someone can block the work of others in this particular case. Please be specific (or stop bringing out unrelated concerns). I'm sorry, but i think you see and the block can be intentionally or not. Have you ever worked in medium teams behind one email ([EMAIL PROTECTED]) ? It doesn't scale and it rarely works, but just when one or a smaller group of persons make the decisions and act while others do basically nothing but watch. Then you can suggest that the email can be pointed to a private request tracker or something similar and that's better, but i don't see the current problems being solved. We would be just opening the doors to create new ones, if we don't have enough already, IMHO. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Criteria for a successful DPL board
On 2/12/07, Raphael Hertzog [EMAIL PROTECTED] wrote: Hi, Hi Raphael, On Mon, 12 Feb 2007, Romain Francoise wrote: Raphael Hertzog [EMAIL PROTECTED] writes: Feel free to comment, ask questions and give suggestions on how to enhance it. Could you provide a bit more context about which problems this would solve, and why you think it's necessary? It tries to give: - more momentum to the leadership: clearly a single leader is swamped with administrivia and even the addition of a 2IC didn't let Anthony finish his first proposal (about giving single-package upload rights to some people which don't want to become full DD but want to maintain just one or two packages) Could you elaborate about the administrivia comment? - better decision taking: when you have a big discussion, it's difficult to take a decison alone, you take the sole responsibility of it... whereas when you're 10 which are deciding, it's easier to assume the outcome. Which kind of decision? Technical? There's the technical committee. I think a DPL board wouldn't help solve our social issues, so you're trying to replace my tech-ctte elected proposal to a DPL board elected proposal, that makes no sense IMHO. - better respect of the leadership: if you don't like the leader, it's easy to dismiss any of its decision, but if you have 6 people in the board that you respect and 4 that you don't trust too much, you're more likely to accept the outcome of a given decision. I agree. It's also a form of leadership that fits better our own internal workings. If a board member goes MIA, we still have 9 others who are there. We've group examples that actually work this way and others that simple don't work if one board member is MIA. That's all about how much work from others one of the members can block. I really prefer to see a tech ctte elected and more active, and only one DPL preferably with a 2IC. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On 1/25/07, Josip Rodin [EMAIL PROTECTED] wrote: Hi, This idea arose from a discussion on the -private mailing list. Andreas Tille, Gustavo Franco, Manoj Srivastava and Gunnar Wolf all commented fairly positively on a vague idea of having a social committee (soc-ctte), different from the technical committee (tech-ctte). I'm citing their names simply to avoid an issues with taking credit. Hi Josip, I don't see a soc-ctte as a problem, if we define how such a committee will act to solve some of our problems though. We need some thing like committee use cases, not just an vague idea. Unfortunately, i can see that some people here into this thread try to spread FUD just based on the idea. Those could get their volunteer asses and do something more useful and let us discuss if the soc-ctte use cases we came up with are worthy. Closing, before any soc-ctte that i hope can help us solve a set of our problems, we need changes the way tech-ctte actually works. I will elaborate more in the near future and avoid debate with those that came up here to say nothing needs to be changed into Debian, nothing needs to be changed into tech-ctte, what's wrong (we're doing great in the tech and social sides, that's the dreamland!) ?. (...) regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On 1/25/07, Lars Wirzenius [EMAIL PROTECTED] wrote: On to, 2007-01-25 at 19:11 +0100, Josip Rodin wrote: As far as appointment, we could try all the same for soc-ctte. Except two things: * keeping votes secret - maybe they should not be secret. * soc-ctte members should serve two years or more. Hmm. There might be a problem requiring people to commit to working on something for Debian for at least two years. It's a bit commitment, and might scare off otherwise worthy people. (Not quite sure it would scare off me, right now.) DPL is committed to work as a volunteer for a one year term and is free to enter on VAC as much as he wants. What's the new problem such a committee would introduce? None. Maybe the limit should be a third of the election quorum, or sqrt(number-of-devels)/2? Currently that would be 16 people. I think that's a good sample of people, and a workable audience for a mailing list (of soc-ctte). Even if we expand twice in size, that's still just 23 people (i.e. the ctte would not grow twice as large). The bigger a committee is, the harder it is for it to get anything done, in general. However, as long as the soc-ctte doesn't need all of its members to be active for some particular decision, then it shouldn't be hampered by people being on vacation, or having their ADSL moved, or whatever. I agree, we don't need a big club, we need a small team that works. We really need real world examples how the committee could handle past issues though. I'm not awake enough to came up with examples. Despite the above two quibbles, I'm in favor of the soc-ctte idea. I'm sure there's lots of details to work out, but those are just details. Agreed. -- The most difficult thing in programming is to be simple and straightforward. The most difficult thing in Debian are changes, i heard that even some kind of uploads were blocked due to the fear of change. :-P I'm sure for a external viewer we look like a bunch of technical skilled cowards sometimes. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On 1/26/07, Steve Langasek [EMAIL PROTECTED] wrote: On Thu, Jan 25, 2007 at 05:55:03PM -0600, Manoj Srivastava wrote: We can determine social policy by discussion and, if necessary, by voting. I'd rather see consensus, and, more specifically, see the soc-ctte spell out the social norms and if the developer body disagrees with it, and can't convince the soc-ctte via discussion, they can force a change via a GR. Voting implies the tyranny of the majority; and I would expect the social and cultural norms to be heavily biased towards white, male, occidental euro-american social and cultural modes; since such is the composition of the voting population. I am not sure I want to be governed by such a social /cultural policy. Why do you think the establishment of a social committee would have any bearing at all on whether you're subject to a tyranny of the majority where cultural norms are concerned? FUD! When you want to stop any kind of changes, that's easy point out that a social committe will work as a censor before it starts, before we discuss use case scenarios and under which rules soc-ctte will play it role. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Let us start a ombudsman team (was Re: Social Committee proposal).
On 1/25/07, Josip Rodin [EMAIL PROTECTED] wrote: Hi, This idea arose from a discussion on the -private mailing list. Andreas Tille, Gustavo Franco, Manoj Srivastava and Gunnar Wolf all commented fairly positively on a vague idea of having a social committee (soc-ctte), different from the technical committee (tech-ctte). I'm citing their names simply to avoid an issues with taking credit. (...) Hi list, First let me explain it has nothing with the suggestions i plan to follow to the technical committee, the content of James Troup message to -devel and what happened before that. I would like to invite some people directly[0] and any other person interested, please ask to join. I plan to start a ombudsman team (alioth), to do the following: - Quality Assurance (but not technically speaking) based on community feedback; - Ask for a pseudo-package in the BTS (ombudsman?) or use project and usertag the ombudsman related bugs. There users/contributors/developers can complain about a number of things; - These things would be listed in the ombudsman.debian.net or our page at alioth. We can discuss this initially here. My suggestions are: * Keep an eye on the mailing list to make sure the community is being heard and the pending non-technical issues can also be tracked in our bug tracking system; * Filter (using the BTS) and forward the feedback to the responsible teams; * Contact the tech-ctte when a technical issue isn't being handled properly by a developer or a team and the community is complaining; * Do informal polls (e.g: To see if the community cares about frequent team updates to d-d-a between releases); * Help with the -private partial archive opening to the public (when the time comes); - Test the waters for a consistent social committee proposal in the near future. If needed we can ask in special cases (eg.: sven's case) the DPL to delegate to the group some powers as in 5.1.2 - Lend authority to other Developers (Debian constitution). [0] = Amaya Rodrigo Andreas Schuldei Andreas Tille Carlos Laviola Erinn Clark Felipe van de Wiel Guilherme Pastore Ian Murdock Josip Rodin Philip Hands Raphael Hertzog Keep in mind that you just need some free time, an alioth account, understand our goals helping us to achieve them and some love for the Debian project. regards, -- stratus http://stratusandtheswirl.blogspot.com ps: I have just CCed invited people that i'm not sure if are subscribed to -project. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let us start a ombudsman team (was Re: Social Committee proposal).
On 1/26/07, Amaya [EMAIL PROTECTED] wrote: Hi all! Andreas Tille wrote: On Fri, 26 Jan 2007, Gustavo Franco wrote: Amaya Rodrigo Andreas Schuldei Andreas Tille Carlos Laviola Erinn Clark Felipe van de Wiel Guilherme Pastore Ian Murdock Removing Ian Murdock from my reply: a) he is no DD (yet!) (WTF and LOL) Sad but true, anyway he can take part of this project with an alioth account as i wrote. I've asked him to be involved in the social committee. The ombudsman project is just a step before that. That's up to Ian decide if he wants to get involved from the first day, join us some time after (into ombudsman or soc-ctte) or change his mind and don't join us. We need practical results to show the critics that we can do better with a ombudsman project and after that push it into our formal structure, we can call that the social committee. Anyway, i think we shouldn't care if we will be cited into the constitution in the near future or not. b) now seriously, I don't think he is in close contact with the project anymore. But I do agree that he is a trustworthy and honest candidate, and good at mediating. I would be glad to count with his experience, right now. Today, there's no technical challenge to start a new distribution, but there are giant social and marketing barriers. I'm not sure how but Ian solved the three problems (with help of course) ages ago and we are ruining this, IMHO. Josip Rodin Philip Hands Raphael Hertzog This is a really nice collection of people I regard trustworthy and honest. Thanks, I feel honoured. I'd be happy to assist in this project (I assume we are talking about the social ctte here, right?). The plan is: First an ombudsman project in alioth, show some results, test the waters and then move on with the soc-ctte thing that would require 3:1 majority to change the constitution. There's also other people I'd like to see involved in (or around) a project like this: Enrico, Biella, Micah, Mako, Holger, Filippo, Bdale, Stephano Zachiroli, Alphascorpii, Vorlon, Steve, Lars, Marga, tbm... I am sure I am leaving many out! Which vorlon thread? :-P Well, i'll open a request on alioth to project setup but you're free to invite more people that are committed to the goals i wrote in the first message of this thread. There are no dictators so we can (and probably will) review the goals once we start discussing under the ombudsman mailing list. Don't forget what we learned every day with programming though: KISS. (...) What I do not really understand here is in how far we could do more as People listed in ombudsman project of alioth than we could now without listed at a project page? Depends on wether there is a formal DPL delegation or not. Exactly, and AFAIK it was never tried before. Correct me if i'm wrong, but never a group of people involved with the project were committed to hear community (both users, contributors and developers) feedback and try to work on the problems or push people that has delegated power to do so. I can do that alone, but there's no minimal formal process or anyone tracking the list of pending issues anywhere. That's just a few of the ombudsman project points. Yes, we even can request formal DPL delegation for some issues as a group. (...) So can we take this on-list? I'm moving back to the list. Kind regards and have a nice^Wprosperous weekend Heh, thx. Wish me luck with the flu I am going through though :) ;-) regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hardware for Debian people
On 12/9/06, Andreas Schuldei [EMAIL PROTECTED] wrote: * Martin Schulze ([EMAIL PROTECTED]) [061209 14:46]: aparently this can be worked around if the machine is owned outside brazil and is only hosted there. so somehow e.g. fiis could own the machine and have it hosted in .br. Stratus, could you please try to find out further details or find out who would know? Yes, i'll do that during this week. joey, could that work? Assuming that you refer to ffis e.V. I guess so, but you should uh, sorry, yes. contact [EMAIL PROTECTED] when you definitifely plan to go that way. will do. Thinking about this, it should be no problem to own and export a machine on the german side. I will try to find out more about that, though. thanks! regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Nome
On 9/24/06, Tulio de Melo [EMAIL PROTECTED] wrote: Qual o significado do nome Debian? Tem alguma coisa a ver com Demônio, essas coisas? Valew! Hi list, Tulio asked in portuguese the origin of Debian name and i point out below the project-history page. [ Tulio, por favor não envie novamente mensagens em português para uma lista de discussão internacional, nelas o idioma que deve ser utilizado é o inglês. Respondendo a sua pergunta, leia: http://www.debian.org/doc/manuals/project-history/ch-intro.pt.html#s1.2 ] regards, -- stratus
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/29/06, Loïc Minier [EMAIL PROTECTED] wrote: On Fri, Jul 28, 2006, Gustavo Franco wrote: I agree, but we need to keep in mind that Ubuntu has less officially supported packages (the main section) and the others are in universe section, supported by volunteers like us, that work on (almost) whatever thing they think is ok. Actually, I would be fine with only supporting a smaller set officially in Debian too. Of course, not all Debian Developers would agree with me on this. I think Ubuntu has also two upload keyrings, one for people approved to upload to main (the officially supported set) and one for people allowed to upload to universe (more or less the rest). Good point, i agree with you, but there's no doubt that this is a discussion for Etch+1. I don't remember the project discussing second citizen class packages but just architectures until now. If we define a sane criteria and the non released packages turn the life of our release team and people work on transitions easier, why not? It's time to consider if Etch will be bigger than needed and what can be better for Etch+1, IMHO. regards, -- stratus
Re: package ownership in Debian
On 7/29/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 02:49:34 +, Gustavo Franco [EMAIL PROTECTED] said: On 7/29/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006 14:11:03 -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] said: On Fri, 28 Jul 2006, martin f krafft wrote: also sprach Matthew Garrett [EMAIL PROTECTED] [2006.07.28.1737 +0100]: If Debian had slightly less of a culture of Keep your hands off my package, I'd do it here instead. I've been thinking about this a lot for the past week. Is there any way this could be changed? Yes, and we could start by really enforcing co-maintainership. Make it 100% mandatory for all essential, required and base packages at first. Err, I am not sure co-maintaining packages actually unequivocally improves packaging quality or response times. There are teams that work well for a packagfe, and then there are packages where team maintainence has not worked out. It won't improve packages from the first day, but in my experience it has improved the way i can communicate with people. It's easier for me talk with a member or two in a group and sometimes join them temporarily and help. The one-man approach, when this one-man is a freak hurts the project, and when the person is sane and the package(s) needs more work, you end with a group maintanance even if itsn't official. If the person is sane and has a package that needs more help, the person get co-maintainers. ANd even then, sometimes, adding maintainers does not reduce the laod on the primary. This is also from experience. Speak by yourself. You wrote that there are teams that work well for a package, and then there are packages where team maintenance has not worked out. These packages where team maintenance has not worked out were well maintained by one person before or what? If not, i disagree. Yes, and in a recent case, that single maintainer was thinking of taking the package back, in order to improve maintainance. Well, wasn't he in that group? Co-maintainers are much closer to what is being done in a package than joe-random developer. Also, co-maintainership is far less prone to fire-and-forget uploads that hose things, and are nicer to people who feel very strongly about their packages. Co-maintainerships require communication, and ability and desire to share decisions, can result in a culture of it is someone elses problem (neat aphorism in german, I believe), and if the team does not trust one of the members, then things can turn ugly. Sometimes, too many cooks do indeed spoil the broth. I think the debian-installer guys can tell you otherwhise. Ha ha ha ha. I can only suspect you do not have access to -private. You know i've. AFAIK, d-i is going well, even with all the problems, i can tell you about Debian Python Modules Team but you would say it isn't core, i don't care, yadda, yadda, Do you see d-i as a project where Joey or Frans do everything almost alone and others just send patches using the BTS ? IMO, if we could reach a better level of resilience, lower response times, and agility with co-maintainership, it would be better than going to the extreme Ubuntu did. I am not yet convinced that that is the case universally, especially if you force people to work in teams. Hello, i thought Debian project was a big team. If people here don't want to work in a team, we're going nowhere. I think that force is the wrong term, we should encourage and in some cases require to avoid single point of failure, IMHO. There is no difference between requiring a team and forcing a team on people. And that does not work. That's great how you ignored my answer for your first comment, but ok. There's a big difference in Manoj maintaining his package foo and Gustavo maintaining glibc alone, do you see? regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/29/06, Thijs Kinkhorst [EMAIL PROTECTED] wrote: On Sat, 2006-07-29 at 08:48 +0200, Martin Schulze wrote: There's a nother problem with team maintained packages. The Security Team has to work on packages that are team-maintained in sid every once in a while. Often we want to get in touch with the maintainer privately before disclosure or before releasing the advisory. With team-maintained packages, the maintainer address often points to a mailing list, so we can't talk to them. Even worse are packages in whose changelog the entries aren't signed by a real person but by a list address as well. That's some sort of anonymous maintenance. I understand the problem, but this is more a question of implementation. Indeed, it's important to always specify who's part of the team, and if you ask me, there always needs to be a head maintainer or team leader who bears the final responsibility for the package. Much like the Maintainer vs Uploaders situation. We've the team admins in alioth. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/29/06, Julien Danjou [EMAIL PROTECTED] wrote: On Fri, Jul 28, 2006 at 11:03:47PM -0500, Manoj Srivastava wrote: Why is a 0 day NMU not OK policy when a team is not maintaining a package well? If there is a bug in the package, it should be fixed asap, regardless of how many people are mismaintaining the package. Where apache is a good example. Do you have a bug number and severity? regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/29/06, Matthew Palmer [EMAIL PROTECTED] wrote: On Sat, Jul 29, 2006 at 02:49:34AM +, Gustavo Franco wrote: Hello, i thought Debian project was a big team. If people here don't want to work in a team, we're going nowhere. Two words for you: Fred Brooks. More two for you: Be polite. I think that force is the wrong term, we should encourage and in some cases require to avoid single point of failure, IMHO. require and force certainly seem like the same term to me. in some cases and in all cases are different terms to me. When you work out how to channel-bond human-to-human communications, we'll talk. Until then, please fix actual problems instead of making broad statements with no actual benefit. Great comment to do for somebody writing IMHO, I think and stuff like that. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On 7/29/06, Matthew Garrett [EMAIL PROTECTED] wrote: Anthony Towns aj@azure.humbug.org.au wrote: What if we introduced the concept of area maintenance? Like saying Matthew Garrett is part of our hardware support team, so can thus NMU any package that needs changes to support that release goal. with the proviso that a bug gets filed with the NMU patch [0] at the same time. We already have something like that with 0-day NMUs for certain transitions authorised by the RMs. That's certainly an interesting idea, and I'd be happy to explore it. How do other people feel? I called this group of groups some messages ago, but we can create proper 'metagroups' (defining areas), eg: desktop artwork or hardware support, and then pkg-gnome, pkg-kde will point who's responsible for desktop artwork uploads or something similar. Thoughts? regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/29/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 16:16:53 +, Gustavo Franco [EMAIL PROTECTED] said: On 7/29/06, Matthew Palmer [EMAIL PROTECTED] wrote: On Sat, Jul 29, 2006 at 02:49:34AM +, Gustavo Franco wrote: Hello, i thought Debian project was a big team. If people here don't want to work in a team, we're going nowhere. Two words for you: Fred Brooks. More two for you: Be polite. What is so impolite in pointing you to an excellent reference, and gently reminding you that increasing team size (to, say, the number of Debian contributors) is detrimental to product quality and ability to deliver on time? Manoj, it's clear he was trolling, it was far from gently reminding me, come on. I think that force is the wrong term, we should encourage and in some cases require to avoid single point of failure, IMHO. require and force certainly seem like the same term to me. in some cases and in all cases are different terms to me. So we only force people to be on a team in some critical cases? Still sounds like a bad idea to me. What's your problem with me? Henrique wrote the same thing some messages ago, why you keep replying everything i post here? If i'm right, your point here is to keep the things as they're, teams and individuals maintaining stuff without any changes from the procedures we're following now. If yes, make it clear and reply my messages like you do with others, right now it seems that you've decided to attack me. When you work out how to channel-bond human-to-human communications, we'll talk. Until then, please fix actual problems instead of making broad statements with no actual benefit. Great comment to do for somebody writing IMHO, I think and stuff like that. First you chastize me for not speaking for myself, and then when someone does, you yell at them for doing so. I did it yes, i thought you were wearing your captain cap and make jokes about if i'm subscribed to private or not. Who cares? Btw, your sentence have nothing to do with my view on Matthew's reply. I said to Matthew that he was being rude and told me to fix human-to-human communication. It wasn't Matthew shut up and/or speak by yourself. Do you see? Wonderful consistency :) After 6 years around you start learning some tricks with the cabal. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/29/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 19:46:58 +, Gustavo Franco [EMAIL PROTECTED] said: On 7/29/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 16:16:53 +, Gustavo Franco [EMAIL PROTECTED] said: On 7/29/06, Matthew Palmer [EMAIL PROTECTED] wrote: On Sat, Jul 29, 2006 at 02:49:34AM +, Gustavo Franco wrote: Hello, i thought Debian project was a big team. If people here don't want to work in a team, we're going nowhere. Two words for you: Fred Brooks. More two for you: Be polite. What is so impolite in pointing you to an excellent reference, and gently reminding you that increasing team size (to, say, the number of Debian contributors) is detrimental to product quality and ability to deliver on time? Manoj, it's clear he was trolling, it was far from gently reminding me, come on. It is not at all clear that pointing to the mythical man month in a discussion on forcing teams or even make it all one huge honking source code repo with universal commit and build from the repo is trolling at all. I never asked to force teams everywhere in the project or huge honkin source code repo so you're jumping the gun in the wrong direction. I think that force is the wrong term, we should encourage and in some cases require to avoid single point of failure, IMHO. require and force certainly seem like the same term to me. in some cases and in all cases are different terms to me. So we only force people to be on a team in some critical cases? Still sounds like a bad idea to me. What's your problem with me? Henrique wrote the same thing some messages ago, why you keep replying everything i post here? If i'm right, your point here is to keep the things as they're, Please stop trying to state what other people's motivations and goals are, your track record WRT to me is not that great. You're motivated against me, it's clear. Again, wearing the same cap judging my track record. I will let you calm down and reconsider not only your opinion about our ideas, since the ones in this thread aren't my ideas, but the ideas of many and you picked me to insult. While we're at it, why don't you reply Anthony's message or Joerg's ? Ignore me if my track record isn't that great. When i reach your great track record Manoj, i hope i don't act like you. (...) When you work out how to channel-bond human-to-human communications, we'll talk. Until then, please fix actual problems instead of making broad statements with no actual benefit. Great comment to do for somebody writing IMHO, I think and stuff like that. First you chastize me for not speaking for myself, and then when someone does, you yell at them for doing so. I did it yes, i thought you were wearing your captain cap and make You know, you really should not project motivations on to other people. captain's cap, jeez. jokes about if i'm subscribed to private or not. Who cares? If you are not subscribed to -private, you lack information about how well teams are getting along with current and ex members. For the second time You know i am. (...) Wonderful consistency :) After 6 years around you start learning some tricks with the cabal. Well, people playing tricks and word games do attract my ire, yes. Except for our *track record*, we're not that different then. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/28/06, martin f krafft [EMAIL PROTECTED] wrote: Please reply to -project only! also sprach Matthew Garrett [EMAIL PROTECTED] [2006.07.28.1737 +0100]: If Debian had slightly less of a culture of Keep your hands off my package, I'd do it here instead. I've been thinking about this a lot for the past week. Is there any way this could be changed? Does Debian *want* it changed? I would like to see it, but with some comments: Before Etch: * Promote NMU LowThreshold wiki list giving it some official status. The developer needs to be logged and mark if all his packages (where he's listed as uploader) can be NMU'ed or not. He could add comments like I'm listed as uploader in foo but group x is the backup uploader; After Etch: For NEW packages: * Add in the new ITPs reports what group (alioth) is responsible for your package too (eg: vte, pkg-gnome) or could act as backup uploader. The package doesn't need to be in the group's svn repository, to give it some more flexibility. I think it should be the development/upload case for a lot of packages; * If the ITP is without the backup uploader means that any DD is free to upload it. Almost no coordination to change or upload new packages (upstream release, RC bugs, wishlist bugs) is needed. It would be good if Joe ping the maintainer before upload, just to avoid version conflicts, duplicated work and all that; Note: Those that are upstream in project bar and uploads the package for Debian just for its own use, might open RC bugs against the package. The rationale is if you don't want that nobody uses your stuff, touch your sacred upstream code, use it at home alone! :-) For existing packages: * The package that contains only the Maintainer field with the name of a person and not a group can be uploaded by any DD. ping the current maintainer is good but not required; * If the package contains a group in the Maintainer field and/or a group of people in the Maintainer field or Uploaders. It's required that the uploader ping the group and coordinate his upload. I think with something similar to what i wrote above we will end up with almost all the packages maintained by groups and some packages maintained by Debian as a whole and not individuals. The next step would be groups allowing other groups to upload some of their packages. The core stuff will be more flexible and well maintained, if we don't have groups where just one person do all the work and others are there just to look cool. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/28/06, martin f krafft [EMAIL PROTECTED] wrote: also sprach Gustavo Franco [EMAIL PROTECTED] [2006.07.28.1838 +0100]: * Promote NMU LowThreshold wiki list giving it some official status. The developer needs to be logged and mark if all his packages (where he's listed as uploader) can be NMU'ed or not. He could add comments like I'm listed as uploader in foo but group x is the backup uploader; How about a flag in the package's control file and an appropriate column in the PTS? I'm not sure about the details. Think about this use case: You're in the middle of the transition, so this is ok NMU all your packages related with that transition. You won't upload a revision to point out that NMUs are welcome. We're using wiki articles and stuff like that today. There's wotomae (DWTT) coming too.. Well, i think the general idea is ok, we need to think about the details and side effects. I would prefer something using PTS, but not requiring package changes. It could be a signed mail to PTS subscribing/unsubscribing packages from our own Low Threshold list. The uploader would be able to query this information by email or using the web interface. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/28/06, Clint Adams [EMAIL PROTECTED] wrote: Yes, and we could start by really enforcing co-maintainership. Make it 100% mandatory for all essential, required and base packages at first. Are there packages which are particularly well co-maintained right now? What about debian-installer, xorg, gnome, kde, ... ? regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/28/06, Fabio Tranchitella [EMAIL PROTECTED] wrote: Hi Pierre, please don't Cc me, I read this list. :) Il giorno ven, 28/07/2006 alle 19.28 +0200, Pierre Habouzit ha scritto: and that won't happen because I'm not very keen on leraning yet another VCS, and that other's think the same, and that you will find poeple that never used svn or just can't use it, and poeple that never used bzr or don't like it , or ... I was talking about repositories, not a single monolithic repository: you are free to use cvs, svn, monotone, bzr, darcs or whatever else you prefer. If every developer would use a common server for his repositories, it would be easier for the others to find and use them. (...) I think we've two important points here: * Are you working on the package foo ? In a scenario when anybody or tons of people can upload the package foo, it's necessary to tag somewhere that you're working on the package foo. Groups do it using IRC or wiki articles today. We could do it using the NEWS in the PTS. It won't break the current groups approach since these groups can point the wiki articles or irc channels for coordination there. * Where are you working on the package foo ? You could send the vcs information about the package to the PTS that would list it in the web or answer it through a mail query. No central repository of any vcs is required. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/28/06, Mario Iseli [EMAIL PROTECTED] wrote: Hi there, (...) I imagine if we would have a big CVS tree like Gentoo or some BSD's, i wouldn't know where to begin with my work or what I sould do. The forest is so large and you don't see the tree! I don't think we need a central approach, every maintainer or group of maintainers is free to use svn, bzr, whatever with Debian infrastructure or not. It would be good if the maintainers pointed out the vcs they're using, and its url through PTS. *BSD are a different and smaller beasts in this matter and what about when their cvs repositories are offline? :-) regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/28/06, Adeodato Simó [EMAIL PROTECTED] wrote: * Gustavo Franco [Fri, 28 Jul 2006 14:38:52 -0300]: * Promote NMU LowThreshold wiki list giving it some official status. And remember that (well done) NMUs are not only for bugs of RC severity. For example, I'm going to upload to 7-delayed a fix for #368917, sending the patch to the BTS at the same time. Yes, i agree. My point was that we can do the promote NMU LowThreshold thing before Etch, and after that do more intrusive changes in the way we maintain packages, that involves ban the NMU concept, except for groups or groups of groups maintaining packages. regards, -- stratus
Re: package ownership in Debian
On 7/28/06, Joerg Jaspert [EMAIL PROTECTED] wrote: On 10729 March 1977, martin f. krafft wrote: also sprach Matthew Garrett [EMAIL PROTECTED] [2006.07.28.1737 +0100]: If Debian had slightly less of a culture of Keep your hands off my package, I'd do it here instead. I've been thinking about this a lot for the past week. Is there any way this could be changed? Simply change the NMUs to be always 0-day, for all bugs =normal. Which means - upload and mail to BTS at the same time. And such dumb rules some maintainer have like never touch my package get ignored - if it complains it should do a better maintainer job... Does Debian *want* it changed? I wouldnt like to be forced to team maintenance. Did you see my suggestions? I think adding your '0day NMU for all bugs = normal' idea for non team maintained packages would do. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/28/06, MJ Ray [EMAIL PROTECTED] wrote: Joerg Jaspert [EMAIL PROTECTED] wrote: Simply change the NMUs to be always 0-day, for all bugs =3Dnormal. Which means - upload and mail to BTS at the same time. Would that mean we get BTS+NMU tennis instead of BTS tennis, where differences of opinion over what is a serious bug result in 0-day NMUs as well as BTS reopens? The key trouble is that non-maintainers are often not familiar with the history of the package and the difficult decisions which have been taken and some don't bother to follow the references given in the changelog. Meanwhile, there's some pressure not to make the debian dir so verbose it includes transcripts of key discussions. That's right, but we're not talking about me uploading stuff to fix the kernel, for example. There's a team and i'm not in that team, so it makes no sense i jump the gun and upload the kernel to fix a = normal bug. It isn't that easy to figure out at first, but if well written somewhere (policy? developers reference?) could work. I'm not sure what the solution is, but 0-day always seems a big step backwards for Quality Control. More co-maints seems a better idea as a step forwards. 0day for = normal bugs, maybe and just maybe is a step backwards for QA in sid, but who knows for sure if the final result won't be better? It includes our upcoming releases, and the motivation of developers encouraged for work more cooperatively and ban the my packages, my stuff, don't touch them! concept. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/28/06, Pierre Habouzit [EMAIL PROTECTED] wrote: Le ven 28 juillet 2006 22:40, MJ Ray a écrit : Joerg Jaspert [EMAIL PROTECTED] wrote: Simply change the NMUs to be always 0-day, for all bugs =3Dnormal. Which means - upload and mail to BTS at the same time. Would that mean we get BTS+NMU tennis instead of BTS tennis, where differences of opinion over what is a serious bug result in 0-day NMUs as well as BTS reopens? […] I'm not sure what the solution is, but 0-day always seems a big step backwards for Quality Control. More co-maints seems a better idea as a step forwards. I've seen more problems of bad maintainers with bad packages, than of irrevertible broken NMUs. Yes shit happen, but well, if you don't move, things rot, which is not much better. Yes, and we need to remember that we're talking about broken stuff in sid that shouldn't hurt too much. do you know a thing that could benefit from that ? - unofficial ports (kfreebsd e.g.) for whom it's a real PITA to have their patches (often of *excellent* quality) to get it. - theming squad (yeah, debian is the sole distro in which the desktops don't have some kind of homgenous look, making it utterly horrible for the newbie) that would just have to integrate their themes, icons, in the right desktop packages. - transitions: I'm the menu packager, I want to change how some option of menu files are handled, no problem, I go to the lintian lab, lists all the packages that will have to be fixed, and DO AN UPLOAD FIXING THEM AT THE SAME TIME instead of waiting for some 2 or 3 lazy maintainers that will apply that only 4 monthes later (did you noticed the /usr/doc transition is still NOT over ?) and I'm sure you can make an arm long list just thinking for a couple of minutes. Great use cases for this proposal! Btw, while we're at this theme stuff. There's desktop-base that i would like to push forward with some consensus between pkg-gnome, pkg-kde and xfce maintainers at least. I started some work on the package but need to try organize a online meeting about this with the parties involved. If you're interested in this, contact me off list first please. Just think how smooth the g++4.1 transition was. Why was it ? because tbm took all the buggy packages, waited 4 or 5 days for the maintainers to fix them, or show they were active about that, and NMUed the rest. I've never ever seen a more clean and quick transition in debian. TTBOMK nobody even tried to complain. But I also think that nobody dared to because it was tbm. Would a random DD have tried the same thing, that wouldn't have been *that* easy. Agreed, and glad he did that. regards, -- stratus
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On 7/28/06, Loïc Minier [EMAIL PROTECTED] wrote: On Fri, Jul 28, 2006, Pierre Habouzit wrote: Moreover, not having strong maintainership in Ubuntu lead to some obscure package to be completely neglected, and some are in a not satisfying shape. I attribute that to the fact that nobody is really responsible for the package if eventually nobody cares about it. If you think about this, it is a good thing: people spend their time on fixing issues that seem important to them, across all packages. Right now in Debian, each maintainer fixes issues he/she considers important in his/her packages, sometime maintainers are allowed to fix very important issues in packages of other maintainers. I think the Ubuntu model will sort bugs distribution-wide instead of per co-maintained packages group. I agree, but we need to keep in mind that Ubuntu has less officially supported packages (the main section) and the others are in universe section, supported by volunteers like us, that work on (almost) whatever thing they think is ok. What we need is list these black holes in the distribution and keep it out of stable. If nobody cares and nobody uses, removal. If nobody cares and just a few are using and it's buggy, no way for stable. regards, -- stratus
Re: package ownership in Debian
On 7/28/06, Daniel Baumann [EMAIL PROTECTED] wrote: Gustavo Franco wrote: For existing packages: * The package that contains only the Maintainer field with the name of a person and not a group can be uploaded by any DD. ping the current maintainer is good but not required; then I will have to found a 'these-are-daniels-packages'-group consisting only of me? *scnr* :) I meant with group of maintainers, number of uploaders 1. Joerg Jaspert said that he wouldn't like to be forced to team maintenance and suggested 0day NMUs for = normal bugs with current rules (patch to the bts), so if you add this rule to my suggestion, i think it's better than 'ping not required', would be better than now too. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/28/06, Simon Richter [EMAIL PROTECTED] wrote: Hello, Gustavo Franco wrote: * The package that contains only the Maintainer field with the name of a person and not a group can be uploaded by any DD. ping the current maintainer is good but not required; I propose that under that policy, if someone NMUs a package without clearing the patch with the maintainer first, that person is responsible for the package until the maintainer acknowledges or reverts the NMU. The rule of sending a patch to the BTS and giving a bit of time to reply serves quality assurance more than it hurts, because you get a second opinion, from a person who is familiar with the package. I reverted my opinion, agreeing with Joerg's idea. The core stuff will be more flexible and well maintained, if we don't have groups where just one person do all the work and others are there just to look cool. But that is exactly what happens if you force group maintenance on everyone. Only that within a group, you cannot even point at somebody and say they are responsible for anything. Every group has at least one admin. I was talking about avoid one-working-man groups. You always can blame the group and the group admins. Don't we blame ftpmasters and their members ? XSF ? same deal. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/29/06, Adeodato Simó [EMAIL PROTECTED] wrote: * Gustavo Franco [Fri, 28 Jul 2006 18:01:26 -0300]: I've seen more problems of bad maintainers with bad packages, than of irrevertible broken NMUs. Yes shit happen, but well, if you don't move, things rot, which is not much better. Yes, and we need to remember that we're talking about broken stuff in sid that shouldn't hurt too much. No, no, no, no, no, no, no. No. No cookie for Gustavo. NMUs are to be done as if you'd be uploading to proposed-updates (e.g. in the amount of testing you've give them). Ideally, all uploads would get that amount of testing. I'm not saying that this is ok break stuff in sid. I said that it was the result in the worst case scenario, ok? regards, -- stratus
Re: package ownership in Debian
On 7/29/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006 14:11:03 -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] said: On Fri, 28 Jul 2006, martin f krafft wrote: also sprach Matthew Garrett [EMAIL PROTECTED] [2006.07.28.1737 +0100]: If Debian had slightly less of a culture of Keep your hands off my package, I'd do it here instead. I've been thinking about this a lot for the past week. Is there any way this could be changed? Yes, and we could start by really enforcing co-maintainership. Make it 100% mandatory for all essential, required and base packages at first. Err, I am not sure co-maintaining packages actually unequivocally improves packaging quality or response times. There are teams that work well for a packagfe, and then there are packages where team maintainence has not worked out. It won't improve packages from the first day, but in my experience it has improved the way i can communicate with people. It's easier for me talk with a member or two in a group and sometimes join them temporarily and help. The one-man approach, when this one-man is a freak hurts the project, and when the person is sane and the package(s) needs more work, you end with a group maintanance even if itsn't official. You wrote that there are teams that work well for a package, and then there are packages where team maintenance has not worked out. These packages where team maintenance has not worked out were well maintained by one person before or what? If not, i disagree. Co-maintainers are much closer to what is being done in a package than joe-random developer. Also, co-maintainership is far less prone to fire-and-forget uploads that hose things, and are nicer to people who feel very strongly about their packages. Co-maintainerships require communication, and ability and desire to share decisions, can result in a culture of it is someone elses problem (neat aphorism in german, I believe), and if the team does not trust one of the members, then things can turn ugly. Sometimes, too many cooks do indeed spoil the broth. I think the debian-installer guys can tell you otherwhise. IMO, if we could reach a better level of resilience, lower response times, and agility with co-maintainership, it would be better than going to the extreme Ubuntu did. I am not yet convinced that that is the case universally, especially if you force people to work in teams. Hello, i thought Debian project was a big team. If people here don't want to work in a team, we're going nowhere. I think that force is the wrong term, we should encourage and in some cases require to avoid single point of failure, IMHO. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/29/06, Adeodato Simó [EMAIL PROTECTED] wrote:
* Thomas Viehmann [Fri, 28 Jul 2006 23:40:19 +0200]:
If that is wanted, I'd consider it important enough information to have
it in debian/control.
A couple packages of mine ship already with an X-VCS-Bzr header in the
source. Example:
(Format: X-Vcs-${VCS}: ${URL})
X-Vcs-Bzr: http://people.debian.org/~adeodato/code/packages/taglib
Another, perhaps more parseable format, would be:
X-VCS-Url: ${VCS}:${URL}
X-Vcs-Url: bzr:http://people.debian.org/~adeodato/code/packages/taglib
Though you'd had to wonder what you'd do with a svn:// url.
Looks good, but i think we could write a proposal for new headers to
address 'vcs' and 'homepage' needs, or add it somewhere else and sync
(like we do with Tags). Thoughts?
regards,
-- stratus
Re: Debian Server restored after Compromise
On 7/13/06, Bas Zoetekouw [EMAIL PROTECTED] wrote: Hi Martin! You wrote: Debian Server restored after Compromise Kudos to debian-admin for sorting out the situation so quickly! Yes! An investigation of developer passwords revealed a number of weak passwords whose accounts have been locked in response. That's not good. Should we maybe implement a stricter password policy? Or maybe only allow pubkey ssh authentication? I agree. pubkey ssh auth only, at least in servers with some core services. I think the servers to support porters can be more flexible, their downtime could hurt just one port and won't taint other services nor the archive - not that this happened with gluck. Btw, the exact compromised account was identified and locked too? regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update on compromise of gluck.debian.org, lock down of other debian.org machines
On 7/13/06, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frans Pop [EMAIL PROTECTED] Should a check/review be done of recent (staring from the date that first account was compromised I would guess) uploads where those keys were used (even if only by the involved DDs themselves)? Do we have any easy way of locating all recent uploads signed by a particular key? Used to be at[0], but you can still do by name. [0] = http://qa.debian.org/developer.php regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am ashamed to be a Debian user.
On 6/15/06, GNAA Jmax [EMAIL PROTECTED] wrote: This is exactly the sort of hate i expected from the debian community. I feel ashamed to be a debian user, as though I have betrayed my brothers and sisters by giving into your hate. I shall not tolerate this, and will be considering legal action against the Debian group under the equal rights act of 1964. Dear Jonathan, Which sort of hate? You've not mentioned in your message what's your point really or in other words what's the source of your anger. You can't sue me, but if you lived in my country i could, so calm down and make your point clear first, please. Thanks in advance, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: irc.debian.org
On 4/30/06, Steve McIntyre [EMAIL PROTECTED] wrote: I've heard it suggested by a variety of people that we should move the official irc.debian.org alias away from freenode to oftc. I can see that more and more of my own Debian IRC discussions are on oftc, to the extent that I'm (currently) not on any freenode channels at all. On another front, oftc is also a sister org under the SPI umbrella. Thoughts? I agree with the move, but to avoid confusion i would like to recommend announce it at least a week before, through debian-announce mailing list. Thanks, Gustavo Franco - [EMAIL PROTECTED]
Re: Reforming the NM process
On 4/11/06, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: (...) 3. Conclusions == (..) I'd like to implement the proposals I made in (2.1) and (2.2) as fast as possible, especially applying the rules in (2.2) to people already in the queue waiting for an AM. (2.3) is, as I said, a long-term thingy - it would be nice if it could happen at some point, but many details are not yet worked out, the infrastructure needs to be changed for it and we really need to decide if this is actually a good way. I agree with 2.1 (Multiple advocates) and in part with 2.2 (Requiring (more) work before applying). In part because it will help us block some newcomers that aren't really into it, but we've some problems already and starting the changes requiring more stuff from everybody will discard more valuable contributors too! I strongly disagree that 2.3 is a long-term thing. It should be started years ago, but it isn't too late yet. We should push it with a transition plan in mind (e.g: what we're going to do with the people that is already waiting for DAM?), but the transition couldn't require (more) work before applying, IMHO. We should block not really interested people giving less privileges for those who do less as you pointed out and be good with MIA and its procedures. I step in to help writing a 1-year transition plan and contact the people that needs to accept/reject some points, if you want. Thanks, -- stratus
Re: Reforming the NM process
On 4/11/06, Benjamin Mesing [EMAIL PROTECTED] wrote: Unless you are not planning to have long term second class developers Make this: Unless you are planning to have long term second class developers No, no, no. Give someone the rights to vote or upload something for Debian isn't consider him second class developer, he/she won't be a developer (yet) ! It means that we will give enough privileges for those that wants to do X or Y tasks, e.g.: don't blocking Joe that just needs to prepare the packages of his two interesting tools, and knows how to prepare packages. Something that is being requested for ages. I think we need a better expression to call these new contributors. 'developers', 'new maintainers', 'mantainers' and probably just 'contributors' are too bad for this now. It's a interesting subject, but i'm going too away from the original topic. -- stratus
Re: Reforming the NM process
On 4/11/06, Raphael Hertzog [EMAIL PROTECTED] wrote: On Tue, 11 Apr 2006, Gustavo Franco wrote: I strongly disagree that 2.3 is a long-term thing. It should be started years ago, but it isn't too late yet. We should push it with a transition plan in mind (e.g: what we're going to do with the people that is already waiting for DAM?), but the transition couldn't require (more) work before applying, IMHO. We should block not really interested people giving less privileges for those who do less as you pointed out and be good with MIA and its procedures. I step in to help writing a 1-year transition plan and contact the people that needs to accept/reject some points, if you want. I don't understand what you have written. Can you reformulate it ? In short it's: Let us start with the long term ASAP, considering what we need during this transition. A long term plan can happen shortly if someone does it, but the change mentionned in 2.3 involve many people and as thus will required a great deal of coordination work. I agree. That's why Mark called it long term IMO. But with Anthony's recent blog post, I'm sure we'll start going into this direction. http://azure.humbug.org.au/~aj/blog/2006/04/12#2006-04-11-maintainers Interesting post. I disagree with the term Debian Maintainer, i think we can get rid of that with the old NM process. If the person has rights to vote or translate (considering a special infrastructure to do that in the future) what will be the term? I suggest Debian Uploader, Debian Translator, ... We can call Debian Developer or Debian Maintainers the person with full privileges, IMHO. Consider that new maintainer should be the DD candidate, at least during the transition. Thanks, -- stratus
Re: uol.com.br and petsupermarket
On 3/14/06, Lars Wirzenius [EMAIL PROTECTED] wrote: ti, 2006-03-14 kello 01:57 +, MJ Ray kirjoitti: Debian contributors are being cost time and money dealing with UOL's crap anyway. The cost of having to delete an autoreply message for every mail you send to -devel is not so great as to warrant kicking out Debian contributors from Debian mailing lists. Get a life. http://foldoc.org/?get+a+life I agree. By the way, a UOL dns admin replied me fast (maybe the message in portuguese did the trick, lol) and hopefully the security team will contact me too. I'm trying to reach them through different ways so we'll see if it can be solved soon. -- -- stratus
Re: uol.com.br and petsupermarket
On 3/14/06, Lars Wirzenius [EMAIL PROTECTED] wrote: ti, 2006-03-14 kello 11:28 +, MJ Ray kirjoitti: Lars Wirzenius [EMAIL PROTECTED] The cost of having to delete an autoreply message for every mail you send to -devel is not so great as to warrant kicking out Debian contributors from Debian mailing lists. Get a life. I feel you're being unreasonably hostile. I don't think I am being unreasonably hostile. Hostile yes, unreasonably so, no. I freely admit that I am being hostile, because you are defending collateral damage from an action that has no actual benefit and does not help solve the problem. Getting uol.com.br customers to react could have been achieved by other ways; hurting them is unlikely to get them to co-operate. Please, calm down. I agree with liw when he says that getting uol.com.br customers to react could have been achieved by other ways. The listmasters could ask the brazilian developers for example. I'm one and i'm already in contact with UOL and no, i've nothing to do with UOL customers. Posting to -devel already brings one a certain amount of spam. Anything that reduces that will make posting to -devel more attractive and help improve communication in the project. Kicking people off Debian lists without proper reason is really, really bad for the project. Much worse than a single autoresponse message that is easy to filter off, until it can be stopped. Since the uol.com.br ban has no practical results and the listmasters knows that i'm trying to solve this, i would like to suggest to remove the uol.com.br ban. (...) Thanks in advance, -- stratus
Re: uol.com.br and petsupermarket
On 3/13/06, Anand Kumria [EMAIL PROTECTED] wrote: Hi, (...) That means that as of now, uol.com.br are now considered spam addresses and anyone with that address (uol.com.br) has now been unceremoniously unsubscribed[1]. Perhaps this action will prompt some kind of response from the powers that be at uol.com.br; but the listmasters are not holding their breath. Hi Anand, Why every uol.com.br address was unsubscribed and not only petsupermarket, AFAIK there's no general problem with that domain, right ? Unfortunately, you've unceremoniously unsubscribed at least a Debian and GNOME contributor. It's clear for me that he can subscribe with other address but this blacklist approach for uol.com.br users makes no sense, IMHO. Can you consider this again ? Thanks in advance, -- stratus
Re: uol.com.br and petsupermarket
On 3/13/06, Matthew R. Dempsky [EMAIL PROTECTED] wrote: On Mon, Mar 13, 2006 at 02:19:55PM +1100, Anand Kumria wrote: That means that as of now, uol.com.br are now considered spam addresses and anyone with that address (uol.com.br) has now been unceremoniously unsubscribed[1]. I am still receiving those obnoxious messages in response to my posts to debian-user. I see, and it's just other reason that this unsubscribe thing not worked as the listmasters thought. I would like to suggest that they unsubscribe the original email address that is forwarding the messages for [EMAIL PROTECTED] and blacklist [EMAIL PROTECTED] only. After that, subscribing again the others @uol.com.br address will not hurt anyone. Thanks, -- stratus
Re: uol.com.br and petsupermarket
On 3/13/06, Lars Wirzenius [EMAIL PROTECTED] wrote: ma, 2006-03-13 kello 17:53 -0300, Daniel Ruoso kirjoitti: I would recomend sending a private message for those who have this stupid antispam asking them to remove or just killfile him or disable him from receiving messages until he remove this crap. The problem is, and has been all the time, that it has not been possible to identify who the subscriber is. If it were, only that address would have been unsubscribed. In December the Debian listmasters sent a mail to every subscriber to see if that would help track down the offender, but it seems not. Rumor also has it that the ISP has not been helpful in identifying culprit. (For the record, I think unsubscribing all uol.com.br subscribers was not a helpful thing to do.) Exactly, and it just changed things for worse, removing from our lists Guilherme Pastore (for example) that is a Debian and GNOME contributor. Btw, i'm trying to contact a UOL sysadmin (i'm from other ISP in Brazil) but it won't be that easy as you already know. -- -- stratus
Re: uol.com.br and petsupermarket
On 3/13/06, MJ Ray [EMAIL PROTECTED] wrote: Gustavo Franco [EMAIL PROTECTED] Hi Anand, Hope you don't mind me replying. You sent this to -project. Why every uol.com.br address was unsubscribed and not only petsupermarket, AFAIK there's no general problem with that domain, right? [...] The Challenge-Response system appears to be a uol.com.br service and there seems no way to detect externally which users are using it. I don't know what proportion of @uol.com.br use it. Do you? Yes, it's their service and the C-R thing sucks. I'm not using @uol.com.br but that's not the point, see below. See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355684 Bug report that triggered the unsubscribe, but apparently not the first time @uol.com.br users have been C-R spamming. http://kmself.home.netcom.com/Rants/challenge-response.html Challenge Response Anti-Spam Systems Considered Harmful http://lists.debian.org/debian-user/2003/08/msg00338.html Earlier version posted to debian-user Good research really, but do you see that [EMAIL PROTECTED] isn't subscribed in our MLs ? It's other address that is forwarding to [EMAIL PROTECTED] The mass-unsubscribe side effect here is that we're hurting users when [EMAIL PROTECTED] is still free to mail our lists. What's the rationale ? Force uol users after unsubcribe them to ask their ISP send a reply for Debian ? -- -- stratus
Re: uol.com.br and petsupermarket
On 3/13/06, Adrian von Bidder [EMAIL PROTECTED] wrote: On Monday 13 March 2006 04:20, Anand Kumria wrote: That means that as of now, uol.com.br are now considered spam addresses and anyone with that address (uol.com.br) has now been unceremoniously unsubscribed[1]. Just curious: how many accounts where these? I have blocked quite a bit of .com.br in my own filters already, and uol rings a bell, I suspect I've already seen it in spam a few times... Do you really agree that unsubscribe every uol.com.br address was a good thing? -- stratus
Re: uol.com.br and petsupermarket
Hi listmasters, Can you send a message to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] and me explaining the problem ? If you already did, please forward to me the original message. Thanks in advance, -- stratus
Re: uol.com.br and petsupermarket
I've just mailed a person in UOL, but i still need a better technical contact that probably i'll obtain through a nic.br person until the end of this week. If the listmasters or somebody else has a good summary that was already sent for UOL, please forward it to me. Thanks, -- stratus
Re: uol.com.br and petsupermarket
On 3/13/06, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Tue, 14 Mar 2006, Anand Kumria wrote: On Mon, Mar 13, 2006 at 02:12:12PM -0600, Matthew R. Dempsky wrote: On Mon, Mar 13, 2006 at 02:19:55PM +1100, Anand Kumria wrote: That means that as of now, uol.com.br are now considered spam addresses and anyone with that address (uol.com.br) has now been unceremoniously unsubscribed[1]. I am still receiving those obnoxious messages in response to my posts to debian-user. Thanks for the information Matthew, that narrows it down to 475 candidate addresses. However we never anticipated that unsubscribing uol.com.br subscribers would rectify the problem -- esepecially immediately. Just 475? How come? weird number, maybe they've left only 475 candidates from the -user (last probe) ? -- stratus
Re: uol.com.br and petsupermarket
On 3/13/06, Martin Schulze [EMAIL PROTECTED] wrote: Gustavo Franco wrote: I am still receiving those obnoxious messages in response to my posts to debian-user. I see, and it's just other reason that this unsubscribe thing not worked as the listmasters thought. I would like to suggest that they unsubscribe the original email address that is forwarding the messages for [EMAIL PROTECTED] and blacklist Err... Did it ever occur to you that listmasters were not able to find out which subscriber is forwarding mails to petsupermarket? Not really until Anand explained it to me. Please provide a means to determine this particular address. I think i'm helping the listmasters with this step right now. The others can stop the insults (it isn't with you Joey), i would like to see your reaction in d-d-a after a listmaster unsubscribe you from a Debian ML. for those who care seems to be the default approach, no ? Closing, i'm just a Brazilian DD, i'm not a UOL customer and i'm trying to help. I replied the listmasters here because they sent the announcement in -project. I give my opinion about how it was handled and heard feedback, i've contacted folks and we will see if it can be solved in a better way. If you are replying here or is planning to do just to be rude with others and make a new flamewar, stop! Feel free to inform your opinion but keep in mind that we're not retards. -- Thanks, -- stratus
