Success of iPhone apps (was: Re: What is annoying in the flattr buttons?)
Charles Plessy ple...@debian.org wrote: And in conclusion, I would like to remind the extraordinary success of non-free software on the iPhone, which I think can be explained by the easiness of micropayement through the Apple webstore. It's clearly not the only reason, and it's not even the first one on the list. You should have told about the high level of integration of the whole platform, the overall quality of the (top) apps, the ease of use, the sexiness of the apps, ... and lots of other things that free software apps do, more often than not, lack. But you absolutely do have a point in that there are lessons to be learned, though the one you are highlighting isn't the most important of all. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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/87wrok1del.fsf...@sonic.technologeek.org
Re: commercial spam on planet
Ana Guerrero a...@debian.org wrote: I am annoyed by the flattr advertisement and I stayed away from the thread becuase my opinion was already represented, not point in repeating them. If you are going do a 'poll' based on the people participating, add 1 to the list of annoyed people. Same here, plus I share most of what Russ wrote about Flattr early in this discussion. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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/871v6tqfbj@sonic.technologeek.org
Re: debian-private declassification team (looking for one)
martin f krafft madd...@debian.org wrote: Hi, How about making archive chunks available e.g. at monthly periods and telling people they have 2 months to voice objections before the stuff is simply disclosed. Those people who don't want their stuff disclosed are the ones that should be doing the work, no? You'll need a GR for that. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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/871vd36gps@sonic.technologeek.org
Re: Reopening my account b...@debian.org
Siggy Brentrup ex...@psycho.i21k.de wrote: Hi, I won't pursue this subject any longer, because I refuse to be examined by ppl that might be my grandchildren. As far as Debian is concerned, they are your peers, and that's all that matters. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Steve McIntyre st...@einval.com wrote: Hi, A time-based freeze could mean for some teams that they'll have to stop work basically for months to a year. Exaggeration, -1. Excuse me, what? This is exactly what happened for this past freeze, so you can take that back, kthxbye. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Jesús M. Navarro jesus.nava...@undominio.net wrote: Hi, That's exactly my point. We suck at freezing. The problem is not we suck at freezing. Quite on the contrary I think I should have written we suck at operating during the freeze or something alike, that was a bit of a bad shorthand :) Debian developers, the release team, the debian-installer team... all of them have done a really *amazing* work in the past, and I can say this without being suspected being just a mere user myself. All things considered (size and nature of the project, nature of the contributions, governance model, ...) I think we're doing amazingly well. It could be a lot worse, especially given nobody has ever done that before. We're bigger than any other project, nobody has been there before us. In the early days of Debian, the lesser number of packages and archs made (barely) possible the monolithic freeze. When people where overhauled (I think I remember it by the slink-potato or maybe potato-woody days) new tools pushed forward the frontier (and due to this package and arch numbers skyrocketeed), then the woody-sarge days again exposed the problem. Back in the days, frozen was just that and unstable was carrying on with its life (with a bit less activity, but only a bit). Today, unstable is just as frozen as testing is during the freeze. In the end, testing kind of works to prepare a consistent set of packages that we can freeze at some point, so it's a good development tool, but it's not a good release tool. WRT unstable, testing is a step backward. A lot of things need to line up for a release. Debian is very large and the windows of opportunity are few and small. True. But that adds more value to the cartesian divide and conquer idea for problem approaching. This, of course, wouldn't be without its own share of If you're talking of freezing/releasing different sets of packages more or less independently etc, this has been discussed to death already. You forget that on a branched dependency path it would be quite difficult for something really nasty reaching testing (for a conceptually similar approach It's not that difficult. It does happen, simply because since the testing introduction (and Ubuntu) we have less users using unstable and reporting bugs. The direct consequence is that bugs do make it to testing more than we'd like. Seriously, everybody gets bored and fed up during a freeze. Not because of the freeze itself but because it takes so long. Again, i.e. Both, actually. I am of the opinion that no matter how hard you try, you can't *make* a Debian release happen. I never thought about it that way but I think you marked the bull-eye. I think to remember something Schopenhauer said once about intuitions. And then, following Schopenhauer on this, although you cannot make it happen you still can make it easier for it to happen. My point exactly. You can *only* help the process. I understand just how frustrating that can be for release managers, but it's something that you need to accept to do this job. There's some point at which the release starts to happen, a point where a critical mass of DDs is reached, the point where everybody uses the word release more than any other word. All of which have some very real technical grounds and a heavy psycological Absolutely. nature too. Just the fact of being seriously comitted to a time-based release instead of current we aim towards this or that date that nobody takes really seriously but as a wishful grosstimate would heavily help for the critical DD mass and the going for the release attitude to happen. I think there's been a real push over the last years and a lot more DDs are focused on getting releases out the door now. We talk about releasing more than ever, so this cannot escape anyone nowadays. As for the cadence, the 18/24 months is something that looks like it can work repeatedly and is generally a good pace for us etc. So, in a nutshell, it's all there already, though not as formal as some would like it to be, it seems. developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). Remember dunc-tank? Yes, but I don't think it as a demonstration that money can't really help (or can just really help that much) but as a misguided and mistimed attempt doomed to fail. Fair enough. What we'd need is some sort of upstream academy where we could teach upstream: [...] Yes... It might be worth it some kind of best practices manual coupled with some kind of peer-review process for such practices (the equivalent to the I think something more interactive and hands on would be best. RTFM never worked that well in this case. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1
Re: On cadence and collaboration
Mark Shuttleworth m...@ubuntu.com wrote: [Cc:ed as I don't know whether you're subscribed to -project] Hi, freeze summit, and there are significant benefits to Debian to being part of that rather than on a different schedule. From the very start of the Debian Project, Debian has been different from everything else: different package management tools, different philosophy, different organization, you name it. Overall, it's been working fine for the last 16 years. What do you think the changes you are proposing can gain us? I don't believe in the upstreams will care stuff (there are good examples of upstreams not giving a damn about distributors over the past months) and I don't believe in the 100% end-user-centric focus you're displaying in your mail. Once I've removed that from your mail, and the but Ubuntu loves you! stuff, there's nothing left. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Mark Shuttleworth m...@ubuntu.com wrote: Hi, Debian stands out in many respects, yes. But being different for the sake of it isn't a laudable goal: if there's a good idea, it deserves to be considered, even if others are already considering it. Being different and independent actually enables us to be better at what we're doing than anyone else. If we were tied to something or someone one way or another, this would not be possible. Overall, it's been working fine for the last 16 years. A lot has been achieved, yes. Could more be done? Could Debian be stronger? Are there weaknesses that may be addressed? I think it's always worth considering how things can be improved. Indeed. And I truly don't see how being tied to and restricted by other projects with differing interests can help us there. Quite to the contrary. Well, we believe differently, and that's OK. I think it's easy enough to go and speak to a few upstreams, and ask them this: what would you do differently if you knew that multiple distributions would all sit down and think about which version of your code to ship with their big 2010 release? I think you'd find most of them say that would be amazing. I don't really care about what they say, I care about how they act upon it afterwards. And unfortunately there's no guarantee that they'll support us better than they do today. Especially if those statements were made without community backing. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Eric Evans eev...@sym-link.com wrote: Hi, Maybe it's just me, but I don't see anything in your response that adds anything to the discussion. You can see Marc's reply as documentation for people new to this matter. There's some value in that. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Mark Shuttleworth m...@ubuntu.com wrote: Being different and independent actually enables us to be better at what we're doing than anyone else. I agree, that conscious, planned and considered differences are the best way to beat the competition or stand for your brand. If you do the same thing as everyone else it's very difficult to be better. Releasing (or freezing, FWIW) at the same time as everyone else is a part of that. Your developement then becomes bound in just the same way as everyone else's, with all the consequences you can think of. As the ultimate goal is to get pretty much all the free software world to sync up for distro releases, this means everyone will work on the same fixed schedule (with ca. 2-year development periods). I'm wondering about the impact this will have on roadmaps in different projects. I fear it may bring to free software some of the worst issues of the proprietary/commercial software world (no vision past the next big release, for instance). you vs your competition. In Debian's case, I can think of several things that really define the brand and the values. Supporting more architectures. Having the most democratic processes. debian-legal. And many more. None of them depend on having the same, or different base versions of the major components as any other distro. I'm not sure our governance model is of much interest to the lambda end-user, she probably also doesn't give a damn about debian-legal and architecture support. some delta. It's worth paying the cost of that delta if it helps you be you. It's not worth having a delta just because nobody bothered to sit down and talk about it. If it works that way already, why bother? Also, what are we really talking about here? Desktop? Is that it? All of this seems very desktop-centric to me. What's the story on the server front, and what are the implications? Do we set an Apache version everybody will ship, too? What impact does that have on security? When everyone gets the same Apache version accross all distributions, with the same issues? Does that buy us anything? Isn't diversity better here? You are on a fight against proprietary software (you made that clear through your wording in your first mail). One of the issues with proprietary platforms is that everyone running a given platform runs the same security holes. Now, that obviously applies equally if platform = Debian, but not if platform = Linux. There aren't different Windows vendors. There's only one. There are different Linux vendors. If they all offer the same thing, then we have another monoculture and we lose something, something very real. In the free software world, the diversity we have today, which is partly due to unaligned releases from the major vendors, is an asset. You have been talking a lot about the implications at our level and a bit about upstream, but there are implications downstream too that must not be overlooked and they might not be the most obvious. I don't really care about what they say, I care about how they act upon it afterwards. And unfortunately there's no guarantee that they'll support us better than they do today. Especially if those statements were made without community backing. There's no guarantee, no. But community members rally to a good, inspiring, intellectually true vision. You may not get them all, and you Wishful thinking. Community members can also rally to the most popular proposer, regardless of the proposal she puts forward. Not meant at you, but to illustrate that things don't necessarily work as they should. may not get the leader, but you will ensure that on every mailing list *someone* will be asking the question what can we do to help those guys with their noble cause? I get your point. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Jesús M. Navarro jesus.nava...@undominio.net wrote: Hi, I think we'll lose part of the we release when it's ready philosophy (that our RMs seem to despise so much). Because part of this is to freeze when it's ready. Not at all if done properly. Freeze on a date simply means that what it's ready on that date is included, what it's not ready won't be included, simply as that. When you couple that with a freeze date well known in advance, you allow interested people to plan properly. The freeze date for the past few releases has always been known in advance and refined as we went. The problem is that a lot of upstreams do not have a planning that we can compare against and base our work upon, so for a lot of the packages we just follow upstream. Not to mention our very own infrastructure issues that have bitten us. (pleeease, wait for another two weeks for our new and shinny). That's largely an end-user-induced issue, desperately trying to escape the Debian obsolete nickname for Debian stable. We're weak ;) A time-based freeze could mean for some teams that they'll have to stop work basically for months to a year. It already takes too much time to recover after a release, this won't help. Why? I really don't see your point unless you mean for the packager under current conditions where no real branches are allowed on Debian (but the That's exactly my point. We suck at freezing. everbody's bag that it is 'experimental' that has demonstrated not to be a solution at all). This needs to be changed and I expect the time-based freeze to be the tick that will finally push this change. It all boils down to the current testing system being inadapted to our needs. But that's something we couldn't really know for sure until we had tried it for a couple of releases, and I think we still won't know for a release or two because of the new tools that have been put in place to handle transitions (and others). If that's what you meant, I think you don't have an argument against time-based freezes but against the first time-based freeze on Dec-2009 but A lot of things need to line up for a release. Debian is very large and the windows of opportunity are few and small. Deciding on versions of core packages between distributions could help, but a fixed-date freeze probably won't. It could even make things worse, as it could make it harder to iron out the issues (like having to convince the release team to let a new upstream in to fix something because there's really no better way). Seriously, everybody gets bored and fed up during a freeze. I am of the opinion that no matter how hard you try, you can't *make* a Debian release happen. There's some point at which the release starts to happen, a point where a critical mass of DDs is reached, the point where everybody uses the word release more than any other word. to push it to a latter date in order to have time for the tools to be developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). Remember dunc-tank? In this day and age, you have to look at features in addition to the version number, because the latter isn't necessarily very telling of the real changes from one release to another. Major features are delivered in minor releases nowadays... I already said that to be simply malpractice and beyond a distribution's ability to correct (while I'm with Shuttleworth in that concurrent freezes would help to show the proper path to upstreamers). What we'd need is some sort of upstream academy where we could teach upstream: - how to version properly - how to properly manage their API/ABI for shared libraries - how not to make a mess of their release tarball - ... (let's not make a list, it'd be depressing) JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Pierre Habouzit madco...@madism.org wrote: Hi, Quoting out of context and generalizing from there, way to go. In the free software world, the diversity we have today, which is partly due to unaligned releases from the major vendors, is an asset. Security-wise ? Let's admit that, I don't want to fight on that point, even if I think it's not as simple. It does help, but sure it's not that simple either. But speaking from my experience as an employee of a software editor, I can tell that the distribution diversity is a huge problem when it comes to distributing our work. If your client use a Ubuntu LTS, a RHEL, a SuSE or worst for some, some kind of home-brewed monster taken half from a RHEL and custom packages (*sigh*) then you have as many builds to do, regress-test and so on. When you target Windows or Solaris or MacosX, Guess what: this will still be the case even with aligned releases or whatever. You won't get rid of that unless all the distros collapse into a single one overnight. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Peter Samuelson pe...@p12n.org wrote: Hi, I still don't understand what is supposed to be new about the time-based freezes. The Release Team was giving us projected freeze dates all through the lenny release. For example, Same here. Either things are evolving and the proposal is being down-moded, or it was badly worded or reported initially. And I concur with your LSB comment, too. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian redesign
Steve McIntyre st...@einval.com wrote: Hi, The new simplified swirl looks cleaner, and it would be nice to move to a free-er font. I'm sorry to say, but the simplified swirl sucks plain and simple and the free font is so bad I'd be ashamed to use it for a logo (actually it's so bad I'd rather use Comic Sans). Also that font is so standard it's not recognizable; it doesn't have anything special, eye-catching like our current logo has. It's a FAIL. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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
Marc Haber mh+debian-proj...@zugschlus.de wrote: Hi, 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. For the record: I concur fully with Marc's statement above. Changing our release policy to match Ubuntu's LTS, changing our well-established, well-recognized logo for a simplified crap that has nothing special to it... What next? If some of our core teams members feel like they'd rather work on Ubuntu, then, by all means, please go ahead and arrange that with Shuttleworth. You'll be better for everybody. Turning Debian into Ubuntu's bitch, however, is not a viable way forward for anybody involved. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
Frans Pop elen...@planet.nl wrote: Hi, I can appreciate that, but is it unreasonable to expect the FD to at least send a simple overview (list of names) of who have been accepted in the project during the past x months? I think the AM could provide a summary for that mail, after all, the AM should know the applicant enough to be able to write that up, right? JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Is that really problem? We need people who take the right decisions (and that includes asking questions when they don't know or are not sure about something), not people who can repeat all our documentation from memory. And then we get what we've seen on -devel over the past few days with somebody who is a DM already. Very basic questions, showing that the documentation was (best case) not understood or (worst case) not read at all. Now multiply that by 10 or more and watch (even more) people walking away from -devel. If you want to bring up -mentors at this point, then you can s/-devel/-mentors/ above and it still holds. Let's add that the quality of advices and reviews offered on -mentors can vary wildly depending on the respondent (DD or not doesn't matter here), from inexact to blatantly (sometimes, dangerously) wrong. Recipe for a disaster. That said, NM is a pain for the applicants *and* the AMs from what I've witnessed recently. There's certainly room for improvements in the process, but it doesn't look like FD is open to much changes in the way NM works today (again, from what I've witnessed recently). JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian packages
Gabriel McCall hellion_darkl...@inbox.com wrote: Hi, Is there a definitive way to download packages for a machine that, due to it's remote location, does not have an internet connection? What I'm looking for is a complete file that would contain all the packages that a specific application is dependant upon whether or not a given operating system already included said packages in it's makeup. apt-zip might be what you're looking for. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership
Lars Wirzenius [EMAIL PROTECTED] wrote: Hi, I think we should go in the opposite direction: massively simplify the whole membership thing. [...] I do not believe the current New Maintainer process measures those things in a practical way. I wish to suggest a replacement process. I like this proposal; it is a bit rough around the edges and a couple of things needs to be improved, but it's a very good basis and goes in the right direction. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert [EMAIL PROTECTED] wrote: Hi, I'm pretty unhappy with the very non-Debian way you have when it comes to making decisions and announcing them. If you are an existing Debian Developer or Debian Maintainer, don't be afraid, we are not going to take anything away from you. And also that feeling you seem to have that you are above the lot of mere mortals that we, DDs without delegations, are. the way it was instantiated outside of most existing structures has always made other groups in Debian uncomfortable. The ftp-masters Pretty much the only thing in your proposal I agree with is the bit about getting DM under proper controls. Now about the new status you are proposing, my general feeling is: more bureaucracy \o/ What you are proposing is way too complicated for the outside world to understand. I think adding a Debian Contributor status (no upload, no vote) with labels (translator, writer, ...) is a simple solution that fits the current issue pretty well. On the contrary, what you are proposing seems like solutions looking for problems to me. Now on to specifics: Debian Maintainer - A DM has to pass the same checks a DC has and very few questions from the TS part[DCDMQ]. A (very) small TS basically, the most important TS questions for them. I'm afraid you're going to need more than very few questions from TS. I think it's important that DMs know their stuff, for we have quite some crappy packages in the archive already and we don't really need more of them. They don't have to answer the more painful questions of the TS template (amazing what AMs can come up with, really), but very few seems like not enough to me. unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. And that I totally disagree with. Being lintian-clean doesn't tell much about the quality of the package, and tells exactly nothing about the quality of the packager. I think we've had some examples of clueless DMs and even clueless new DDs in recent times (proving that even a full TS might not be enough). Do you want more of that, or less of that? I like the idea of progressing from DM to DD during NM, as it provides some kind of an observation period. As applicants are required to have some packages already when they apply, they could be granted DM after the basic checks, then complete NM and start an observation period as DM. To me, that's giving them full responsibility for their packages early on so we can see how they handle them on their own. Debian Member - A DME can nominate themself as DPL, can be delegated rights from the DPL and can start any GR, basically do everything our foundation documents allow project members to do. I have a problem with non-technical persons voting on technical issues, or issues having technical implications for the developer body. I have even more of a problem with non-technical persons leading a technical project. I am against this part of your proposal. Voting rights should be coupled with proper understanding of the Project at large, including the technical stuff, which is, after all, the base of this Project. This whole status is useless. If you want to vote, go to DD status. You'll get upload rights too, that doesn't mean you have to make use of them. I expect going to DD status to be something doable for any contributor after a period of time. Changes to the DM Keyring - Keyring management will be moved to the control of keyring-maint. The NM committee will decide who will be added or removed, similiar to the way keyring-maint and DAM currently work together. No matter what happens with everything else in your mail, go forward with that. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
Sven Luther [EMAIL PROTECTED] wrote: This is the exact example of why things went bad in erkelenz, because you are unable to hear what others have to say, and want to impose your own opinion on others. And, when it comes to that, you know what you're talking about. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
Sam Hocevar [EMAIL PROTECTED] wrote: Please, Sven. There is already one thread about you in -vote where you are already copiously posting and that people are acutely following. I therefore suggest restricting your interventions to that thread. And a third one on debian-powerpc. Having all your posts in the same thread makes it easier for the people who wish to help you to see your arguments, for instance by tagging the whole thread as important. If you post at too many different places, these people who wish to help you may miss valuable information. ITYM it's easier to kill one thread than 3 ? JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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!
Anthony Towns [EMAIL PROTECTED] wrote: incredibly open manner with a pretty impressive level of uptime. None of that means we can't or shouldn't be doing better, but I think it's worth recognising that when we say we're not doing a good enough job, *we* are still the ones setting and raising the bar. Others being even worse at that than we are is neither an excuse nor a compensation. Let's continue to raise the bar. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Etch Stable.
Mike Hommey [EMAIL PROTECTED] wrote: Given this isn't a DPL funding initiative, I think you're way off base. It's not only because you subtly outsourced it. subtly ? HAHAHAHAHAHA. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Etch Stable.
Anthony Towns aj@azure.humbug.org.au wrote: Personally, I'd say that now would be the time for any anti-payment people to say we can do this better, and look, we'll prove it, and make up their own target date for etch, and demonstrate how much energy and Now if only you could understand that we don't give a shit about the release date, that would be a great step forward. Only quality matters. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Etch Stable.
Anthony Towns aj@azure.humbug.org.au wrote: Now if only you could understand that we don't give a shit about the release date, that would be a great step forward. Only quality matters. Quality is not, and has never been, the question. Given how one of the two release managers treated some of the RC bugs, quality is the question. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Etch Stable.
Marc Haber [EMAIL PROTECTED] wrote: Now if only you could understand that we don't give a shit about the release date, that would be a great step forward. Only quality matters. Kindly speak for yourself. I happen to give a shit about the release I speak for (most of) the so-called anti-payment people. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Letter to Anthony Towns about the d-i mediation ... [forking practicalities]
MJ Ray [EMAIL PROTECTED] wrote: Hi, Hopefully someone smarter will have a better suggestion. It's sad to see so many clever people unwilling to go beyond calling for /ignore svenl and sod the powerpc install. Is no-one smart enough to come up with a way that's good enough to stem complaints from both sides? To be honest, it does not look like the d-i team is interested in putting an end to this story. JoeyH's comment on the support page I set up makes that clear enough I think. And, as you wrote, any attempt from Sven to fix things up will look like a desperate attempt to get his commit access back and only that, so ... JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Powered Logo
Benjamin Seidenberg [EMAIL PROTECTED] wrote: Hi, It seems to me that that particular text (Debian Powered) makes more sense as a button for a service on a box running debian. For a Debian Derived Distribution, I think it would make more sense to s/powered/derived/. Right, here it is: http://people.debian.org/~jblache/debian-derived-1.png There's room for improvement, I have a few ideas I need to try out, but I lack the time to do so at the moment, so I'll be back to playing with Inkscape in a couple of weeks :) JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Powered Logo
Eduard Bloch [EMAIL PROTECTED] wrote: Hi, http://people.debian.org/~jblache/debian-powered-1.png Something, yes. Maybe you could try to use the text only three times. OK, here it is with the text repeated only 3 times, in a closed circle around the swirl: http://people.debian.org/~jblache/debian-powered-2.png The text repeated 3 time in an open circle around the swirl (same font size than -1.png): http://people.debian.org/~jblache/debian-powered-2_open.png They still need some work, consider them as a base for the discussion :) JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Powered Logo
Eduard Bloch [EMAIL PROTECTED] wrote: Hi, http://people.debian.org/~jblache/debian-powered-1.png Something, yes. Maybe you could try to use the text only three times. Yes, this was a quick hack, I need to fiddle a bit more with Inkscape to get what I want :) JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Powered Logo
Eduard Bloch [EMAIL PROTECTED] wrote: Hi, What about creating a logo for a strategy similar to the Intel Inside campain? I imagine a simple circle of letters Debian Powered (in Debian-red) around the Swirl. Something like this ? http://people.debian.org/~jblache/debian-powered-1.png JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: irc.debian.org
Steve McIntyre [EMAIL PROTECTED] wrote: Hi, 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 Thoughts? Go for it. Having half the project members on Freenode and the other half on OFTC is just counter-productive. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: irc.debian.org
Benjamin Seidenberg [EMAIL PROTECTED] wrote: components I use, postfix, etc, etc etc. I think it might be better for us to try to use our influence as a huge source of users to try to better freenode than to just move. We tried to do just that years ago. See how it worked out ? JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strawpoll on proper usage of @debian.org email address
Michael Banck [EMAIL PROTECTED] wrote: Hi, 2. Using @d.o for dealing with FLOSS with a loose debian-relationship (e.g. reporting a bug/patch in the upstream bug tracker of an unrelated package, posting on mailing lists of projects without being the Debian maintainer etc.) Alright Not Alright [ ] [ ] In this precise context, I'd like to answer I don't mind. Could you repost your poll with this answer added ? I think it'd be a real gain ; otherwise people would probably answer Alright when they really mean I don't mind. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: EPSON appreciates your feedback by June 30, '03 - Debian
[Ob-lists: if replying publicly, please reply to -devel only] Farideh Sherbaf [EMAIL PROTECTED] wrote: Dear Linux Developer and Distributor, Hi, Please allow me to introduce myself. My name is Farideh Sherbaf and I am your contact for EPSON Worldwide Developer Relations for scanners and All-In-One (Multifunction) products. The EPSON Developer Relations Group would like to obtain your feedback on your support of scanners in the Linux environment. I am the maintainer of the SANE packages in the Debian distribution ; nice to see some communication from Epson Kowa ! SANE maintainer hat on Your prompt answers to the following questions are appreciated (Yes/No): 1. Do you include the SANE backend (scanner driver) within your Linux distribution package? Yes. This is a must-have for any Linux distribution that wants to be used on the desktop. 2. Which SANE frontends (applications) do you include within your Linux distribution package? The standard frontends from the SANE project are available (scanimage, scanadf, xscanimage, xcam, saned), along with XSane, QuiteInsane and Kooka. 3. Do you include Epson's Image Scan! for Linux? (Image Scan! for Linux is a graphical frontend for Epson scanners.) No. Although further explanation does not seem to be requested by your survey, let me explain why the Epson Kowa backend and frontend aren't included in Debian. To be included in the Debian distribution, a software basically needs to fulfill 2 conditions : - its license must be considered Free by Debian (see [1] for details) - somebody has to volunteer to maintain the packages The latter would probably be no problem for the Epson Kowa softwares if the former point was fulfilled. The Epson Kowa Public License that covers the distribution of the Epson Kowa softwares isn't Free ; it forbids reverse-engineering or any form of analysis of the binary-only modules that ship with the software. This is the first showstopper. The second one is that the source distribution ships binary-only modules, which makes it impossible to build the softwares for anything else than Linux/x86 ; in its latest release, Debian supports 11 hardware architectures, and portability is something very important for us. We have a special section in our archive for softwares that do not meet our requirements in terms of license, but are nonetheless freely redistributable and potentially useful to our users ; it's the non-free section. Should somebody be willing to maintain packages of the Epson Kowa softwares, they could be included in the non-free section. However, note that the non-free section isn't distributed on the release CDs. Now, apart from this, looking at my 6-months-old notes on the subject, it seems that the scanners supported by the Epson Kowa backend are already supported (to some point) by the regular SANE backends. The same applies to the frontend, with the powerful frontends already available. Again, my notes are somewhat dated by now, so feel free to correct me if I'm wrong on this point. Feel free to contact me if you have any questions. Regards, JB. [1] http://www.debian.org/doc/debian-policy/ch-archive.html#s2.1.1 -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
