Re: Debian Quiz game
On Thu, October 2, 2014 11:45, Lucas Nussbaum wrote: It would be great if a team could magically form to maintain it as a Debian package. I'm Ccing people who already expressed interest in helping with this, but feel free to just join the fun! Maybe this fun Debian Quiz could also serve as some inspiration: https://www.df7cb.de/debian/quiz/ Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7a6149ee432d3141f57f38e205f129af.squir...@aphrodite.kinkhorst.nl
Re: Can I donate in bitcoin?
On Wed, August 27, 2014 04:54, martin f krafft wrote: also sprach Russ Allbery r...@debian.org [2014-08-26 19:43 -0700]: I believe Debian's major expenses are Debconf, team meetings (mostly travel and possibly some lodging and food), and computing hardware. I would be surprised if Bitcoin were useful for the first two. The latter seems likely to have the most potential to take Bitcoin. The benefit of using Bitcoin for DebConf and sprints is to be able to reimburse people without the costs of cash or international money transfer. This is, in fact, one of the main ways I could see Debian use Bitcoin. I doubt whether such transaction costs are really a significant part of Debian's expenditures. From my locale I know that transfers within the eurozone are already free. But probably Lucas can answer this. (One thing that's inconvenient is that nowhere on debian.org can I find even a high level report / yearly statement of what Debian spends its money on.) The question about where to spend them on is a question on whether to keep Bitcoin or convert it immediately. However, to the original question of whether to accept Bitcoin, I say a full yes. Debian should make it as easy as possible for people to donate to us. People want to support us, we should be grateful and make this at least a hassle for them as possible and align maximally with their wishes (of course informing them about drawbacks, e.g. transaction costs, of certain options over others). So if there is significant demand to be able to make such donations, we should accept them. In fact, it's quite a pity that Debian's donations page is really not inviting to donate; with much text, including a piece of history on early Debian finance, expresion of hope for company donations, a statement that we can't buy our own hardware (?), a link to a very unwieldy form on the SPI donation page and no option for Paypal except through the Italian TO whose website is in Italian. When people come to this page, they want to know how to give to Debian as efficiently for them as possible. These are the options, transfer your money to this account, send checks there, Bitcoin to there, click here for Paypal. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4e98b46f8676e50f96b9bcab9fb72545.squir...@aphrodite.kinkhorst.nl
Re: Pro-ftpd 1.3.3a
Hi Juan, On Mon, June 16, 2014 20:35, Juan Barrera wrote: My name is Juan Barrera. I am a security analyst at Trustwave. I am looking for information about whether or not Proftpd-1.3.3a is going continue receiving support. Visiting: https://www.debian.org/News/2014/20140424 says that Debian GNU/Linux 6.0 (code name squeeze) will continue receiving support until February 2016. However, it does not say anything about continuing support to this specific package. Can you please point me in the right direction so I can obtain more information about that fact this version (Proftpd-1.3.3a) is out of date and needs to be upgraded to the most current one? In principle all packages in Debian squeeze are subject to long term support without a number of explicitly excluded packages of which ProFTPd is not one. Debian tracks security vulnerabilities in the Security Tracker. According to this tracker, there are no open issues in ProFTPd in Squeeze: https://security-tracker.debian.org/tracker/source-package/proftpd-dfsg If you believe this information is correct, you can report this to the relevant people; how to reach them is listed at the reporting problems link at the bottom of that page. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3481e8267e82fc8b2abbbd377b164e7e.squir...@aphrodite.kinkhorst.nl
Re: Debian squeeze/LTS
Hi René, On Thu, June 12, 2014 10:54, René Bleisch wrote: Hi, are there any news concerning the planned LTS of Squeeze? (How to get it and so on) I'm quite a bit frustated: * there were no more news since 26. April. * the standard support has ended by 31.May (no news about it ?!) Squeeze LTS is currently fully active. The starting point for how to use it is https://wiki.debian.org/LTS . A news item for the Debian announce list is in preparation. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/007d655dda36192a682228b454b4d0e4.squir...@aphrodite.kinkhorst.nl
Re: 20140407 keyring report
On Sun, April 20, 2014 06:12, Gunnar Wolf wrote: Kurt Roeckx dijo [Sun, Apr 20, 2014 at 12:51:45AM +0200]: On Sat, Apr 19, 2014 at 09:41:40PM +, Clint Adams wrote: Upon request. Made with an unpackaged set of keyrings[0]. Thanks for the update. (...) So we seem to making some progress, and I hope the rest will follow soon. Yes. March and April were happy and busy months for keyring-maint. Late-April has lost quite a bit of speed. I hope we can get traction again! IIRC, we have ~6 pending requests right now (I haven't done any keyring work this past week). I think it has been suggested earlier in related discussions that a cleanup of long time inactive DD's may make a rather significant dent in the number of 1024 bits keys. Is this something you're considering? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c26d795a0305d3631fdf5e89621a1a5a.squir...@aphrodite.kinkhorst.nl
Re: systemd bad press? score card?
On Mon, February 10, 2014 18:26, Daniel Pocock wrote: http://www.itwire.com/opinion-and-analysis/open-sauce/63079-debian-init-system-vote-has-become-a-farce finishes off with the line And users are still expected to take this lot seriously. Not really objective journalism Even if objective journalism would actually exist, the article is clearly marked as an opinion piece. Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/439b765e8f317a77dc506c4aff391384.squir...@aphrodite.kinkhorst.nl
Re: link removal
Hi Peter, On Fri, January 10, 2014 02:45, link master wrote: My name is Pete Crisaf and Im getting in touch on behalf of our company www.dzineit.net .We noticed that youve linked to our website on your page with the text (new york web design) and am requesting that you remove the link.Im asking this because its come to our attention that some of the links to our website have been acquired against Googles Webmaster Guidelines, so its important for us to remove links that are harming traffic to our website. It's sad to hear that some malicious person created a spam account on our forums that, what are the odds, happened to link to your website, damaging your Google reputation. What has become of our world? Rest assured, I have removed the link now. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/80489cc82b70be00a014ff30e43a8010.squir...@aphrodite.kinkhorst.nl
Re: Debian services and Debian infrastructure
On Mon, January 6, 2014 11:38, Stephen Gran wrote: I don't think jumping straight to a solution that puts all of the responsibility for every idea for a service in Debian on DSA shoulders is either the only way to go or even a good way to go. There are plenty of bad ideas that should be allowed to wither on the vine, and there are always going to be services that have been designed in such a way as to be difficult to integrate into DSA-managed infrastructure. We are, after all, a reasonably small team of volunteers. Pretending that we can support an infinite number of services or an infinite variety of designs is just going to end in disappointment for someone. I think this is a good observation. The whole problem does not seem to differ at all from with the tradeoffs that the sysadmin team in a large organisation wherein I work, have to make regularly. New services come to us in a variety of forms: someone just requests functionality and all other decisions are left to us; someone wants us to host a product or is developing a product and consults us early on (those people are the best!); more often someone has already bought or developed some product and it 'just' needs to be hosted. It's always a case by case judgement: how essential is this service? Will this fit in our infrastructure? If not, can we feasibly have it changed so it will? And if not, sometimes it's decided that we will need to host it nonetheless, in other cases we advise to host it somewhere else. The latter is surely an option and it doesn't necessarily mean we completely lose control over it at all. The simple fact that we retain control over DNS is a blunt but effective last resort to anything gone bad. Just like DSA, it's not our job to exclusively host everything that the organisation requires nor is it required that everything that we do end up hosting conforms to our ideal of the perfect service. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f1fda1389bd5e7727d4294a794afe446.squir...@aphrodite.kinkhorst.nl
Re: Need debian lenny source code
Hi Venkatesh, On Fri, December 13, 2013 09:44, Venkatesh Pawar wrote: I am Venkatesh Pawar need a link for debian lenny os source code for some operation purpose. So can you please tell me from where should i download source code of debian lenny os. It will be great help if uou help me. You can put the following in your sources.list to be able to apt-get source packagename on a Lenny system: deb-src http://archive.debian.org/debian lenny main Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/97c8df20a90a24a251e3c5a43cae6848.squir...@aphrodite.kinkhorst.nl
Re: Please update the DSA delegation
On Thu, December 5, 2013 02:15, Ian Jackson wrote: I would go further and say that I think it would be better to do things differently. For a team which is functioning well, it would be helpful if the DPL delegated to the team the authority over its own composition, explicitly reserving the right to intervene. That way there is no procedural problem: there is no question of someone de facto making decisions which de jure they are not empowered to make, or alternatively of having to have people wait for a rubber stamp from the DPL before getting on with useful work. Perhaps it would make sense to first more clearly define problems we want to solve with the whole delegation process, so we then know what kind of process would best address that. I see that currently the process costs the DPL quite some time while at least to me it's unclear what problem it solves for the project. Can we point to a concrete issue in the past few years that we were able to address more efficiently because delegations were in place? There are a number some teams active that perform tasks essential to Debian but are not delegated. Do we see more problems with those teams than with the delegated ones? Sometimes it seems to be bureaucracy for bureaucracy's sake. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e4ea9b8b1b625ddcc4c66b03c2b1e6b1.squir...@aphrodite.kinkhorst.nl
Re: Please update the DSA delegation
On Thu, December 5, 2013 11:46, Lucas Nussbaum wrote: This was discussed in https://lists.debian.org/debian-project/2013/05/msg00018.html. Main points are: * it facilitates the monitoring of the team manpower, which helps taking proactive actions before things get too difficult. * it provides a place to clearly define what are the roles, responsibilities, powers of the team. * it's a rather lightweight process when things work well. It's bureaucratic, yes, but not so expensive bureaucracy. These arguments are all inherently bureaucratic in nature (monitoring, defining responsibilities). That's not bad per se, if it can be justified that this form of monitoring or formal responsibility determination actually solved concrete issues. Since you skipped my request for concrete examples, I'm assuming you also haven't seen such cases :) I find it more likely that monitoring in the sense that people perceive trouble when interacting with a team is much more indicative of a problem than monitoring through the process of updating delegations. I'm not convinced that the work done on all these delegations is a net win. There are a number some teams active that perform tasks essential to Debian but are not delegated. Do we see more problems with those teams than with the delegated ones? Which ones are you thinking about? (the release team is not delegated yet, though this is a long running pending task, and there's a draft already). I'd rather not say for fear of more busywork ;-) Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/76eb12cecd3c0e6f40ffc070f53d36cc.squir...@aphrodite.kinkhorst.nl
Re: Possibly moving Debian services to a CDN
On Wed, November 20, 2013 19:03, anarcat wrote And saying that because there's proprietary firmware in your BIOS it's okay to offload all of Debian's infrastructure to a non-free CDN is okay seems to me to be a slippery slope. Nobody has talked about moving all of Debian's infrastructure. Okay, some. The argument remains: it's still a slippery slope argument. :) The slippery slope argument is often considered a logical fallacy and not without reason. The argument implies that by making choice A we would automatically not be stopping to make the 'worse' choice B, while Debian at any and all moments keeps the freedom to do A and not B. I see your point, although I think there is a few orders of magnitudes between adding improvements to the current mirror infrastructures versus soldering PCBs... Debian's core activity is building the best OS in the world. Distributing the actual result of that is, at least in my opinion, a thing very peripheral to that activity. The fact that Debian has always shied away from making CD's and distrbuting those to users but rather left that to commercial and non-commercial parties, indicates that this is not a novel development. We allow (and promoted) commercial CD services. I see delivery over the network not as a fundamentally different thing than delivery on CD. It's not the thing Debian is necessarily good at. Let us concentrate on the OS building. which are based on a spirit of free access and open knowledge, something commercial CDNs seem to be alien to... I have not seen any indication that commercial CDN's would necessarily be alien to free access and open knowledge, in fact, it would seem rather contrary to their nature to hinder access to content. Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/741f124a517fd73222781224a56f4fcb.squir...@aphrodite.kinkhorst.nl
Re: Possibly moving Debian services to a CDN
On Wed, October 16, 2013 15:01, Stefano Zacchiroli wrote: I do realize that most of the value of a CDN is not in its software parts. But I'm under the impression there is still quite a bit of software behind commercial CDN offerings. So my question is: would the CDN providers we're going to choose be able to ensure that the software parts behind their offerings to us are 100% Free Software? It is of course a good target to strive for, but putting such a demand on a service is probably not fair, because our current distribution system also does not run on 100% Free Software. We do not know what software our mirrors are running (we can make a guess that there will be Debian hosts in there, but just as well we can be quite sure there will be some Solaris or commercial Linux variants) so it's just as opaque as a commercial CDN offering would be. The principled point that everything Debian does should involve 100% Free Software is not the status quo nor is it attainable. We will deliver bits using equipment running Cisco IOS, and we will not have the source of the bank software that processes our donations. The question is therefore: do we consider such CDN services to be more like network- or financial services, which we source externally, or is it a core aspect of developing Debian? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/459f0e787bedca53b8a40256c4050c1f.squir...@aphrodite.kinkhorst.nl
Re: Paths into Debian
On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote: Did you tag them 'gift'? https://wiki.debian.org/qa.debian.org/GiftTag This may just be me, as it's very personal, and no offense intended at you, but I really detest the name 'gift' of that tag and that prevents me from using it. Tagging something 'gift' gives me a really condescending association, where the Big Maintainer has been so kind to hand out a 'gift' of doing work to the little newbie who should be grateful to receive it. Because these are the connotations of the word gift to me: that people should feel happy to receive it, while actually we should be happy if people do work for the project. I realize this is absolutely not your intention in naming this tag and also that it's highly subjective matter. I'm raising it only because it prevents me from using it. If it's just me, than that's that. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/491fcd683b50d2f0d8aa866bd90d4655.squir...@aphrodite.kinkhorst.nl
Re: Authorizing minor expenses by DSA without prior DPL approval
On Wed, August 28, 2013 18:12, Tollef Fog Heen wrote: ]] Lucas Nussbaum I like this idea of max outstanding of $300 instead of an explicit time limit. But I think that your proposal makes it possible for DSA to not get reimbursed if the DPL is grumpy and decides not to approve the expense. I would rather use DPL acknowledgement than DPL approval. First, thanks for pushing this forward, much appreciated. So, new proposal: DSA is allowed to make expenses and get reimbursed by Trusted Organizations for up to US$300 to support the operation of Debian infrastructure (pay shipping costs, purchase of cheap hardware such as cables, replacement disk, etc.). Given we're not buying the cheapest disks we can find (since they have worse warranties, etc), replacement disks quite often ends up at approximately the $300 mark, maybe make the limit $400 or $500? Similar mandates exist in many other organisations, and are often even template by-law text. The one's I've encountered are very much the same. They boil down to a mandate for expenses of 500 euro (this amount seems to be quite constant between different organisations aswell) per incident / purchase / work order, for which no pre-approval is required. The mandate does not remove accountability of course, so if someone bought candy with it or doesn't have a receipt, they're still liable. I don't think anything that Debian does needs to be more complicated than this. After all, the people in those roles are already trusted by the project to do way more important things. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0efb814da70d93c4afee08767459b8df.squir...@aphrodite.kinkhorst.nl
Re: Survey of new contributors -- results
On Wed, August 7, 2013 21:52, Lucas Nussbaum wrote: 22/37 were sponsored as part of a team 10/37 had a friend or colleague sponsor them 5/37 were sponsored as part of debian-mentors Other things mentioned (once): - sponsored by the previous maintainer when adopting a package - sponsored by an Ubuntu MOTU who is also a DD | It seems that your best luck, if your package does not fit in a team, | is to find someone close to you (friend/colleague) that will make the | upload... That's quite sad! I'm not following why these numbers would be sad. People are apparently finding collegues or friends to sponsor them, which seems great, not sad. At work we sponsor non-DD's regularly and this is always a positive experience. I think it's acutally encouraging to read that most people do not need debian-mentors but found teams, friends or collegues to work with them. Such longer-standing relations are, in my opinion, better than the one-off sponsoring that happens on d-mentors. Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ee5ffec1f6c61260f8edc37db393657a.squir...@aphrodite.kinkhorst.nl
Re: PaySwarm-based Debian donations
On Tue, June 18, 2013 04:31, Martin Owens wrote: On Mon, 2013-06-17 at 19:03 -0500, Gunnar Wolf wrote: site requesting user's charity You mean user's involvement. You don't want users to be invited to participate in Debian. Debian isn't elitist and it shouldn't care that the tool being deployed is money rather than time. Money isn't neutral and has specific social effects when it comes into play, that are different from other resources such as time. So we should care. I recommend you (or anyone else for that matter) read What Money Can't Buy by Michael Sandel. It describes very well the unique features that money can introduce into an equation. Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/050a23d1a19b33aaadae0d352c097b81.squir...@aphrodite.kinkhorst.nl
Re: Debating difficult development issues in essay form
Op donderdag 9 mei 2013 23:40:45 schreef Wouter Verhelst: I do agree that sometimes, mailinglists aren't the best possible medium to hold a discussion. However, I'm not convinced that your proposal is the best way to fix that. I think that with all its flaws, mailinglists (and/or usenet) are still the best option we have for discussing important matters. I believe we're already using the form that Lars and Russ described, in the context of GR's. On the mailinglist, people collaboratively construct a short essay that they think rightly makes the case for their option. Others may construct a complete counterpoint, but there's also the form where you agree with the essay but want to change one aspect of it (an amendment). In the GR process these options are then put to the vote and even votes that didn't read all of debian-vote can make an informed decision by reading each of the options put forth that document the motivations. The proposed system seems to work well, and I don't know why it couldn't equally work well when ported to the non-voting-context of debian-devel. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: gravatar on bugs.debian.org - acceptable or not?
On Fri, March 15, 2013 21:03, Simon Paillard wrote: Regardless avatar on/off, I really miss the CSS that used to have a grey background for email headers in BTS. You have an old version of the CSS cached. Use shift-F5 to solve this. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d448444b1c0cde5de1ccdba3d6500f67.squir...@aphrodite.kinkhorst.nl
Re: Copyright assignement for Debian tools?
On Mon, February 11, 2013 14:54, Antonio Terceiro wrote: There are several cases where upstream explicitly puts Copyright 2013 The Foo Developers and similar statements. Are they invalid as well? If they are valid, wouldn't Copyright 2013 Debian Project have the similar (if not the same) meaning? I do not think such claims are invalid: when there's a clear definition of what The Foo Developers means (e.g., it's expanded in a central README file), then its nothing more than a shorthand for the set of people claiming copyright on the work. The actual, legal copyright is in the hands of the people the string expands to. In the case at hand, you could indeed add Copyright 2013 Debian Project but because that doesn't expand to a clear set of legal rights holders, I believe this would not have the desired effect, namely that a single legal entity owns the copyright which then has the possibility to make decisions on that copyright. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f344cfd64e5c9d2358e26806e5afa481.squir...@aphrodite.kinkhorst.nl
Re: mjg59's blog on planet.d.o
On Tue, October 30, 2012 12:38, Jakub Wilk wrote: * Lars Wirzenius l...@liw.fi, 2012-10-30, 09:45: AFAIK Matthew Garrett hasn't been active and directly involved participant in the Debian development community for years. What is the reason for keeping his blog on planet.d.o? Matthew has been blogging frequently over the several past years, and aggregated on Planet Debian. He has, for example, written a lot about UEFI and Secure Boot, and the different ways in which Linux and distributions can handle them. You said nothing then. Now, when he blogs about what Ted Ts'o has said about rape, you react. This sounds an awful lot like you want to remove Matthew from Planet Debian because of his opinions on that issue. You guessed (almost) right. I am fine with active Debian contributors blogging about women's rights. I also occassionally enjoy a high-quality technical posts written by an outsider. I can normally even stand when outsiders blog about non-technical matters. However, I do not wish that Planet Debian syndicates posts that denigrate Debian developers. Matthews blog post at hand is to me in very bad taste. From time to time I see blog posts from DD's in bad taste, even specifically when relating to Debian or indivual developers. Whether someone can exercise good taste, obviously subjective matter, in writing blog posts is not a selection criterion for Planet Debian. And rightly so. Blogs are the perfect place to put content of a highly personal nature. It's clear to everyone that such posts are not endorsed by anyone but the author. I see no problem here to solve. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2b14b376c02e3f13a791dc9fb1b87f2a.squir...@aphrodite.kinkhorst.nl
Re: ditching the official use logo?
On Mon, October 8, 2012 16:52, Paul Tagliamonte wrote: Right now, the way I understand it is that you can, in a DFSG and legal way, create a document with the Debian logo brand, and create a certificate that looks to be from Debian, and sell them as some sort of certification from Debian without recourse from the Debian project. This is possible whether the official use logo exists or not: right now anyone can create a certificate with the open use logo, which is what everyone and their dog recognises as the Debian logo. The current open use licence does not allow you to misrepresent yourself as being Debian. The Cc license summary even mentions prominently that it you may not use it to claim endorsement by Debian: http://creativecommons.org/licenses/by-sa/3.0/ I find it therefore doubtful that keeping the bottle logo solves any real world problem. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1056171940d7b2e660df0eb308ff5bcf.squir...@aphrodite.kinkhorst.nl
Re: ditching the official use logo?
On Mon, October 8, 2012 20:54, Paul Tagliamonte wrote: On Mon, Oct 08, 2012 at 08:48:40PM +0200, Thijs Kinkhorst wrote: On Mon, October 8, 2012 16:52, Paul Tagliamonte wrote: Right now, the way I understand it is that you can, in a DFSG and legal way, create a document with the Debian logo brand, and create a certificate that looks to be from Debian, and sell them as some sort of certification from Debian without recourse from the Debian project. This is possible whether the official use logo exists or not: right now anyone can create a certificate with the open use logo, which is what everyone and their dog recognises as the Debian logo. Sure, but the issue is it's legal with the open-use logo and not legal with the bottle logo, which means we have legal recourse when we use the nonfree logo. The key point is that what the world recognises as the Debian logo is the free logo. We can make certificates with the bottle logo all we want. At the same time anyone can legally another certificate with the free logo. I'd even say that people would more easily trust the free logo to be official than a bottle logo they've never seen before. In any case, it's still illegal to falsely claim that a certificate was officially issued by the Debian project if it wasn't. You don't need logo's for that. That's why I think in practice the bottle logo has no real value because no-one recognises it, and we have better ways to advance Debian than to invest lots of time in marketing to change the public's perception of what is the Debian logo. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d8a09e0e5c15530bb307f18a4dc404cf.squir...@aphrodite.kinkhorst.nl
Re: ditching the official use logo?
On Mon, October 1, 2012 12:27, Stefano Zacchiroli wrote: I haven't touched (nor looked into) the official logo. My impression is that that that logo is massively underused and basically unknown to most of our public out there. My personal take on it is that we should simply ditch it, focusing on a single logo (the open use one) with a DFSG-free license, that we do now have. I agree with the idea of discontinuing the 'official use' logo (remove it from the logo page and/or moving it to the 'other promotional images' section), but not before relicensing it to the same free terms as the 'open use' logo. This would mean that any remaining existing use is hereby sanctioned under the broader terms, or that someone who finds a use for it may to so under free conditions. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/67cac4a3ff8e39315e4f5c7ee6025e4c.squir...@aphrodite.kinkhorst.nl
Re: trademark policy draft
On Tue, August 14, 2012 16:51, Stefano Zacchiroli wrote: I agree with this. In dealing with lawyers on behalf of Debian, I've quickly learned that there are almost never 100% safe or 100% risky positions. It is *always* a cost/benefit/risk analysis. You ask the experts to evaluate the risks of the positions you're interested in, and then you pick a position. It's surely a cost/benefit/risk analysis, but either of them is hard to quantify. We may know how much money we pay to the registration offices (do we?), but there's also the manpower we spend on drafting a policy, processing trademark requests, consuming the time of our legal advisors, etc. And a potential cost in goodwill (being perceived as 'jerky'). The benefit is that we have a legal tool against someone doing something nasty with our name. Which is nice to have, but doesn't come for free. It's hard to quantify as well: the benefit is for a future situation of which we do not know if or when it will happen. Or how many extra costs we need to incur then to actually enforce our trademark in the legal system. Keeping the trademarks has costs, the benefits are uncertain, and there seem to be many examples of projects getting along fine without any. For me the tradeoff is clear. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ba699cde998bc92d936432a64a5c0535.squir...@wm.kinkhorst.nl
Re: trademark policy draft
On Wed, August 1, 2012 18:54, Russ Allbery wrote: Lars Wirzenius l...@liw.fi writes: I'll leave the discussion with this counter suggestion: change the trademark policy to say: We call ourselves the Debian project. You can use our name as long as it doesn't make reasonable people confuse you or your stuff with us or our stuff, or imply that we're affiliated with or endorse you. You can use our logos under the CC-BY-SA 3.0 (US) or later license. So, again, the reason why it doesn't read like this is because we got actual legal advice and the lawyers said that we can't make it read like that. We can choose to abandon our trademark and make it indefensible, but we should do that intentionally and not under an illusion that we're just creating a better usage policy. I would just like to register that I would be in favour of that: just let go of these trademarks, which gains people maximum freedom and creates for us the least policies and the least hassle. And it also saves money. That sounds like a win. Of course there are some imaginable uses of a trademark: to protect against bad guys misrepresenting us. We have to balance this potential future possible benefit against the current costs, policy and hassle these trademarks bring us and more notably people wanting to do good things based on Debian. And factor in the huge costs a lawsuit against a trademark infringer would bring (as I understand it, we would be required to act on any infringement in order not to lose the trademark). Many other projects don't have any trademarks, and to my knowledge are not quite swamped by counterfeit ripoffs. For me the balance tips to the 'no trademarks' side. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bcb59938bbd0461d4797f8cee49cc116.squir...@wm.kinkhorst.nl
Re: RFC - Changing current policy of debian.net entries
On Fri, June 22, 2012 23:01, Martin Zobel-Helas wrote: There is nothing carved into stone yet! I just want to hear your comments on this. The key point is that lay users will not understand the difference between debian.net and debian.org, and we should not require that they do. The purpose of this RFC is to seek comment on how to address this concern and the above proposal is perhaps one such way. I'm not clear why it is problematic that lay users do not know the difference between 'official' and 'unofficial' services. Take mentors.debian.net, perhaps the most visible debian.net service. How is it relevant to lay users whether or not this service is officially blessed? It works great for all parties involved. Whether or not it's blessed is mostly a project internal issue. The Debian security tracker has been on debian.net for years. It has been the canonical tool for anyone working on security issues in Debian. No problem there. (I do see why we want to run important stuff on DSA infrasturcture. But that is a project internal issue and does not really matter for outsiders to decide.) There's a selection procedure for DD's, because we want to be able to trust them to not do weird things when they post with their 'official' debian.org email address, or when they upload any package into the archive. If we can trust them with that, I think we can also trust them to run services in a reasonable manner, or at least not so unreasonable that it's necessary to put big warning signs on them. The outside world does not really care about the difference between debian.org and debian.net, but I do not perceive that as a problem. Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bbc3715a8049916dfa382b7399a5772b.squir...@wm.kinkhorst.nl
Re: Claiming the debian account on GitHub ? (was: Re: Packaging on GitHub ?)
On Thu, June 14, 2012 16:56, Stefano Zacchiroli wrote: On Thu, Jun 14, 2012 at 09:31:39AM +0900, Charles Plessy wrote: I have not added links to their competitors, as I think that it would be bad taste, but yes, I invite every developer to consider Free alternatives such as Gitorious or Branchable. To be blunt, I think that our advocacy for software freedoms is more important than good taste. I'm surprised by this dichotomy. It seems perfectly well possible to both operate in good taste and advocate software freedoms. Given how you worded the README (i.e. along the lines of some of the software we work with is already on GitHub...), it would be entirely appropriate to recommend favoring Gitorious, Branchable or similar services over GitHub. I find this indeed not in good taste. We are using their service, for free. We have many platforms of our own we can use for such advocacy. The current proposal, that we make it clear that usage does not constitute endorsement, makes the situation perfectly clear to anyone without using the free resources we've been given by them to promote their competitors. Cheers, Thijs p.s. I just bought some groceries and the supermarket didn't publish the source code to their cash register, so I may be biased towards non-free services. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f40cbe9858793c4a8945f58601d5d659.squir...@wm.kinkhorst.nl
Re: revenue sharing agreement with DuckDuckGo
On Thu, March 29, 2012 04:27, Paul Wise wrote: Probably you missed the part of the email that says we should add t=debian by default to every new DDG search URL? I would suggest that it should be up to the users what t= should be set to when sending search requests to DDG, not Debian. I'm surprised by the notion that merely sending the string 'debian' to the search engine is construed to be detrimental of my privacy. While indeed hypothetically sharing some bit of information, it's rather high-level information about somebody which I really doubt would influence anyone's life in any meaningful way if it's 'leaked'. Privacy law discerns certain categories of information that require protection (like your home address) and categories that require even more stringent protection (like race or religion). We should obviously strive to do better than the minimum standards of such laws, but the boolean 'is Debian user' (of which there are millions in the world) is in my view far removed from what actually constitutes disclosure worth worrying about. The average request, containing an IP-address, User-Agent and plugin information already discloses so much information about a user's computing environment that my opinion on the DDG-proposal is not at all influenced by the mere fact that it requires adding a t=debian parameter. Someone can know the brand of my bike when parked in front of my house. That doesn't make me uneasy at all. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bf6cd7f5dab285ab82906b37d7a87d49.squir...@wm.kinkhorst.nl
Re: Report from DSA Team Sprint in Oslo
On Tue, March 20, 2012 09:06, Tollef Fog Heen wrote: Shouldn't the various teams handling the group take care of managing them? Do they currently fail at that? I think we can say that yes, they generally fail at asking for people to be removed from groups. I'm still a member of webwml even though I don't think I've committed anything there since 2007 or so. I'm also apparently a qa member, though I can't even remember asking to be put in the group. :-) You may want do consider the extra 'powers' membership of specific groups brings. For example, I've hardly revoked any group membership in the past that serves to give commit access to a repository. Afterall, commit access is usually hardly dangerous: impact is small and inappropriate ones are easily reverted; and it usually helps everyone if someone can make a quick fix for something they ran into because they still have access. So I would advise to only make an effort to 'clean up' groups that have sufficiently 'dangerous' consequences attached to them. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ea010f314e95dbb3d2dc24800b910567.squir...@wm.kinkhorst.nl
Re: Report from DSA Team Sprint in Oslo
On Wed, March 21, 2012 13:16, Clint Adams wrote: On Wed, Mar 21, 2012 at 10:07:30AM +0100, Thijs Kinkhorst wrote: So I would advise to only make an effort to 'clean up' groups that have sufficiently 'dangerous' consequences attached to them. Then logically it would follow that the ones that don't should be gid 800 instead. In some situations I'm talking about there was a slight advantage that upon ingress you could verify that prospective committers were aware of basic procedure. But this is indeed only a minor advantage and a case for gid 800 (or equivalent solutions) could certainly be made for anything that's easily reversible; and we can expect DD's not to go on a commit rampage that takes a lot of time to revert. The collab-maint repository has been available to all DD's for a long while. We've been trying to get the secure-testing repository writable for all DD's, unfortunately the Alioth admins didn't have time to respond to that request yet, but the wish is certainly there. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b34ca52824cf986d67e3cec47587bdf3.squir...@wm.kinkhorst.nl
Re: Security guidelines for Debian people
On Thu, November 3, 2011 18:44, Henrique de Moraes Holschuh wrote: On Thu, 03 Nov 2011, Jakub Wilk wrote: * Lars Wirzenius l...@liw.fi, 2011-10-30, 17:33: Personally, I think some guidelines for DD's about securing their personal machines where their private keys are located would be a good idea. It would be a lot better than just having a vague and ineffable thing called trust. I agree. I offer the following as a first approximation, targeted specifically for key management. * These are meant to provide an idea of the minimal acceptable standard. * Store your master PGP keys on at least two USB thumb drives. This seems to suggest that having multiple copies of the PGP key Multiple *offline* copies, in an encrypted container. This thread reminds me of a Dutch management book entitled Managing Professionals? Don't do it![1]. We shouldn't prescribe how many copies of a key one should keep where in which crypto containers, or whether you should use an USB thumb drive, smart card or a floppy to do it. DD's are technically competent people and are perfectly able to decide what adequate protection for their private key material should look like. They don't need the guidelines for that, in fact, they can do without the associated signal that there's a need that they be micromanaged about this. Indeed, I oppose the assertion that such guidelines are 'a lot better than just having a vague and ineffable thing called trust'. Trusting DD's to do the right thing is an important value for Debian. Thijs [1] 9789055943524 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fe0ef9e4b996b09b1a6a2b960e87ef85.squir...@wm.kinkhorst.nl
Re: Squirrelmail package availability question
Hi Douglas, On Thursday 20 January 2011 16:45:50 g...@ccil.org wrote: I'm curious why only eleven Squirrelmail plug-ins seem to be available as Debian packages: http://packages.debian.org/search?keywords=squirrelmail Specifically, I don't see that the Unsafe Image Rules plug-in is available: http://squirrelmail.org/plugin_view.php?id=98 The reason for this is, like with other things in Debian: it hasn't been done because there was nobody yet that did it. In a volunteer organization things happen when someone sees the need and can spend the time on doing it. In this specific case, there has been a concern in the past that making a package for really small things, like a plugin that's just one short file, would be overkill. But if you ask me, there's always some way to deal with such concerns, and, the real cause is described in the previous paragraph. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: Debian decides to adopt time-based release freezes
On Wed, July 29, 2009 14:24, Alexander Reichle-Schmehl wrote: If you don't like that, don't shoot the messenger, because they might get sick of being shooten at at every occasion; thanks. I think an important critic in this thread is the way the message was brought: DD's like myself are learning of this decision from a press release. Affected teams haven't been asked or even informed beforehand. This is definitely something that the 'messenger' should have considered before deciding to take this route to announce the plan, don't you think? Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Linux System Engineer (100%) in Zurich
On Wed, November 26, 2008 11:12, martin f krafft wrote: You may be 70 and capable to do a job which required me to invest 2 years into you, I'd be with you if the ad required a maximum age that was actually somewhere close to the pension age. Your example does not compare with the arbitrary age limit of 35 years that was mentioned. I know a few Linux System Engineers of above 35 years old, and they would all function fine for the many decades until they reach EOL. but the chance of you waking up dead is far higher than of a 30-year-old. The chance of getting pregnant is remarkably higher for women than for men, and the associated leave is often costly for an employer. Do you think it's fair to preclude females in an ad? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Non Maintainer Uploads (final call for review)
On Friday 22 August 2008 15:49, Lucas Nussbaum wrote: Conclusion: we need a way to version stable/testing uploads that avoids this. While I'm not convinced that it's a pressing issue that needs resolving, if people badly want it I'll use the new system. I think that instead, we should use this conservative choice until the real release number is known, and then switch to the announced release number. If the release team changes its mind, well, we have a problem. But that's probably something we can deal with. As a consequence, I propose the following wording for the paragraph of developers-reference about that: If you upload a package to testing or stable, you sometimes need to fork the version number tree. This is the case for security uploads, for example. For this, a version of the form +debXYuZ should be used, where X and Y are the major and minor release numbers, and Z is a counter starting at 1. When the release number is not yet known (often the case for testing, at the beginning of release cycles), the lower release number higher than the last stable release number must be used. For example, while Etch (Debian 4.0) is stable, a security NMU to stable for a package at version 1.5-3 would have version 1.5-3+deb40u1, whereas a security NMU to Lenny would get version 1.5-3+deb50u1. After the release of Lenny, security uploads to the testing distribution will be versioned +deb51uZ, until it is known whether that release will be Debian 5.1 or Debian 6.0 (if that becomes the case, uploads will be versioned as +deb60uZ. Would that work for everybody? I'm not sure why we can't just agree to set the release number of n+1 before n is released? That would make the proposal significantly less complex. Thijs pgpjD5iLKnH6z.pgp Description: PGP signature
Re: DEP1: Non Maintainer Uploads (final call for review)
On Thu, August 21, 2008 10:33, Steve Langasek wrote: On Wed, Aug 20, 2008 at 01:33:16PM +0200, Thijs Kinkhorst wrote: But perhaps we need another mechanism to signal this. Consecutive uploads to the same distribution should not cause previously present version entries to disappear from the changelog. Maybe the archive can reject an upload that misses a changelog entry that was previously present in the uploads to this distribution. No, this is a terrible idea. If someone uploads a bad NMU of one of my packages, why should I have to reference it at all when superseding it? Neither the archive nor policy should impose such a requirement on me. My concept of the package changelog is to give a chronological account of the changes that happened to the package. When your co-maintainer adds and uploads some patch which you in a later upload decide to revert, you don't edit it out that old changelog entry, but rather add a new entry stating that you reverted patch p because of reason r. Right? I'm not clear why that would be different for NMU's. The changelog primarily documents what changed, who exactly did that is of low importance to the user. When leaving out such changelog entries, I have a version of the package on my system that shows one behaviour, after upgrade another, and then after upgrade the first behaviour again, I would check the changelog and not find anything relevant. In fact, the previous version seems to have disappeared completely. What is the problem with documenting which versions were actually present in the archive? Or with explicitly stating that a change has been undone? That seems like very useful information for users to me. How often does it happen that NMU's are rejected that makes it an unreasonable burden to copy the 10 lines of changelog into yours? Say the NMU'ed fix migrated to testing and the maintainer uploads another fix to unstable, leaving out the changelog entry, testing is marked as affected again which it isn't. That's not true. Testing will only be marked as affected when the maintainer upload reaches testing. Which AFAICS is perfectly appropriate. Good, then I misunderstood how that worked, sorry. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Non Maintainer Uploads (final call for review)
On Wed, August 20, 2008 14:14, Raphael Hertzog wrote: Say stable and testing have 1.0-1. Sid has 1.0-2. stable-security has 1.0-1+etch1 The maintainer wants to upload something to t-p-u. If we had a codename that sorted before etch we would be screwed. I don't think we're screwed, rather that we need to use a custom solution in a rare case, which I don't find objectionable if it means we can keep a working system for the vast majority of existing cases. Of course changing it is not the end of the world but I'm not quite convinced it's a needed change. Still, I think that the deb41=5.0 point is a real regression to the current system. If we can solve that I'm not objecting to changing the scheme if people so desire. So if we can just agree that the version number of Debian n+1 will always be decided before the release of n, my most important concern is addressed. Can we do that? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Non Maintainer Uploads (final call for review)
On Wednesday 20 August 2008 10:06, Lucas Nussbaum wrote: On 20/08/08 at 09:38 +0200, Raphael Hertzog wrote: On Tue, 19 Aug 2008, Thijs Kinkhorst wrote: The past weeks I had several encounters with the situation that a maintainer completely overlooked and NMU and uploaded a newer version without acknowledging the previous NMU, thereby reintroducing the problem the NMU addressed. This happened to active maintainers. At least the BTS automatically reopens the bugs so the problem doesn't stay unnotified and untracked. It doesn't really reopen the bug. But the BTS version-tracking allows to find out that the bug is not fixed in the new maintainer upload. That has the drawback of not notifying the maintainer explicitly directly after (or even before) the upload. But perhaps we need another mechanism to signal this. Consecutive uploads to the same distribution should not cause previously present version entries to disappear from the changelog. Maybe the archive can reject an upload that misses a changelog entry that was previously present in the uploads to this distribution. The NMU changelog entry should always be there, else the BTS will start to display incorrect information. Say the NMU'ed fix migrated to testing and the maintainer uploads another fix to unstable, leaving out the changelog entry, testing is marked as affected again which it isn't. It works well except when the same package version is in two consecutive release. 1.0-1+sarge1 1.0-1+etch1 when we really want the opposite. That's why this scheme was invented. I agree that it's not very nice though but i couldn't find anything cleaner. Clean is of course subjective, I find the codename scheme cleaner than a scheme where 41 means 5.0. The situation you name has as far as I know not occured in any recent times so it seems you're trying to solve an hypothetical problem. And if it occurs we can deal with it in that rare case individually rather than devising a more complex scheme around a situation that hardly happens, right? Actually, for lenny, we could just have used +deb41 until the release team announced that Lenny would be 5.0, and switch to +deb50 at this point. If the release team doesn't change its mind, it's fine. Is there a reason why we couldn't decide on that version number of n+1 before the release of n? Then we can always use the right number right from the start and the scheme gets quite less convoluted to me. Thijs pgpq5WkWGaj4O.pgp Description: PGP signature
Re: DEP1: Non Maintainer Uploads (final call for review)
Hi, Sorry for breaking the thread and chiming in late, I was until recently not aware of this thread and not subscribed to debian-project. I hope my comments can still be considered. The version must be the version of the last upload, plus +nmuX, This special versioning is needed to avoid stealing one of the package maintainer's version numbers, which might disrupt their work. The past weeks I had several encounters with the situation that a maintainer completely overlooked and NMU and uploaded a newer version without acknowledging the previous NMU, thereby reintroducing the problem the NMU addressed. This happened to active maintainers. I was wondering why we version NMU's differently from MU's. If they used the same scheme, in these cases the subsequent upload from the MU would have been rejected. That would have flagged a problem for them and they had discovered the NMU they forgot to integrate. Of course it wouldn't help in any situation but it would have helped these. I do not really buy the stealing argument since maintainers do not own version numbers. It indeed interferes with their work but it *needs* to. A completely ignored NMU has been rendered ineffective. If you upload a package to testing or stable, you sometimes need to fork the version number tree. This is the case for security uploads, for example. For this, a version of the form +debXYuZ should be used, where X is the current stable major release number, and Y is the current minor release number for a stable upload, or one higher than that for a testing upload. Z is a counter starting at 1. For example, while Etch (Debian 4.0) is stable, a security NMU to stable for a package at version 1.5-3 would have version 1.5-3+deb40u1, while a security NMU to Lenny would get version 1.5-3+deb41u1. This is the case even when it is already known that the next release will be a new major version ; for instance, Lenny will be released as Debian 5.0. I am not very happy with this paragraph. The proposed scheme is in my opinion hard to read, and it gets especially confusing when 40 means 4.1 and 41 means 5.0. We already have a scheme in the security team that prevents this numbering confusion, and that is to use release codenames. It makes it clear at a glance whether a package is intended for stable or testing, and the codenames do not change. The current convention is to add +etch1 or +lenny1 respectively. This scheme works well. It would fail when we have a release name starting with a, but that situation doesn't exist and can be easily prevented. The scheme was recently changed to cope better with binNMU's, and I'm not sure what the benefit would be to change it yet again within a few months. The problems we have, like today with postfix, are when maintainers use the old scheme which is indeed suboptimal. I'm unclear on the reasons of changing the current system. It works, so why change it? I prefer to codify existing practice than the other way around in this case. cheers, Thijs pgpybwIX3a6FK.pgp Description: PGP signature
Re: When Debian 4.1 will arrive... will anyone care?
On Fri, 2007-04-20 at 19:43 +1000, Craig Sanders wrote: 1. why is this allegedly a 'benefit'? what's so special about libraries? why is a new libc6 or libssl etc more scary than a new apache or php etc? When using a backports package, the breakage is confined to that package. When pulling in newer libs aswell, it might be that some totally unrelated part of the system, e.g. another service on that host, breaks because of a change of behaviour in that library that is not triggered by the application for which I upgraded it. It's a matter of reducing risk: if code works, do not change it unless necessary. If I can upgrade one application and keep other existing code in place, I prefer that of changing it just for the heck of it. An example: I run a stable system with apache and php from stable. I want to run some web application only in testing, which requires a newer PHP version. The version of the webapp in backports is modified to work with stable PHP, so that I can keep my working apache+php installation and still use the newer web application. Getting the version from testing directly requires also upgrading PHP, potentially breaking other web scripts that users of my system have installed. Thijs signature.asc Description: This is a digitally signed message part
Re: Why is there only self-nomination? [Re: Expulsion process: Sven Luther]
On Thu, 2007-03-01 at 22:39 +0100, Luk Claes wrote: Personally, I think the idea of a DD having to ack his nomination, though only after being nominated by some (Q?) fellow DDs would be better than a plain self-nomination. What do others think? What would be better about it? I haven't seen any concrete problems yet with the nominations. Last year (i.m.o.) a troll has nominated himself, but he was convincingly voted down. What concrete problem would this solve? Thijs signature.asc Description: This is a digitally signed message part
Re: DWN
On Sun, 2006-10-15 at 20:18 -0400, Hubert Chan wrote: I also appreciated the package summaries at the bottom of DWN. (e.g. these are new packages in the archive this week, these packages have been orphaned, etc). Is there some other easy way to find that information? They are automatically generated as far as I know. Therefore, these summaries could be displayed on some sidebar of Debian Times. Or even more general, turn the generating script into something that creates an RSS feed, and list that feed on Debian Times. Thijs signature.asc Description: This is a digitally signed message part
Re: Filibustering general resolutions
On Tue, 2006-09-19 at 10:09 -0500, Manoj Srivastava wrote: The project should decide how it wants to handle filibustering, if it feels like doing anything about it, of course. But now, any GR has a veto contingent of only 6 developers. How about we see how to solve that when it actually happens? As far as I can see, in the case you're refering too, the deadline has only be moved into the future *once*; quite different from indefinately and I've seen nothing to believe that this group you refer to is interested in excercising this loophole to veto the proposal. I'll just keep my faith in the good intentions of these fellow developers for now and only assume an attempted sabotage of a vote when a bit more evidence to that matter surfaces. Let's wait and see what happens, and give our collegues/peers/fellows the benefit of the doubt. Thijs signature.asc Description: This is a digitally signed message part
Re: Packages awaiting proposed-updates moderation
On Wed, 2006-08-02 at 10:50 +0200, Loïc Minier wrote: I don't quite understand the various steps that a package traverses when uploaded to SPU. Is some document explaining that? In short, I would just like to understand the number of steps, the human-triggered transitions, and the public visibility, for example: I'd appreciate such a document, maybe linked from the proposed-updates page. I'd be even more happy if if also included the process for security uploads that end up in proposed-updates, because it seems to be different. Thijs signature.asc Description: This is a digitally signed message part
Re: package ownership in Debian
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. Thijs signature.asc Description: This is a digitally signed message part
Re: Constitutional Amendment GR: Handling assets for the project
On Sun, 2006-07-23 at 23:47 -0400, Joe Smith wrote: That is true. However this ammendment substancially changes the section that talks about SPI, so it would be reasonable to have SPI's board look at it if they so desire. At best they could find some text that ought to be tweeked, and at worst they could have no input. What I'm missing in this discussion is that SPI has an active board at this very moment. No need to delay anything to satisfy both the ask SPI and don't ask SPI camps... the fact that their term ends soon is surely no reason to think they're suddenly incapable? Thijs signature.asc Description: This is a digitally signed message part
Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.
On Mon, 2006-06-19 at 23:32 -0500, Ean Schuessler wrote: Social politics creeping into Debian is one of the greater mortal dangers that we face. I surely hope not. Your mail suggests that someone who has severe social problems but is technically competent is per definition fit as a developer. I don't know the details of Sven, but I know of a lot of situations where someone's social interactions severely hamper the technical achievements of other members of a team. Such examples I've seen (not necessarily with Sven, to be clear) include contiuous destructive feedback on others, constant promises to do work but not actually doing it, taking criticism personally, only accepting 'your way' as a possiblie solution, not being able to compromise, lying to other team members. I've seen all these in practice, and however technically capable someone might be, these kind of characteristics destroy the production of other team members, especially volunteers. If Sven makes genuinely important technical contributions to the PPC installer and is being excluded for purely social reasons then we should take that very seriously. Purely social reasons can be a very good reason to have someone leave a team. What matters is what the reasons are and if they are justified, not whether they are technical or social. And to be honest, those reasons have now passed over and over. Thijs signature.asc Description: This is a digitally signed message part
Re: Donations
Hello Wouter, On Sat, 2006-06-10 at 12:45 +0200, Wouter Verhelst wrote: Perhaps a formulation like Since Debian has no authority to hold money or property, any monetary donations for the Debian Project must be made to an organization that has been vetted by the DPL to be allowed to handle such things in name of the Debian project, where no more than one such organization shall be vetted per country. Any property in hardware, trademarks, or in copyright will be handled by SPI, which is our legal umbrella organization in the U.S. might work. This would avoid having to update the constitution every time someone wants to create a new organization. I wonder why you open up the possibility for other organisations to keep money for Debian, but do not allow these organisations to have any non-monetary property for Debian. I know of no good reason now why an organisation other than SPI would want to hold e.g. hardware for Debian, but I also do not see a clear drawback - if we trust them with money we can trust them with servers aswell. I'd keep the possibility open to have such approved organisations hold other property since there might be a reason to do so in the future which we're now unaware of. It also keeps the constitution simple: no special casing, the list would contain organisations that Debian trusts to keep things (monetary and other) in its name. Thijs signature.asc Description: This is a digitally signed message part
Re: Donations
On Sat, 2006-06-10 at 18:51 +0100, David Pashley wrote: Presumably because transfering money between countries involves non-neglegable cost, where as transfer of ownership of hardware doesn't[0]. I understand that - my point is that I don't see a clear reason to *disallow* other of such vetted organisations to own property for Debian, and hence wonder what good such an extra restriction would bring. I'd only add restrictions when there's a good reason for it. Just like with software :) Thijs signature.asc Description: This is a digitally signed message part
Re: Shouldn't we have more ftp masters ?
On Wed, 2006-05-31 at 15:10 +1000, Anthony Towns wrote: If you can't think of anything useful to do, you might like to look at http://ftp-master.debian.org/unmet-deps/ for a bunch of ftp-masterish problems that no one else is looking at much these days. Might be a dumb question, but isn't this more the responsibility of the respective maintainers than of the FTP-master? If so, wouldn't this be better sorted by maintainer and/or linked from the PTS, than hidden in some corner? By the way, those files were most recently updated last July. Thijs signature.asc Description: This is a digitally signed message part
Re: Using the Debian open use logo to distinguish DFSG-compatible licenses
On Thu, 2006-05-18 at 12:34 -0400, Evan Prodromou wrote: So: if there's a public statement by Debian or debian-legal on a license (like http://people.debian.org/~evan/ccsummary is now), would it be misleading for an organization to point to that statement? Especially if it was clear that the review and approval was not an endorsement of the organization or their goals? My suggestion would be that any organisation wishing so just uses the facts to describe the DFSG-fitness of their licence. For example: Over the past years, Debian has accepted a number of works covered under this licence into their archive. or similar statements. This requires nothing to change from the current situation. Thijs signature.asc Description: This is a digitally signed message part
Re: irc.debian.org
On Sat, 2006-05-06 at 13:09 +0100, Simon Huggins wrote: Since Debian doesn't donate any money to Freenode, I think that the question of donation spending is not relevant to what network Debian should choose as its default. By pointing irc.d.o at freenode, it says Debian supports freenode's allocation of funds implicitly though. That's a matter of opinion not fact, an opinion which I do not share but others of course might. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: irc.debian.org
On Sun, 2006-04-30 at 19:34 +0100, Steve McIntyre 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. Disagree. I'm on some channels for other projects aswell, and they are all on Freenode. Freenode is the de-facto standard for open source IRC channels, and moving away from it should only be done for very compelling reasons. I personally have not had any serious problem with freenode in the recent past. I guess the main problem with freenode would stem from quite some years ago. Time has passed and Freenode improved. Of course one can find a problem with any network, just as OFTC has its problems too. To give an example, when trying to connect recently, I discovered that there isn't even a server list available on their website (quite basic information), and that irc.eu.oftc.net does not connect you to a European server. On another front, oftc is also a sister org under the SPI umbrella. What advantage does the same umbrella bring in choosing an IRC network? Summarizing: I do not see how changing the default network would improve Debian's IRC channels, but it would separate the Debian channels from the much larger base of open source channels on Freenode. thanks, Thijs signature.asc Description: This is a digitally signed message part
Re: Reforming the NM process
On Wed, 2006-04-12 at 21:33 +0200, Marc 'HE' Brockschmidt wrote: Michael Banck [EMAIL PROTECTED] writes: [...] I am not sure 6 months of sustained contributions is really necessary, I think several months or sustained contributions are alright, where both measures are up for interpretation depending on the type, quality and quantity of the contributions. Which is a perfect reason for Hey, $foo was allowed to do $bar after 4 months, I have done the same and needed to wait 6 months! Sorry, the appeal of these numbers is that clear rules allow us to kill off most reasons for flamewars. Not only for preventing flamewars, but to make things more predictable for the people entering the system. Please establish clear, measurable goals whenever that's reasonably possible. Since it doesn't seem to add much value to allow to shorten that period from 6 to 4 months for some and not for others, I'd advise just not to do it. Thijs signature.asc Description: This is a digitally signed message part
Re: Reforming the NM process
On Thu, 2006-04-13 at 08:39 +0200, Benjamin Mesing wrote: like your studies (beeing in a computer science PhD/MSC helps), Well this might be interesting for the Debian project, but applicants might not want this to become public knowledge. Please do not assume, that this is for any particular reason, but merely for keeping ones privacy. You need not to document any of that personal information in order to become a DD. As said, your studies might help, but it's not necessary to provide it (the proof is in that also people without any studies can become a DD). You only need to prove that you're capable of doing the task you applied for. If you wish to share the information with your AM but not with another DD, you can of course always mail that to them privately. Thijs signature.asc Description: This is a digitally signed message part
Re: Reforming the NM process
Hey Marc, Thanks for this initiative; I'd just decided to not get involved in the threads on -newmaint anymore because even though I feel strongly about the issue, the threads were just a repeat of themselves. However, your mail seems to be different, in that it comes from someone actually involved and that it has some concrete plans. 1.2.1 Add more people 1.2.2 Fewer checks 1.2.3 Drop Front Desk/merge with DAM I think these are still worthwhile to pursue, in the context of the other changes you propose below. Reforming the process could require some more fundamental changes, but is even more effective with streamlining in these areas. About the More People part, this is something that won't change when doing nothing, but could change when the demands on AMs are different (less boring, less unfit candidates). Merging the FD with DAM is also an item I still support, since I think it saves effort, and I don't see any drawbacks in doing so: worst case it will cost just as much time as now, but with a simpler structure. In the best case it will eliminate quite some duplicate checking of reports. 1.2.4 Task-based checks ~~~ Some people, including me, have discussed the possibility to use a task-based approach to the NM process. As far as I know, I'm the only AM who has actually finished this with an applicant. I've actually done this with my AM, Luk, and I'm quite satisfied with this. After doing this once, I'd not recommend it as a regular replacement for the checks based NM templates we use at the moment, mostly because of its time needs. I still would; it costs a bit more time, but that time actually yields results for Debian. This was more motivating for me, and it could be more rewarding for the AM. 2.1 Multiple advocates Yes, good idea. It seems that some DD's are advocating people to early. I would also advise to contact people who make too fast advocations about this matter, to tell them why this isn't right. If they keep on advocating people who aren't ready, you could of couse consider banning the respective DD from advocating, but I think some feedback would already make enough impression on most. 2.2 Requiring (more) work before applying Yes, agreed. If you don't do that amount of work already you could easily continue on the sponsored-basis we have. 2.3 Separate upload permissions, system accounts and voting rights This part is *very* experimental, I'd love to hear other people's opinions, suggestions and changes. I'm really not convinced that this is the perfect solution, but it has some very nice aspects. It is a bit of a generalization of the idea Anthony posted on his blog today. I like it. It formalizes the current sponsoring idea: it makes it a bit harder to actually have your first package sponsored, but not in a bad way. The little more effort wouldn't scare away those who are actually interested in maintaining a specific package, it's not at all like the NM process but more of a quick lintian check of an uploader. There should of course be provisions for people for whom it isn't that easy to get signatures from two DD's. Anyway, actual system accounts could either be given out at this stage or after another set of checks, though I don't see a reason to allow people to upload everything, but not log in on Debian boxes... I would keep it to the two stages you propose. Adding more stages doesn't add any real value while it unnecessarily complicates the procedure. Thanks for your mail, I look forward to some actual changes being made! Thijs signature.asc Description: This is a digitally signed message part
Re: About expulsion requests
On Sun, 2006-03-19 at 13:32 +0100, Harald Geyer wrote: I don't want future employers to be able to google about my bugs. http://bugs.debian.org/robots.txt Thijs :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: uol.com.br and petsupermarket
On Mon, 2006-03-13 at 22:46 -0300, Guilherme de S. Pastore wrote: You have dropped a nuclear bomb to kill a cockroach, and the cockroach is still alive. I consider this a bit of a hyperbole. Appearently you can still read and post to the lists, albeit through another account. It might be annoying, and you are in your right to dispute the way this is handled, but is it really the end of the (Debian) world? I hope an easily avoidable block from some Debian lists is not enough to scare developers away. Thijs signature.asc Description: This is a digitally signed message part
Re: Hi, request to remove spammed links from http://lists.debian.org/
Hello Koen, This is a request to remove spam from http://lists.debian.org/debian-l10n-portuguese/2002/01/msg00026.html. My reason for requesting the removal of this page is that it is the most powerful link (on google) for bethedealer.com, a poker website that spams alot. Koen Every message in the archives has a Report As Spam button in the top-right corner. You can press that to inform the listmasters about the problem so it can be dealt with. thanks, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stable security support
On Wed, 2005-12-21 at 12:08 +0100, Adrian von Bidder wrote: On Tuesday 20 December 2005 19.33, Anthony Towns wrote: ... it's worth considering a GR ... I really liked your analysis up to that point. I can't see any reason why we would need a GR here. I think it's an interesting approach. The issue at hand has been going on for a long time, and it is needed that something is done. What especially needed is a decision on how it is going to be solved, and after the decision has been made, that people work towards reaching that goal. There's been a lot of talk, but it's needed that there's a clear decision on the solution for the problem. The instrument for the Debian project to decide, is a GR. A GR is not something that should only be used in issues like the constitution. It can also be used for anything that you want a clear decision on, after some discussion. Trying to reach a real, clear consensus, especially in cases like this, is very difficult. It's a fair instrument, because everyone has an equal vote and it doesn't favour the loudest discussion participant. A discussion usually ends in the lack of objections, or ends in some people in favour and others who disagree. In the second case, what do you do? Are there just a few, loud people in favour and a silent majority against? Or the other way around? This proposal might bring a resolution to the trouble. But it will only work if it's clear that it's widely supported. So to me the obvious advantage would be that it brings clarity. To ask you a question: why would you not hold a gr? What disadvantage does it bring? Thijs signature.asc Description: This is a digitally signed message part
Re: Complaint about #debian operator
On Mon, 2005-12-12 at 13:41 +0100, martin f krafft wrote: But your post makes it all the more clear that *a lot* of Debian people need to get the facts straight, and that a Debian vs. Ubuntu comparison on #debian is definitely not out of place. My biggest surprise whas that the channel operator appearently thought a discussion on Sushi to be more on-topic for #debian than the differences between Debian and Ubuntu. Thijs signature.asc Description: This is a digitally signed message part
