Re: Appeal procedure for DAM actions
On Mon, Jan 07, 2019 at 11:27:35PM +0100, Joerg Jaspert wrote: > With this message we define a way to appeal a DAM action, I'm treating this as if it's a first draft and open to comment. > 1. Appealing DAM decisions > -- > Any person who had their Debian membership suspended or revoked by DAM may > appeal the decision. Based on the process you describe, I'd suggest phrasing this as "may ask for the decision to be reviewed by the New Members Committee". An "appeal" (at least in legal terms) usually goes to the more powerful body, but in this case, DAM is the more powerful body. Having the boss's decision reviewed by people who report directly to the boss is kind of a dodgy structure; and people on the new member committee will probably want to maintain good relations with DAM, at least if they want to continue doing new member work. > 2. DAM statement > > Within 72 hours DAM will provide a statement to the NMC and the appealer > with their reasoning for the account status change. I think by this point DAM should have already provided the reasoning for the expulsion to -private (or -project if the person being expelled agreed), so this should be redundant. > DAM may also send additional material to the NMC only, encrypted to the > individual members, if they deem it necessary for the case, and if > presenting this to a wider public might cause issues of confidentiality for > involved third-parties. > [1] The NM-Committee is defined as: >- All members of DAM and FrontDesk. >- All application manager that are marked as active and > processed at least one NM in the last 6 months. >There is a mail alias which reaches all > members, it is regularly regenerated by FrontDesk. All AMs that have processed an NM in the last 6 months is a fairly broad group, and not one that's particularly selected for dealing with particularly sensitive information. It doesn't seem like a great idea to send sensitive info to them that you wouldn't feel comfortable sending to any random developer to me, so again sending the detailed reasoning to -private still seems like the right approach, removing personally identifying details in the rare cases where that's necessary. > The NMC members are expected to avoid disclosing > this material to anyone else, including the appealer.[3] Doing things that way avoids this risk/caveat. I don't really think providing sensitive material to the new member ctte in this way is helpful anyway: if they can't pass it on to the person who got expelled they can't ask "is this true? what's your side of the story?" either, which is pretty essential if you want to have a remotely fair process. > 3. Appealer statement > - > Within a further 72 hours, the appealer has the opportunity to respond to > the DAM statement with their own statement. DAM should be providing the full reasoning to the person being expelled when they're expelled; if that person's going to ask for review, they already have all they need to provide their side of the story as part of the request for review, avoiding the need for this 72h period. Both the above changes would cut the appeal time down by a week, from: - expulsion happens - <30 days, review is requested - 3 days for DAM to do an update - 3 days for expelled person to provide a statement - 7 days for discussion - 3 days for vote to something more like: - expulsion happens, affected member and -private given detailed reasoning - <30 days, review is requested and statement from expelled person is provided to newmaint-ctte - 7 days for discussion - 3 days for vote This setup avoids giving the expelled developer the opportunity to pick Christmas or Easter or the start/end of the freeze or some other inconvenient time to start the process, and immediately triggering a 3 day deadline for DAM members. > 4. NM Committee review > -- > The NMC has 7 days to review the received material and discuss the matter in > private. They are expected not to solicit further input, as this is not an > inquiry but a peer review of the DAM decision. One of the things appeals courts in real life can do is send the case back to a lower court with a requirement to fix up mistakes in fact finding, which gives them an easy opportunity to avoid having to do any fact finding themselves. Since the balance of power is the other way around here; I'd expect that if the new member committee isn't just going to be a rubber stamp for DAM, then they'd need to be able to solicit further input in cases where DAM's summary of events doesn't match the expelled developer's take on what happened. (Another difference between the proposed process and court appeals is that appeals courts can provide detailed opinions as to why the original decision was wrong which helps avoid making the same mistakes in future; this process doesn't really have that feature) > 5. NM-Committee vote >
Re: Censorship in Debian
On Fri, Jan 04, 2019 at 10:47:05AM -0800, Russ Allbery wrote: > People seem to feel they're unreasonably put-upon by having to think about > what they're saying *at all*, but this is absurd. Everyone else in the > world is doing this all the time. There are times when you don't have to think about what you're saying before you say it; that situation is often called being "among friends", or "in a safe space", or "able to let your guard down". I think it's probably news to a lot of people that Debian isn't that sort of a situation today. (IMO, one of the problems with planet aggregators is it changes your personal blog from being a place where you can say whatever you want and have it only affect yourself, to a place where you have to watch what you say because it's automatically pushed to strangers who are only interested in very particular parts of who you are) Cheers, aj
Re: What do you expect from the DPL?
On Sat, Feb 14, 2015 at 02:41:18PM +0100, Stefano Zacchiroli wrote: On Sat, Feb 14, 2015 at 10:07:08AM +0100, Lucas Nussbaum wrote: My own view on the original question (What are you expected the DPL to do?) is that the main thing the DPL must absolutely do is being a good garbage collector (I think the original naming comes from Zack). Possibly. I think I actually used decision garbage collector, but the notion is exactly the one you explained. I wonder if that couldn't be framed a bit more positively. I reread HPMOR recently, and I wonder if the notion of heroic responsibility mightn't be applicable: You could call it heroic responsibility, maybe, Harry Potter said. Not like the usual sort. It means that whatever happens, no matter what, it's always your fault. Even if you tell Professor McGonagall, she's not responsible for what happens, you are. Following the school rules isn't an excuse, someone else being in charge isn't an excuse, even trying your best isn't an excuse. There just aren't any excuses, you've got to get the job done no matter what. -- http://hpmor.com/chapter/75 FWIW, that aspect of the DPL job seems to be frequently overlooked in DPL candidate platforms, which often tend to focus on ambitious Debian reform plans. To my mind, that's because there's a lack of obvious alternatives on how to do ambitious Debian reform plans -- or in particular establishing the moral and practical support for them. So in the same sense that the DPL is the final answer for trying to resolve disputes when everything else you can think of fails, it's also the answer for trying to make big changes when you run out of other idas. They are all fine and well of course, but DPL time will in the end have to be split among implementing those plans and tending to often unpredictable day by day duties, with the latter often dominating the DPL agenda (IME). I haven't seen any followup from the tech ctte on some of the disucssion from Dec about improving the way the ctte approaches requests, cf https://lists.debian.org/debian-vote/2014/12/msg00050.html https://lists.debian.org/debian-vote/2014/12/msg00069.html https://lists.debian.org/debian-vote/2014/12/msg00075.html Improvements there might help with the DPL's workload, in so far as that involves dealing with arguments over technical things. Cheers, aj -- 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/20150216035014.ga9...@master.debian.org
Re: About language specific package management tools
On Mon, Jan 26, 2015 at 02:15:22PM +, Sam Hartman wrote: One huge advantage of teaching our package management tools to understand alternate package technologies and convert on the fly is that we can use the mirror networks of the language-specific packages. Unfortunately, we're fairly picky about licensing issues and legal distributability of packages. The above's fair. But I don't think you can say: That's a significant value we add to Debian and it's really important. and then go on to say that it's hard so we should just wash our hands of the responsibility by letting our users go direct to upstream and deal with the problems themselves. Either it's valuable and it's worth doing, or it's not worth worrying about and not actually that valuable. It's not like the problem goes away if Debian ignores it: it still hits the upstream (distributing it in the first place), their mirror network (redistributing), and users (who might base their code or systems on libraries that they don't have any right to actually use). However, we'll probably find that if we tried to automate something we'd discover legal problems. The fact that CPAN, PyPI and others exist and function puts an upper bound on the problems that there are to be discovered. It's something they can manage, so it's something we could manage too. It's entirely possible that having two levels of vetting would be valuable to our users -- ie, our current level of NEW checking for main, and a CPAN/PyPI/etc minimal effort level of checking for extras. That's not much different to the main vs non-free split we already have, except that in this case it'd still be all about promoting free software. We'd discover confirming DFSG status difficult if we tried and that there are probably packages out there our users want that really when you look at it aren't actually even redistributable. That already happens occassionally with stuff in main, cf: http://snapshot.debian.org/removal/ Cheers, aj -- 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/20150130095414.ga14...@master.debian.org
Re: About the recent DD retirements
On Fri, Jan 23, 2015 at 10:03:08AM -0800, Don Armstrong wrote: On Fri, 23 Jan 2015, Anthony Towns wrote: CRAN has about 6k (~250 in Debian), Just to piggyback here, debian-r.debian.net has about 8.6k of these packages (bioc, cran, and omegahat). Talk about giving 110%! [0] Yes, I really think Debian should have 300k+ packages, including everything in all the language archives Handling this will probably require second-class packages, where we use automated tools to package the package, and hope for the best. In some ways, we're already starting to go that way,[1] but it would be nice to use all of Debian's infrastructure even for those second-class packages, too. Archive, mirrors, lintian, piuparts, other qa stuff, yep. Promotion to testing [1], maybe? BTS, I somewhat don't think so? NEW-esque license review seems impractical. Probably also wants an additional db tracking what upstream commit/whatever was converted to which Debian-ised version. Cheers, aj [0] Or more accurately 110% of 110% of 110% of 110% [1] Oh, dude! I finally thought of a possible rename for britney: pro-test as in promotion to testing. -- 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/20150124071757.gc17...@master.debian.org
Re: About the recent DD retirements
On Fri, Jan 23, 2015 at 11:29:19AM -0600, Gunnar Wolf wrote: Anthony Towns dijo [Fri, Jan 23, 2015 at 10:57:55AM +]: (Yes, I really think Debian should have 300k+ packages, including everything in all the language archives, no matter how special purposes (compare against the chiark* packages eg). My answer to this is that... A distribution should mostly cater to users. That means, we should target applications, not libraries. So I'm going to disagree with that in two ways. First, and more trivially, is that there are plenty of applications people want to run, that depend on unpackaged libraries that are a PITA to package. Etherpad is the example I already gave. Openrocket is another -- it's packaged as an installer that downloads the pre-build OpenRocket .jar file from the upstream site and instals it; because openrocket upstream likes using cool new java libraries for features and java libraries are a pain to package. ie, not having those libraries easily available in Debianised form /is/ one of the things that prevents people from running apps on Debian. Second, and more philosophically... Free software's about users not just being passive consumers, but treating them like co-developers. From fsf.org: Free software developers guarantee everyone equal rights to their programs; any user can study the source code, modify it, and share the program. If we *really* believe that, then we shouldn't just be about getting users some nice eary to install prepackaged apps, we should be about getting them the tools they need to make those apps do whatever they want, and even make apps of their own. Once upon a time the C library, a compiler and a debugger were state of the art for doing that; nowdays, pulling together bits of code from the hundreds of thousands of pre-written open source modules is. Oh, and as a bonus: third -- how much easier would packaging applications be, if all the libraries they used (and all the libraries we currently maintain) we're already packaged, essentially for free? By limiting our scope to what is actually wanted (i.e. by applications that have been ITPed or RFPed, Per the wnpp pages, there are: * 868 packages being worked on * 3434 requested packages That's a total of 4302, compared to 21554 source packages, that's just under 20%, so about two years worth of backlog at 10% growth in source packages per year. ie, Debian's already not coming close to keeping up with the actually wanted stuff. (Also, note that quite a lot of those are modules from various language sites already) Cheers, aj -- 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/20150124064646.gb17...@master.debian.org
Re: About language specific package management tools
On Fri, Jan 23, 2015 at 11:51:32AM +, Jonathan McDowell wrote: On Fri, Jan 23, 2015 at 10:57:55AM +, Anthony Towns wrote: It takes a couple of minutes to download something using pip or npm; how long does it take to get a python or nodejs Debianized and installable? (eg: learning that npm2deb exists, how to use it, what else you have to do to have a package, building the package, and getting apt access to the package -- which in turn presumably includes setting up and distributing an archive key) In an ideal world, users would just be able to say apt-get install lib-whatever-perl and have it. At worst, they might have to modify their apt sources explicitly to say yes, I know there's a lot of crap on CPAN that doesn't necessarily receive good security updates, I know what I'm doing. There's two ways that could be achieved: - having automated scripts pull everything from CPAN (et al), package it as debs, and publish it - having about 14,000 new DDs each individally maintaining 10-20 library packages But if the answer is oh, you want to use some random nodejs package? just npm it into /opt. if you want there's some tools to help start you off in packaging it too (Yes, I really think Debian should have 300k+ packages, including If this is being done in an automated fashion is there not a third option? Teach apt and associated tools about the language specific repositories. They'd do the download from CPAN or wherever, do the conversion, and pass to dpkg. On the fly, no need to expand the archive and no need to wait for the latest and greatest if you're that way inclined. For extra bonus points teach cpan, gem etc to still work but register the package + files with dpkg. Sure, that's an option. It seems more a gentoo-style approach than a Debian style approach to me. The main drawback to my mind is that I don't think it's as feasible: - if cpan/pypi/etc change their formats and the conversion scripts need updating, it'd have to be done on every system, rather than in one place - you'd still require a build environment just to use the modules on and end-user system - your end-user system relies on multiple mirror networks all working, rather than just the debian mirror network working - modifying apt is probably harder than just writing scripts that generate debs (On the other hand, just pointing users at urls and having them download stuff has fewer potential licensing issues) I think there are some issues with automated packaging which would mean that you'd still want hand crafted bits, You definitely want hand-crafted bits somewhere; ideally those would go in the upstream sources. Having them in a separate git repo could work too though; though that adds another dependency if you're expecting every user to have access to it. and there's the question of how you pin to a stable version (though I think often the reason people are pulling in from external sources is because the version in stable simply isn't recent enough, rather than unavailable) but it'd be Yep, that's certainly a question. You might be able to automate it via dependency analysis, britney-style, or use popcon-style statistics. I don't know how you'd choose versions either; would experimental/unstable/testing/stable be enough varieties? Would they even be useful? How would you deal with developing against one version of a module versus running an app using a different version? Coinstalled packages? Containers? kinda cool to have: cpan http://cpan.etla.org/ cran http://mirrors.ebi.ac.uk/CRAN/ etc in /etc/apt/sources.list and have it just work. I guess my theory was more along the lines of either: deb http://http.debian.net/debian/ testing main contrib extras (with them all combined into the extras component, and sharing the pool with Debian main), or deb http://http.debian.net/debian-extras/ testing cpan cran pypi deb http://http.debian.net/debian-extras/ unstable cpan npm (with a separate pool/ and separated by upstream archive) Same/similar result, different behind the scenes implementation. You could probably treat each different source as a different suite to aid with apt pinning (and by default preferring the Debian version rather than the external version). With the examples above it'd be: Pin: release c=extras or Pin: release o=Debian-extras or Pin: release o=Debian-extras, c=cpan, a=unstable Cheers, aj -- 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/20150124051340.ga17...@master.debian.org
Re: About the recent DD retirements
On Thu, Jan 22, 2015 at 07:02:51PM +0800, Paul Wise wrote: On Thu, Jan 22, 2015 at 6:28 PM, Anthony Towns wrote: - there are archive networks for most programming languages these days: CPAN, CRAN, Hackage, PyPI, RubyGems, NPM, CCAN, etc. Installing software from these sources is often necessary for Debian users, but doesn't mesh well with packaged software (unlss you're a DD and can package it yourself). Since it's all free software, I don't really see why Debian doesn't have a set of automatic tools to repackage all that software, so it's all just an apt-get away. We do: dh-make-perl, npm2deb, gem2deb, stdeb, cabal-debian etc which are intended to be wrapped by debdry to eliminate much of the initial packaging process. Sure, that works great if your model is there are a few thousand pieces of interesting software, and a few hundred packagers, each of whom can maintain tens of them. But CPAN has 30k modules (~3k in Debian), CRAN has about 6k (~250 in Debian), Hackage has 7k (~700 packaged), PyPI has about 54k (2500 packaged), RubyGems has about 95k (~6000 packaged?), npm has about 120k (266 packaged?). [0] There's obviously a seriously long tail of stuff that's not very interesting to many people in those numbers, but Debian's still at least an order of magnitude short of any of them. So what's that mean if you're either developing or installing random software? 1) ignore anything not in Debian and be hamstrung 2) use the language native packaging stuff 3) invest a lot of time skilling up on the various Debian utilities and package it yourself (including repackaging every update) 4) invest even more time so that your packages can be included in Debian It takes a couple of minutes to download something using pip or npm; how long does it take to get a python or nodejs Debianized and installable? (eg: learning that npm2deb exists, how to use it, what else you have to do to have a package, building the package, and getting apt access to the package -- which in turn presumably includes setting up and distributing an archive key) In an ideal world, users would just be able to say apt-get install lib-whatever-perl and have it. At worst, they might have to modify their apt sources explicitly to say yes, I know there's a lot of crap on CPAN that doesn't necessarily receive good security updates, I know what I'm doing. There's two ways that could be achieved: - having automated scripts pull everything from CPAN (et al), package it as debs, and publish it - having about 14,000 new DDs each individally maintaining 10-20 library packages But if the answer is oh, you want to use some random nodejs package? just npm it into /opt. if you want there's some tools to help start you off in packaging it too (Yes, I really think Debian should have 300k+ packages, including everything in all the language archives, no matter how special purposes (compare against the chiark* packages eg). By my count, jessie's at 20,700 source packages in main, which is about an 11% per annum growth rate since lenny, and indeed since sarge in 2005 [1]. If we'd stayed at about a 35% pa growth rate since woody then we'd be at around 200k source packages now, which I think would be the right order of magnitude for everything that's actually buildable in CPAN, and PyPI and so on being just an apt-get away.) - perhaps it's all been fixed since I last looked, but web apps still don't seem to be a solved problem to me. If you install, say, libreoffice, you run apt-get (or whatever), then you run libreoffice, and you're done. But if you want to install wordpress, you have a whole bunch of additional steps to go through [1]. We have a web app policy but it is fairly abandoned. Isn't that statement alone a pretty clear indication that Debian's not addressing the packaging problems of today? There are some external projects in this space, like sandstorm and juju. (And that one too... Also, unless I'm mistaken neither are packaged in Debian; apparently juju got dropped over a year and a half ago, bug#716754) The wordpress wiki page seems to miss the wp-setup script that is in the package now. The manpage says For now, it's mainly for the package's internal usage though. - application isolation is a popular issue now, often solved by blatting whole OS images around (VMs, docker, ...). That brings up a whole host of packaging issues (how do you create the image, how do you keep it up to date, how do you distribute the image) systemd has some great isolation features that use the same Linux kernel APIs as docker/etc. The GNOME folks are working on application isolation for the desktop: http://blogs.gnome.org/mclasen/2015/01/21/sandboxed-applications-for-gnome/ Why is that something the GNOME folks are doing, but the Debian folks aren't? If Debian's just about packaging, sandboxing applications (eg, apache being sandboxed from
Re: About the recent DD retirements
On Wed, Jan 21, 2015 at 06:46:16PM -0800, Russ Allbery wrote: Gunnar Wolf gw...@gwolf.org writes: ... And yes, maybe Debian is less attractive in general ... One side effect of this is that packaging feels like a solved problem. If so (and assuming that's all Debian's about), then that'd be a good reason to consider Debian a mature project and the only thing that's really needed is enough people to keep the lights on. I think that's a meritorious [0] argument. Personally, I'd argue the other side though. Packaging works fine within Debian -- which is certainly an improvement on how things were in the 90s (or even ten yars ago); but there are a bunch of unsolved problems in the area. For instance: - there are archive networks for most programming languages these days: CPAN, CRAN, Hackage, PyPI, RubyGems, NPM, CCAN, etc. Installing software from these sources is often necessary for Debian users, but doesn't mesh well with packaged software (unlss you're a DD and can package it yourself). Since it's all free software, I don't really see why Debian doesn't have a set of automatic tools to repackage all that software, so it's all just an apt-get away. - perhaps it's all been fixed since I last looked, but web apps still don't seem to be a solved problem to me. If you install, say, libreoffice, you run apt-get (or whatever), then you run libreoffice, and you're done. But if you want to install wordpress, you have a whole bunch of additional steps to go through [1]. - application isolation is a popular issue now, often solved by blatting whole OS images around (VMs, docker, ...). That brings up a whole host of packaging issues (how do you create the image, how do you keep it up to date, how do you distribute the image) Other folks are answering those questions -- eg in order to run my own instance of etherpad [2], I found that it needs some nodejs modules that aren't packaged, so rather than jump through the hoops to Debianise it, I created a docker instance for it, and followed the upstream instructions to install it, and put a port redirect in place via systemd. Of course, that system is out of date (because I forget to login to run apt-get on it, and who knows what the npm packages are up to). And, of course, I run Linux systems that aren't Debian these days -- I have both a phone and a tablet. In some sense you could say they're kind-of open hardware running free software, but both running my own software on them or rebuilding what's already on there aren't things I can actually do. That's not because they're .apk's rather than .deb's, but more because (as far as I've looked anyway) the android ecosystem doesn't have the same build-package-distribute infrastructure that distros like Debian and Fedora have built and now take for granted. Oh, for heaven's sake, how could I almost forget to mention the reproducible builds effort? I don't know how the laws of reality changed to make that possible let alone feasible, but wow. And that /is/ even being addressed in Debian [3]. But some of it is also inevitable. A lot of smart, talented people want to work on really hard problems that are currently major pain points, since that's where they can have the most leverage. Packaging just *isn't* that any more, ... So I'd say there are plenty of major pain points in this space that are hard and interesting and attract smart, talented people. Heck, Docker got a $.4B valuation [4] a few months ago just a few months ago. Why aren't those people doing things in Debian? I claim two reasons: 1) because they can make (more/any) money doing it elsewhere; and 2) because Debian folks are more interested in the solved problems of the 90s than the problems of today. Cheers, aj [0] *Not* meretricious as I was about to write. Thankyou dict. [1] https://wiki.debian.org/WordPress#Basic_Installation_guide_for_Wheezy [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576998 [3] https://people.debian.org/~lunar/blog/posts/eighty_percent/ (This should totally be posted to d-d-a) [4] http://www.bloomberg.com/news/2014-09-16/docker-said-to-be-valued-at-400-million-in-funding-round.html -- 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/20150122102845.ga18...@master.debian.org
Fwd: Maximum term for tech ctte members
On 26 June 2014 08:18, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Anthony Towns writes (Re: Maximum term for tech ctte members): - Term limit: Every 1st of November, the most senior member of the Technical Committee's is immediately and automatically removed from the Committee, if in the preceding 27 months less than two new Committee members have been appointed. Seniority is determined by a member's most recent date of appointment to the Committee, with ties broken by length of membership in the Project. 27 months prior to November 1st is August 1st two years prior. (Is there any particular rationale for Nov 1st?) So by my count, that would result in: - 2014-11-01: Keith appointed in the previous 27 months, Ian removed; Alice appointed - 2015-11-01: Keith and Alice appointed in the previous 27 months, no compulsory removal - 2016-11-01: Alice appointed in the previous 27 months, Bdale removed, Bob appointed - 2017-11-01: Bob appointed in previous 27 months, Steve removed, Carol appointed - 2018-11-01: Bob and Carol appointed in the previous 27 months, no compulsory removal - 2019-11-01: Carol appointed in previous 27 months, Andi removed, Dave appointed - 2020-11-01: Dave appointed in previous 27 months, Don removed, Emma appointed - 2021-11-01: Dave and Emma in previous 27, no compulsory removal - 2022-11-01: Emma in previous 27, Russ removed, Fred appointed - 2023-11-01: Fred in prev 27; Colin removed, Gwen appointed - 2023-11-01: Fred and Gwen in prev 27, no compulsory removal - 2024-11-01: Gwen in prev 27, Keith removed, Henry appointed - 2024-11-01: Henry in prev 27, Alice removed, ... Total term lengths would then be: - Ian: 16 years (1998-2014) - Bdale: 15 years (2001-2016) - Steve: 11 years (2006-2017) - Andreas: 13 years (2006-2019) - Don: 11 years (2009-2020) - Russ: 13 years (2009-2022) - Colin: 12 years (2011-2023) - Keith: 11 years (2013-2024) - Alice: 10 years (2014-2024) That seems overly long. But adding non-normative text: The Technical Committee should arrange to appoint fresh members on a regular basis, at least as often (and probably more often) than the minimum specified here. That's only possible when the ctte isn't full; if the ctte's full, the only way to refresh members is for someone to be removed... If the idea is to leave have some spare slots on the committee on an ongoing basis, that may mean even longer terms than implied above, eg an additional twelve months for Steve: - 2014-11-01: Keith appointed in the previous 27 months, Ian removed; - 2015-10-30: Alice appointed - 2015-11-01: Keith and Alice appointed in the previous 27 months, no compulsory removal - 2016-11-01: Alice appointed in the previous 27 months, Bdale removed - 2017-10-30: Bob appointed - 2017-11-01: Allice and Bob appointed in previous 27 months, no compulsory removal - 2018-11-01: Bob appointed in prev 27, Steve removed I think 6 years is probably a better actual term than 9 or 4.5. So I would be in favour of the TC running an election for 1 place every 18 months. 1 place every 18 months would be an average term of 8x1.5 = 12 years, or 9x1.5 = 13.5 years... - For the purposes of seniority and term expiry, someone who leaves the committee but rejoins it less than 10 months later, is treated as having been a member continuously throughout that gap. I don't think that would have any teeth: 2014-11-01: only one recent appointment, Ian most senior, Ian removed 2014-11-02: Ian reappointed, term treated as continuous 2015-11-01: only one recent appointment, Ian most senior, Ian removed 2015-11-02: Ian reappointed, term treated as continuous 2016-11-01: no recent appointments, Ian most senior, Ian removed 2016-11-02: Ian reappointed, term treated as continuous ... [on your earlier non-specified-date scheme:] But it sure gets confusing, especially with Colin having to resign after four years in order to be re-appointed to serve eight years, rather than maxing out at about six years and not being immediately re-appointable. Worse still with Keith who (I think) would max out after 3 and a bit years, get reappointed, and would then have to resign a few months later and get reappointed in order to max out at eight years... This is a consequence of the rule running continuously rather than at fixed intervals. No, it's a consequence of the rule allowing for approximately one immediate re-appointment. The combination of: - The committee's membership will be reviewed annually on August 16th. - At that point, if there have not been at least two members leave the committee in the past 12 months, the most senior committee member's term expires immediately. - In addition, if there are more than five members in the committee, and no members have left the committee in the the past 12 months, the second most senior committee member's term also expires immediately
Re: Maximum term for tech ctte members
On 29 June 2014 19:14, Anthony Towns a...@erisian.com.au wrote: On 26 June 2014 08:18, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Anthony Towns writes (Re: Maximum term for tech ctte members): - Term limit: Every 1st of November, the most senior member of the Technical Committee's is immediately and automatically removed from the Committee, if in the preceding 27 months less than two new Committee members have been appointed. Seniority is determined by a member's most recent date of appointment to the Committee, with ties broken by length of membership in the Project. 27 months prior to November 1st is August 1st two years prior. (Is there any particular rationale for Nov 1st?) So by my count, that would result in: I missed the potential interaction with increasing the committee size to 9. With a two week minimum discussion period and a two week voting period, the earliest that could be accepted would be July 30th or so, so it seems likely that would result in an extra appointment in the period between Aug 1st 2014 and Nov 1st 2014. Combined with the above, that's something more like: 2014-09-01 Zach appointed as 9th ctte member 2014-11-01 Keith @ 12 months, Zach @ 2 months, no compulsory removals 2015-11-01 Keith @ 24 months, Zach @ 14 months, no compulsory removals 2016-11-01 Zach @ 26 months, Ian removed, Alice appointed 2017-11-01 Alice @ 12 months, Bdale removed, Bob appointed 2018-11-01 Alice @ 24 months, Bob @ 12 months, no compulsory removals 2019-11-01 Bob @ 24 months, Steve removed, Carol appointed 2020-11-01 Carol @ 12 months, Andi removed, Dave appointed 2021-11-01 Carol @ 24 months, Dave @ 12 months, no compulsory removals 2022-11-01 Dave @ 24 months, Don removed, Emma appointed 2023-11-01 Emma @ 12 months, Russ removed, Fred appointed 2024-11-01 Emma @ 24 months, Fred @ 12 months, no compulsory removals 2025-11-01 Fred @ 24 months, Colin removed, Gwen appointed 2026-11-01 Gwen @ 12 months, Keith removed, Harry appointed 2027-11-01 Gwen @ 24 months, Harry @ 12 months, no compulsory removals 2028-11-01 Harry @ 24 months, Zach removed, Irene appointed 2029-11-01 Irene @ 12 months, Alice removed, Jack appointed Total term lengths would then be: - Ian: 18 years (1998-2016) - Bdale: 16 years (2001-2017) - Steve: 13 years (2006-2019) - Andreas: 14 years (2006-2020) - Don: 13 years (2009-2022) - Russ: 14 years (2009-2023) - Colin: 14 years (2011-2025) - Keith: 13 years (2013-2026) - Zach: 13 years (2014-2028) - Alice: 13 years (2016-2029) ie, an additional couple of years for each member compared to my previous simulation: Total term lengths would then be: - Ian: 16 years (1998-2014) - Bdale: 15 years (2001-2016) - Steve: 11 years (2006-2017) - Andreas: 13 years (2006-2019) - Don: 11 years (2009-2020) - Russ: 13 years (2009-2022) - Colin: 12 years (2011-2023) - Keith: 11 years (2013-2024) - Alice: 10 years (2014-2024) I think that leaves me still leaning towards the following or something pretty close to it: - On August 16th of each year, the terms of any Committee Members who have served on the committee for 50 months (4 years and 2 months) or more will ordinarily automatically expire. However an individual member's term may be extended for an additional twelve months if there are two or more Committee Members who have either served on the Committee for a longer continuous period or left the Committee in the preceding twelve months. - A developer is not eligible to be reappointed to the Committee if they have been a member of the Committee at any time in the preceding twelve months. Cheers, aj -- Anthony Towns a...@erisian.com.au -- 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/cajs_lcuxd00xdbyzlo6_-ubeqpv9rqhapams9herezmh3bj...@mail.gmail.com
Re: Maximum term for tech ctte members
On 30 May 2014 19:37, Anthony Towns a...@erisian.com.au wrote: I might have another go at seeing if I can word it for rolling twelve months, to see if that's workable. Okay, so I gave it a go, and came up with: - A Technical Committee member's term will end upon resignation, removal or expiry. - A Technical Committee member may resign by stating such in public email to the committee discussion list. - If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. - The most senior member of the Technical Committee's term expires immediately, if in the preceding twelve months fewer than two Committee members' terms have ended. Seniority is determined by a member's most recent date of appointment to the Committee, with ties broken by length of membership in the Project. That should work okay along with: - A developer is not eligible to be reappointed to the committee if they have been a member for more than four of the past five years. But it sure gets confusing, especially with Colin having to resign after four years in order to be re-appointed to serve eight years, rather than maxing out at about six years and not being immediately re-appointable. Worse still with Keith who (I think) would max out after 3 and a bit years, get reappointed, and would then have to resign a few months later and get reappointed in order to max out at eight years... Maybe it would be simpler and better to go with something like: - On August 16th of each year, the terms of any Committee Members who have served on the committee for six or more years will ordinarily automatically expire. However an individual member's term may be extended for the next year, if two or more Committee Members have either left the Committee in the preceding twelve months, or served on the Committee for a longer continuous period. - A developer is not eligible to be reappointed to the Committee if they have been a member of the Committee at any time in the preceding twelve months. Assuming no one resigns or gets reappointed to the committee, that would mean: - Aug 16 2014 - Ian (16y), Bdale (14y) out; Alice, Bob in - Aug 16 2015 - Steve (10y), Andi (10y) out; Carol, Dave in - Aug 16 2016 - Russ (7y), Don (7y) out, Emma, Fred in - Aug 16 2017 - Colin (6y) out, Greta in - Aug 16 2018 - [no change] - Aug 16 2019 - [no change] - Aug 16 2020 - Keith (7y) out, Henry in Leaving: Alice, Bob - 6 years in Carol, Dave - 5 years in Emma, Fred - 4 years in Greta - 3 years in Henry - fresh blood Specifying six years means you effectively get seven years though, unless appointments manage to happen on or before Aug 16th. 5.5 years is probably better, which would bring Keith's term back to 2019, and result in just under six years in practice, I think. 4.5 years would get to Stefano's suggestion of 5y on / 1y off, which might look like: - Aug 16 2014 - Ian (16y), Bdale (14y) out; Alice, Bob in - Aug 16 2015 - Steve (10y), Andi (10y) out; Carol, Dave in - Aug 16 2016 - Russ (7y), Don (7y) out, Emma, Fred in - Aug 16 2017 - Colin (6y) out, Greta in - Aug 16 2018 - Keith (5y) out, Henry in Leaving: Alice, Bob - 4 years in Carol, Dave - 3 years in Emma, Fred - 2 years in Greta - 1 year in Henry - fresh blood Cheers, aj -- 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/cajs_lcveknrent4r3zjqdkc1wu0_4ufghun6+emj1ose1wd...@mail.gmail.com
Re: Maximum term for tech ctte members
On Mon, May 26, 2014 at 07:58:45PM -0700, Russ Allbery wrote: I'm still skeptical that something built around people typically serving for eight years is the sort of turnover we want, but it's the conservative approach and doesn't change too much at once. Which has some definite merits. I'm not sure that two terms would necessarily be the normal case; I suspect some of that is just that having to quit and appoint a new member to the ctte is work and it's always easier to just let things be. Having thought about it some more, I don't think longest serving ctte member's term ends on date, unconditionally is a good rule. For one thing, it means that on day-before-date, the longest serving ctte member can resign and force the second longest serving ctte member's term to end prematurely. I might have another go at seeing if I can word it for rolling twelve months, to see if that's workable. Possible candidacy rules: - A developer is not eligible to rejoin the committee if they have been a member for more than four of the past five years. (Max two consecutive terms, roughly) I think this is my preference. Yeah, it seems plausible. - When considering candidates for inclusion in the committee, the ballot must include at least one candidate who has not been a member of the committee in the previous four years. (Enforce considering new members, not necessarily having them) The social pressures here don't work very well. In general, any approach that has the existing committee decide whether to retain a member who's already on the committee has the potential for hard feelings, creating future difficulties working together, and so forth. Yeah, that's a fairly persuasive argument. - Any eligible developer nominated by the DPL or by at least two developers in the period between August 1st and August 16th will be considered for appointment to the committee, and be included on the next ballot. Any developer so nominated may, however, withdraw their nomination if they so choose. I'm not sure there's any need to say something about this, Me either. Cheers, aj -- 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/20140530093749.ga20...@master.debian.org
Re: Maximum term for tech ctte members
On Mon, May 26, 2014 at 11:02:17AM +1000, Zenaan Harkness wrote: The Australian senate (our federal parliament) has 8 year terms. In (6 year terms; same as the US senate as it happens. We have 3 years terms the house of reps and hence prime minister as compared to 2 year terms for the US hous of reps or the 4 year term of the US President) Cheers, aj -- 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/20140526102107.ga15...@master.debian.org
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 02:09:35PM -0400, Michael Gilbert wrote: 8 seems like it would be near ideal: turnover is dealt with only about once per year, it is close to the average of the existing members terms (7.385 years), and it's likely close the historical average (although I haven't calculated that, would be interesting for someone to research). Going by the CVS history of the www.debian.org/intro/organization page, past ctte members had terms of: Manoj Srivastava ~14y 1998-12-14 - 2012-08-30 (* - 1.440) https://lists.debian.org/debian-ctte/2012/08/msg00028.html Raul Miller ~ 9y 1998-12-14 - 2007-06-14 (* - 1.244) https://lists.debian.org/debian-ctte/2007/04/msg00019.html Guy Maor ~ 7y 1998-12-14 - 2006-01-05 (* - 1.186) https://lists.debian.org/debian-ctte/2005/12/msg2.html Wichert Akkerman ~ 5y 2001-04-23 - 2006-01-05 (1.40 - 1.186) https://lists.debian.org/debian-ctte/2005/12/msg0.html Jason Gunthorpe ~ 5y 2001-06-01 - 2006-01-05 (1.42 - 1.186) https://lists.debian.org/debian-ctte/2005/12/msg0.html Dale Scheetz ~ 4y 1998-12-14 - 2002-10-16 (* - 1.84) https://lists.debian.org/debian-ctte/2002/10/msg7.html Anthony Towns ~ 3y 2006-01-05 - 2009-01-06 (1.186 - 1.312) https://lists.debian.org/debian-ctte/2009/01/msg6.html Klee Dienes ~ 2.5y 1998-12-14 - 2001-06-01 (* - 1.42) https://lists.debian.org/debian-ctte/2001/05/msg00010.html I've put the CVS revision id in brackets for the relevant commits to organization.data in the webwml tree for verification purposes, and based on the commit dates had a look in the -ctte archives for what seem to be the relevant removal mails. That's an average of ~6 years, and a median of 5 years; but that should probably be scaled down given the lack of involvement of most of those folks towards the end of their terms... Cheers, aj -- 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/20140526103955.gb15...@master.debian.org
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 10:37:05AM -0700, Russ Allbery wrote: If we want the opportunity to appoint new members regularly, rather than expire old members per se, we could just say that: on July 1st, the two longest serving ctte members' term expires to end up with (on average) four year terms... [...] Yeah, that would achieve the same goals I had in mind and might be a better idea. Okay, let's see where that goes... I don't know if it makes sense to have two people's terms expire at the same time or to have one person expire every six months. Or, in general, n people's terms expire every 6n months. You could have 3 people every 18 months, or 4 people every 2 years too. We could combine both features, though: set a term length of two years, and then say that people can serve for two terms in succession but then have to leave the committee for at least one term. Two year terms would be electing (up to) four people a year. That seems a lot? Eg, assuming two year term, and one year ineligible after two consecutive terms, that'd be: 2014: Alice, Bob re-elected; Carol, Dave newly-elected 2015: Emma, Fred re-elected; Greta, Henry newly-elected 2016: Carol, Dave re-elected; Ivy, Jason newly-elected (Alice, Bob ineligible) 2017: Greta, Henry re-elected; Karen, Larry newly-elected (Emma, Fred ineligible) 2018: Ivy, Jason re-elected; Miley, Nathan newly-elected (Carol, Dave ineligible) ... Given only four tech ctte members have been on the ctte less than essentially four years (Klee, who was an original member; myself, who chose to not stay longer than 3 years; and Keith and Colin who are both still serving), it seems to me like four years is a reasonable lower-bound. For the sake of something concrete to improve upon, how about, ummm... - The committee's membership will be reviewed annually on August 16th. - At that point, if there have not been at least two members leave the committee in the past 12 months, the most senior committee member's term expires immediately. - In addition, if there are more than five members in the committee, and no members have left the committee in the the past 12 months, the second most senior committee member's term also expires immediately. - A member's seniority is determined by the date of their most recent appointment to the committee. In the case of multiple members appointed to the committee on the same day, ties are broken based on their debian.org uid (lower uid, more senior). August 16th, because that's Debian's birthday, and choosing an arbitrary date seemed to make it easier to deal with. Having it be a continuously rolling 12 months could be a good idea if it can be worded reasonably? Also possible would be just having the most senior ctte member's term expire on Aug 16th unconditionally. To make it two year terms, make the four most senior people's terms expire each year. To make it six year terms, you'd probably have to go with a rolling 18 month period. There's nothing in the above preventing a member from being immediately reappointed once their term expires, if the remaining committee vote and the DPL agrees. However... Possible candidacy rules: - A developer is not eligible to rejoin the committee if they have been a member of the committee within the preceeding twelve months. (One term, then a break) - A developer is not eligible to rejoin the committee if they have been a member for more than four of the past five years. (Max two consecutive terms, roughly) - A developer is not eligible to rejoin the committee unless another appointment has been made since they were most recenty a member. (No term limit per se, but continually enforce some new blood) - When considering candidates for inclusion in the committee, the ballot must include at least one candidate who has not been a member of the committee in the previous four years. (Enforce considering new members, not necessarily having them) - Any eligible developer nominated by the DPL or by at least two developers in the period between August 1st and August 16th will be considered for appointment to the committee, and be included on the next ballot. Any developer so nominated may, however, withdraw their nomination if they so choose. (Enforce more meaningful consideration of new members, and provide a nomination mechanism) (This would work well with always expiring the most senior member's term, because then there would be a guaranteed vacancy to fill after August 16th, so nominations would always be relevant; even if none might actually end up being appointed) I've got a weak preference for the later options that don't set hard term limits, personally. Cheers, aj -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: Maximum term for tech ctte members
On Mon, May 26, 2014 at 09:02:25AM +0200, Matthias Urlichs wrote: Russ Allbery: I had picked four-year terms because I think adding one member every six months (or two members every year) is probably near the upper limit of membership management that the TC can deal with and still get other things done, and at the same time I think four years is near the upper limit for meaningful term lengths. Eight years is an eternity in free software. That may be true, but our release cycles also feel like an eternity :-P and it might make sense to have, say, at least one TC member on board who has been on the TC at least since the current oldstable was released. So the periods between release n and n-2 have been: 4y10m - 3.1 sarge June 6th 2005 4y9m - 4.0 etch Apr 8th 2007 4y3m - 7.0 wheezy May 4th 2013 3y10m - 6.0 squeeze February 6th 2011 3y8m - 5.0 lenny February 14th 2009 3y4m - 3.0 woody July 19th 2002 2y4m - 2.1 slink March 9th 1999 2y1m - 2.2 potato August 15th 2000 1y10m - 0.93R6 November 1995 1y7m - 2.0 hamm July 24th 1998 1y3m - 1.1 buzz June 17th 1996 1y1m - 1.3 bo July 2nd 1997 1y1m - 1.2 rex December 12th 1996 Though aiui, the security team only support oldstable for 1 year after the release date of stable (previously 6 months), so the effective life of oldstable releases is probably shorter than the times above. Cheers, aj -- 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/20140527025244.ga11...@master.debian.org
Re: Maximum term for tech ctte members
On Sat, May 24, 2014 at 11:37:53AM -0700, Russ Allbery wrote: Yeah; I don't think that's a bad rule in general, but I'm not convinced it's a great fit for the tech-ctte. The thought experiment that makes me doubt it is if a compulsory x year break after n years of service makes sense in general, shouldn't it make sense now?, or equally, if it's too painful for us to do things this way now, why won't it be equally painful in future (eg if we end up appointing four members at the same time, and having their terms all expire at the same time as a consequence)?. Well, I guess my point is that I think it *is* a good idea now. Hmm, that doesn't really get to the point I was trying to reach. How about: Which is more important, avoiding sudden upheavals where possible, or ensuring individual ctte members have breaks? If the latter's more important, then it's better not to special case things now; if the former's more important, shouldn't whatever rule take that into account in case we end up in a similar situation in future? If so, then there's also no need for special casing now... Without special casing, it might be hard to reconstitute the ctte from just Coin and Keith (assuming terms of less than six years) if all the existing members were unavailable to be re-included. I don't know that it'd actually be that hard though -- they could just appoint two members initially to get up to the constitutionally recommended at least 4, then add to that over the next few years to get up to a steady state of 8 ctte members with 2 appointed each year... An approach like: If we want the opportunity to appoint new members regularly, rather than expire old members per se, we could just say that: on July 1st, the two longest serving ctte members' term expires to end up with (on average) four year terms... [...] would work for avoiding sudden upheavals where possible (if everyone resigned simultaneously, you're still stuck, eg), but still supports reviewing or cycling through members, IMO. Any thoughts on that sort of approach? I would have thought deliberate scaling would make more sense than random assignment, eg, tech ctte members have four year terms; for the purpose of this rule the existing members are deemed to have been appointed at: Ian, Bdale:2010-12-01 (expiry 2014-11-30) Andi, Steve: 2011-12-01 (expiry 2015-11-30) Russ, Don: 2012-12-01 (expiry 2016-11-30) Colin, Keith: 2013-12-01 (expiry 2017-11-30) I was not particularly clear on what I meant by random assignment. What I had intended was to designate six artificial start of term points in the past four years and then have all the members who have served for over four years to just draw those out of a hat. Not completely randomly generating a start date. Colin's already at 2.75 years; so if the artificial start-of-term points weren't limited to being between, say, May 2010 and Aug 2011, you'd have some of the oldbies' terms expiring after Colin, despite being appointed before Colin. If you did set them all in that 15 month period, you'd still have 6 of 8 ctte members terms expiring in, well, the next 15 months -- which seems about as bad as having them all expire now to me. Less of a problem with longer terms, though. BTW, I've been using four years because it's a nice round number and reasonably short; did you think it was a good number, or were you just using it as an example too? Based on how long current folks have been on the ctte, I could see 8 years being plausible too, though anything more than that seems overly long to me. Cheers, aj -- 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/20140525073157.GA8558@debian
Re: Maximum term for tech ctte members
On Thu, May 22, 2014 at 06:40:22PM -0700, Russ Allbery wrote: Anthony Towns a...@erisian.com.au writes: Would anyone else be supportive of a proposal to set a term for tech ctte membership? I just mentioned this today in our TC meeting, so obviously I've been thinking along these lines as well and have been wondering if this would be a good idea. Cool. I think set terms, with no term limits would make sense (ie, you're appointed to the ctte, you stay on it for X years, then you either say thanks, but enough's enough or that was fun, I'd like to keep doing it and the ctte and DPL considers whether to reappoint you in the usual fashion. Other bodies of this type take a variation on this approach (and of the reappointment rule you propose below) that I quite like: after each term, that member may not be reappointed for some period. For example, we could say that members serve for four years, and after that four-year period they cannot be reappointed to the TC for at least two years. Yeah; I don't think that's a bad rule in general, but I'm not convinced it's a great fit for the tech-ctte. The thought experiment that makes me doubt it is if a compulsory x year break after n years of service makes sense in general, shouldn't it make sense now?, or equally, if it's too painful for us to do things this way now, why won't it be equally painful in future (eg if we end up appointing four members at the same time, and having their terms all expire at the same time as a consequence)?. Even if you set n as high as 13 years, that'd mean Bdale and Ian would be due for a compulsory break, despite (from my impression) them both being enthusiastic contributors. I was thinking of the have to appoint someone different rule I suggested because that would at least mean you could do something like set n=6, have Steve, Andi, Bdale and Ian's term expire immediately, but still reappoint up to three of them almost immediately. I'm not really convinced by the idea either, though. Another approach might be, say, four year terms, with a compuslory two year break after eight years. One approach we could take to this would be to randomly assign each existing member (except maybe Keith and Colin) to an artificial start of term date distributed across the past three or four years, for the purposes of deciding when our current term ends. That would build in some transition time and spread new member selection out in a sustainable way. I would have thought deliberate scaling would make more sense than random assignment, eg, tech ctte members have four year terms; for the purpose of this rule the existing members are deemed to have been appointed at: Ian, Bdale:2010-12-01 (expiry 2014-11-30) Andi, Steve: 2011-12-01 (expiry 2015-11-30) Russ, Don: 2012-12-01 (expiry 2016-11-30) Colin, Keith: 2013-12-01 (expiry 2017-11-30) That still rubs me a bit the wrong way though -- we limit the tech ctte to 4 years each, which for Ian means 16 years, for Bdale means almost 14 years, for Andi and Steve it means 10 years, for Russ and Don it means 8 years, for Colin it means six years, and for Keith it means 4 years. And again, sure, you can't change the past, but if it's good for tech ctte members to be reviewed or put on a break after X years, excluding the current members who've served X years from the rule just doesn't seem sound to me. If we want the opportunity to appoint new members regularly, rather than expire old members per se, we could just say that: on July 1st, the two longest serving ctte members' term expires to end up with (on average) four year terms... Probably needs some tweaking though -- maybe it ought only apply if nobody's resigned in the previous 12 months or something. Cheers, aj -- 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/20140524071325.ga8...@master.debian.org
Re: Maximum term for tech ctte members
On Sat, May 24, 2014 at 01:07:11AM +0200, Stefano Zacchiroli wrote: On Fri, May 23, 2014 at 06:58:36PM +0200, Tollef Fog Heen wrote: I believe a maximum of 5 years in a row with a minimum 1-year suspension before being able to join again would work well for our tech-ctte. I think 5 years would be awkward in an 8-member ctte; you'd end up with: 2010: 2 members appointed 2011: 2 members appointed 2012: 1 member appointed 2013: 2 members appointed 2014: 1 member appointed 2015: 2 members replaced ... 4 years is easy (2 members per year), as is 8 years (1 member per year), and 6 years isn't too bad (4 members every three years; or 2 members every year and half). Bumping the ctte size to 10 members could make 5 years work of course. Think it makes sense to have the term proportional to the ctte size though, so turn over can be regular. Cheers, aj -- 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/20140524072740.gb8...@master.debian.org
Re: Maximum term for tech ctte members
On Sat, May 24, 2014 at 01:07:11AM +0200, Stefano Zacchiroli wrote: - continuity is valuable in a body like the tech-ctte, where there aren't that many decisions on a yearly basis (and hence, for instance, it takes time to get new members up to speed). You could get continuity by having past members continue to participate in tech ctte discussions; they just wouldn't get a vote in the outcome... Also, new ctte members could have been participating in ctte discussions previously (or just general Debian development issues on -devel, -policy, etc), so they kind-of should be mostly up to speed already. Keith was appointed in December, and engaged in the init system question by January, eg. Cheers, aj -- 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/20140524073237.gc8...@master.debian.org
Maximum term for tech ctte members
Hello world, Would anyone else be supportive of a proposal to set a term for tech ctte membership? The current tech ctte members were appointed: Ian: May/Dec 1998 (15 years, 5 months) [0] Bdale: Apr 2001 (13 years, 1 month) [1] Andreas: Jan 2006 (8 years, 4 months) [2] Steve: Jan 2006 (8 years, 4 months) [2] Russ: Jan 2009 (5 years, 4 months) [3] Don: Jan 2009 (5 years, 4 months) [3] Colin: Aug 2011 (2 years, 9 months) [4] Keith: Nov 2013 (6 months) [5] I think set terms, with no term limits would make sense (ie, you're appointed to the ctte, you stay on it for X years, then you either say thanks, but enough's enough or that was fun, I'd like to keep doing it and the ctte and DPL considers whether to reappoint you in the usual fashion. Personally, I think 3 or 4 year terms ought to be long enough, but that would mean kicking everyone but Colin and Keith off the ctte immediately. Terms of 6-8 years would leave half the current ctte around to reconstitute the ctte. With a term of 16 years (which no member has exceeded yet), a new member would have to be voted on once every two years on average to maintain a full 8-member ctte. I think it'd be healthy if there was a rule something like an ex-member may not be reappointed to the committee unless someone else has been appointed to the ctte since s/he was last a member. That would mean you couldn'y have Alice, Bob, Carol, Dave as the tech ctte with an agreement that they'll just reappoint each other anytime their term expires; they'd have to appoint someone from outside the group (Emma, say) first. Call it an anti-Cabal measure. I'm not sure there's a simple and obvious way to phrase such a measure though, so maybe it's too hard. At present, the only way for someone to leave the tech ctte is for them to disappear, resign, or be hounded out by either their fellow ctte members or a GR. IMO, it would be nice if there was a way out of the ctte that had more of a feeling of winning / leaving at the top of the game than those. YMMV. I think I'd rather second a proposal along these lines than actually propose it... Cheers, aj [0] https://lists.debian.org/debian-devel/1998/05/msg01546.html https://lists.debian.org/debian-announce/1998/msg00047.html [1] https://lists.debian.org/debian-ctte/2001/04/msg00025.html [2] https://lists.debian.org/debian-project/2006/01/msg00013.html [3] https://lists.debian.org/debian-ctte/2009/01/msg00053.html [4] https://lists.debian.org/debian-devel-announce/2011/08/msg4.html [5] https://lists.debian.org/debian-devel-announce/2013/11/msg9.html -- 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/20140523011634.ga25...@master.debian.org
Synchronising with Ubuntu
On Mon, Aug 03, 2009 at 03:55:16PM +, Anthony Towns wrote: etch: 2006/12 - 2007/04 (decent hit for feisty's import freeze) lenny: 2008/07 - 2009/02 (decent hit for jaunty's import freeze) dapper and hardy are the two Ubuntu LTS releases so far, dapper reached its desktop end-of-life a couple of weeks ago. feisty hit its end-of-life in October last year. I'm just extrapolating from karmic's release schedule; I haven't checked the schedules weren't different historically. Based on that, comparing universe packages in etch-vs-feisty and lenny-vs-jaunty for version differences, and any differences in security updates could be interesting, actually. Turns out it kind-of is, too. First, basics: etch: froze in December 2006, released in April 2007; still supported feisty: DebianImportFreeze in Dec 2006, UpstreamVersionFreeze in Feb 2007, released in April 2007; support ended October 2008 Comparison between etch/main and feisty/main+universe by source: 6874 exact same source 132 only in Debian 2273 only in Ubuntu 600 newer upstream version in Debian 1538 newer upstream version in Ubuntu 1079 Ubuntu has Vebian bersion with ubuntuXX patch As at today (2009/08/11) etch/feisty security support compare as follows: 63 packages with security updates in both Debian and Ubuntu (11 same version, 8 where Debian has new upstram, 28 where Ubuntu has new upstream, 16 where Ubuntu applied patches to Debian version) 5 updates in Debian to Debian only packages 7 updates in Ubuntu to Ubuntu only packages 31 updates in Debian to packages with the exact same source in Ubuntu 6 updates in Ubuntu to packages with the exact same source in Debian (!) 42 packages updated in Debian but not Ubuntu (6 where Debian has newer upstream, 30 where Ubuntu has newer upstream, and 6 with ubuntuXX patches) 15 packages updated in Ubuntu but not Debian (4 where Debian has newer upstream, 6 where Ubuntu has newer upstream, and 5 with ubuntuXX patches) Of the 31 updates Ubuntu's missing, only one is from feisty/main, and that lcms 1.15-1.1+etch3, which was DSA-1684-1 (etch1), DSA-1745-1 (etch2) and DSA-1745-2 (etch3), which were released on Dec 10, 2008, March 20, 2009 and March 25, 2009; well after feisty's end of life in October 2008. The 6 updates it seems like should be a no-brainer for Debian to pull are: clamcour 0.2.2-1.2+feisty2 universe/mail dansguardian 2.8.0.6-antivirus-6.4.4.1-4build1~feisty2 universe/web denyhosts 2.6-1ubuntu0.1 universe/net dircproxy 1.0.5-5ubuntu0.1 universe/net dokuwiki 0.0.20061106-6ubuntu0.1 universe/web jasper 1.701.0-2ubuntu0.7.04 libs The only USN I can find covering these is for jasper, namely USN-501-1. In any event, seems like there's more room for collaboration there at first glance. I've half done the same analysis for lenny/jaunty; but apparently it's time for pizza. Cheers, aj -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Synchronising with Ubuntu
On Tue, Aug 11, 2009 at 07:42:24PM +1000, Anthony Towns wrote: Comparison between etch/main and feisty/main+universe by source: As at today (2009/08/11) etch/feisty security support compare as follows: 63 packages with security updates in both Debian and Ubuntu (11 Hmm, let's try that again. I was missing a few things... Also, comparisons for lenny against intrepid and jaunty (both of which are still supported, though neither are LTS). etch vs feisty == 6874 (55%) same version 132 ( 1%) only in Debian 2273 (18%) only in Ubuntu 195 ( 2%) Debian has newer upstream 405 ( 3%) Debian has newer patches 868 ( 7%) Ubuntu has newer upstream 670 ( 5%) Ubuntu has newer Debian patches 1079 ( 9%) Ubuntu has ubuntuX patches 125 packages with security updates in both Debian and Ubuntu 28 same version 2 Debian has newer upstream 18 Debian has newer patches 37 Ubuntu has newer upstream 15 Ubuntu has newer Debian patches 25 Ubuntu has ubuntuX patches 12 updates in Debian to Debian only packages 15 updates in Ubuntu to Ubuntu only packages 68 updates in Debian to packages with the exact same source in Ubuntu 10 updates in Ubuntu to packages with the exact same source in Debian 87 packages updated in Debian but not Ubuntu 3 Debian has newer upstream 15 Debian has newer patches 33 Ubuntu has newer upstream 21 Ubuntu has newer Debian patches 15 Ubuntu has ubuntuX patches 34 packages updated in Ubuntu but not Debian 1 Debian has newer upstream 10 Debian has newer patches 10 Ubuntu has newer upstream 4 Ubuntu has newer Debian patches 9 Ubuntu has ubuntuX patches Updates in Debian for packages not in Debian: linux-2.6.24 2.6.24-6~etchnhalf.8etch2 devel openssh-blacklist 0.1.1 net Packages Debian should pull advisories for: clamcour 0.2.2-1.2 mail dansguardian 2.8.0.6-antivirus-6.4.4.1-2 web denyhosts 2.6-1 net dircproxy 1.0.5-5 net dokuwiki 0.0.20061106-6 web jasper 1.701.0-2 libs python-clamav 0.3.3-2.1 python sylpheed-claws 1.0.5-5.1 mail xemacs21 21.4.19-2 editors xfsdump 2.2.38-1 admin (NB: denyhosts 2.6-1etch1 and dircproxy 1.0.5-5etch1 were included in 4.0r3, but didn't have a security.d.o upload, afaics. This is effectively considering someone who has a DVD of etch r0 and otherwise only updates from security.d.o) Updates in Ubuntu for packages not in Ubuntu: openssh-blacklist 0.1-1ubuntu0.7.04.1 net openssl-blacklist 0.3.3+0.4-0ubuntu0.7.04.2 net openvpn-blacklist 0.1-0ubuntu0.7.04.1 universe/net pyclamd 0.1.1-0ubuntu1~feisty2 universe/python Packages Ubuntu should pull advisories for: (well, if it weren't already past it's use-by...) lcms 1.15-1 libs[DSA 1684-1, 1745-1, 1745-2] mtr 0.71-2 net [DSA 1587-1] netpbm-free 2:10.0-11 graphics [DSA 1579-1] afuse 0.1.1-1 universe/utils alsaplayer 0.99.76-9 universe/sound b2evolution 0.9.2-3 universe/web backup-manager 0.7.5-3 universe/admin bochs 2.3-2 universe/misc camlimages 2.20-8 universe/devel centericq 4.21.0-18 universe/net cscope 15.6-2 universe/devel devil 1.6.7-5 universe/libs eggdrop 1.6.18-1 universe/net exiftags 0.98-1 universe/graphics feta 1.4.15 universe/admin flamethrower 0.1.8-1 universe/admin gallery2 2.1.2-2 universe/web gnome-peercast 0.5.4-1.1 universe/gnome hf 0.7.3-4 universe/hamradio hyperestraier 1.4.9-1.1 universe/text imp4 4.1.3-4 universe/web inotify-tools 3.3-1 universe/misc jailer 0.4-9 universe/admin kazehakase 0.4.2-1 universe/web kronolith2 2.1.4-1 universe/web ldapscripts 1.4-2 universe/admin libcdaudio 0.99.12p2-2 universe/libs libdbd-pg-perl 1.49-2 universe/perl libfishsound 0.7.0-2 universe/misc libnss-ldap 251-7.5 universe/net libpam-krb5 2.6-1 universe/net libphp-phpmailer 1.73-2 universe/web libtk-img 1:1.3-15 universe/devel loop-aes-utils 2.12r-15 universe/admin maradns 1.2.12.04-1 universe/net memcached 1.1.12-1 universe/web newsx 1.6-2 universe/news nsd 2.3.6-1 universe/net open-iscsi 2.0.730-1 universe/net openswan 1:2.4.6+dfsg.2-1.1 universe/net otrs2 2.0.4p01-17 universe/web pdns-recursor 3.1.4-1 universe/net peercast 0.1217.toots.20060314-1 universe/sound php-xajax 0.2.4-2 universe/web phpbb2 2.0.21-6 universe/web phppgadmin 4.0.1-3.1 universe/web phpwiki 1.3.12p3-5 universe/web refpolicy 0.0.20061018-5 universe/admin reprepro 1.3.1-1 universe/utils ruby-gnome2 0.15.0-1.1 universe/interpreters ruby1.9 1.9.0+20060609-1 universe/interpreters scponly 4.6-1 universe/utils serendipity 1.0.4-1 universe/web slash 2.2.6-8 universe/web sork-passwd-h3 3.0-2 universe/web splitvt 1.6.5-9 universe/utils streamripper 1.61.27-1 universe/sound strongswan 2.8.0+dfsg-1 universe
Re: Debian decides to adopt time-based release freezes
On Tue, Aug 04, 2009 at 05:44:58PM +0200, Marc Haber wrote: On Thu, Jul 30, 2009 at 11:51:35AM +0200, Raphael Hertzog wrote: Also in many cases, Ubuntu and Debian teams can't fully collaborate because they do not target the same upstream version, freezing at the same time should make it possible to achieve this goal. I still see that Ubuntu gets more benefit from that decision. Also, the release team's stunning silence to questions asked about their decisions makes me wonder. I'm a little bothered by the lack of release team involvement in the discussion, but I wonder if the reason isn't simply that it's probably pretty hard for them to pick a way of responding that won't be misinterpreted to fit folks predisposition to argue that Ubuntu are thieves! or everything's always decided behind closed doors! or similar. I don't know of a solution to that, beyond just accepting you'll be misinterpreted and responding anyway. Maybe a stylised debate would work -- ie, pick a couple of people who can debate civilly, randomly assign positions under consideration, and let them make the best arguments they can for those positions, then see what falls out. Basically, just like school debates, though with more points for substance than rhetoric. I'd find that fascinating to follow/participate in, personally. Alternatively, one of the ideas suggested while I was DPL that I didn't end up getting a chance to try was having regular ask the DPL sessions, where anyone can mail in questions, then every couple of weeks the DPL selects a few of them and gives answers. Kind of along the lines of Google Moderator, perhaps. Maybe something like that could be intriguing, anyway. Cheers, aj -- 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
On Wed, Jul 29, 2009 at 01:09:35PM +, Anthony Towns wrote: For three, what happened to getting the firmware issue resolved early in squeeze's cycle [1]? It's evidently no longer early in squeeze's cycle, so maybe I just somehow missed the decision on that... [1] http://lists.debian.org/debian-vote/2009/05/msg0.html For those who didn't see this post [womble] on Planet Debian already: [womble]http://womble.decadent.org.uk/blog/status-of-firmware-in-debian Status of firmware in Debian A question from AJ reminded me that I haven't said much about the changes to packaging of firmware in Debian, and in particular the separation of non-free firmware from the Linux kernel. Linux kernel packages There is an ongoing process upstream to move firmware blobs from drivers into a firmware/ subdirectory of the source, which is now almost complete. Since most of this firmware is non-free, we remove it from the source tarballs for kernel packages but use it to update the firmware-nonfree source package. We continue to patch some drivers to separate out firmware, and have been submitting our changes upstream. Most of these have been accepted though the DRI drivers matrox, r128 and radeon are notable exceptions. A few months ago I attempted to make a new inventory of the remaining firmware blobs [inventory] outside of the firmware/ subdirectory. I identified three that should still be addressed. The Linux-libre [libre] project, however, removes many other constant arrays from the kernel [arrays] (and disables the affected drivers) where I judged the array to be a plausible preferred form of modification. Firmware packages Much of the non-free firmware removed from the kernel is now available in the firmware-linux package in the non-free section of the Debian archive. Starting with Linux 2.6.31, we will build the DFSG-free firmware shipped with Linux into a package called firmware-linux-free, which will be recommended by kernel image packages. The contents of firmware-linux will be moved to firmware-linux-nonfree and firmware-linux becomes a meta-package depending on the other two packages. Many other firmware images [others] never distributed with Linux are also packaged for the benefit of users that require them. [inventory] http://wiki.debian.org/KernelFirmwareLicensing#Inventory [libre] http://linux-libre.fsfla.org/ [arrays]http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/ [others]http://packages.debian.org/source/sid/firmware-nonfree Does that mean we can now pass something along the lines of [reaffirm] for squeeze and expect minimal (or no) effect on the release? If so, that seems like a major cause for celebration, no? [reaffirm] http://www.debian.org/vote/2008/vote_003#texta Cheers, aj -- 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
On Thu, Jul 30, 2009 at 11:49:48AM +0200, Steve Langasek wrote: Doesn't this imply that everyone who continues using Debian today does so merely as an accident of the release schedule and the particular set of packages that land in a given Debian release? That and the fact that upgrades between Debian stable releases are easier (or, at least, more officially supported) than from Debian to Ubuntu. At the moment I could recommend Debian stable over Ubuntu LTS because it has more recent packages (2009/02 release versus 2008/04 release), or because it's an easier upgrade for people with existing Debian systems. With synchronised releases, both those reasons to run stable disappear. OTOH, perhaps you're saying that you think that the proposed sychronization will be successful, and as a result Ubuntu's quality will come up, eliminating a key differentiator between the two at present? I'm not aware of any apples-to-apples comparisons of Debian's and Ubuntu's quality; but personally I haven't seen much evidence that Debian's is significantly superior (NB: I haven't used Ubuntu LTS personally, though). The tradeoffs to me seem to be: Debian stable Ubuntu LTS 2 year rel cycle 2 year rel cycle 3 years security 3 years desktop security, 5 years server guaranteed freeze dateguaranteed release date support for all pkgs support for main, best-effort for universe stabilise from testingupgrade support from previous Ubuntu 6mo release upgrade from oldstableupgrade support from previous Ubuntu LTS (?) support for 6-12 archssupport for 2-3 architectures availability of pre-installed systems full-time security support staff commercial quality support larger userbase some additional packages Having stable and LTS have mostly the same packages makes apples-to-apples quality comparisons easier, which might be good or bad for Debian depending on what the difference is. It'll make cross-grades from Debian to Ubuntu fairly easy, removing most of the lock-in on Debian's behalf; and probably vice-versa. For otherwise unsupported packages in Ubuntu universe, any security problem that Debian notices can be copied straight into Ubuntu due to synced package versions, making best-effort mean at least as good as Debian, so there's no drawback to using packages in universe. So afaics, Ubuntu LTS looks to be the better system to use in all but niche cases (non-x86/amd64 machines). There seems to be an assumption here that Ubuntu would benefit from bugfixes from Debian developers, but that the reverse would not be true. Is this what you believe? Does that mean you don't think Ubuntu developers contribute fixes back to Debian today? Ubuntu has a well-defined and efficient process for accepting changes from Debian (pull from unstable regularly), Debian doesn't have a similarly efficient process for getting contributions from Ubuntu (Ubuntu folks file a bug, maintainer eventually incorporates it), and that'll presumably be made worse if there's a Debian freeze for most of the LTS development cycle. So yeah, I think it's reasonable to expect Debian won't get that many benefits from work on Ubuntu LTS into the corresponding stable release. Testable/refutable claim: my impression is most changes developed for an Ubuntu release don't make it into Debian testing/stable until after that release is out. I'm not particularly bothered by this in and of itself -- if Ubuntu LTS becomes better in every way than Debian stable is now, well great: let's all use that instead! Benefits of free software, etc! But if stable doesn't get used much because LTS releases (or short-term-support Ubuntu releases) are way better, I expect that will have a flow-on effect making testing and unstable less useful/effective, which in turn will make Ubuntu less useful/effective. That doesn't sound like a fun outcome for anyone to me. Cheers, aj -- 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
On Wed, Jul 29, 2009 at 11:25:01AM +0200, Alexander Reichle-Schmehl wrote: Steffen Moeller schrieb: Same here. The release team, or the individual that pressed the button for the announcement, I suggest to apologize for disturbing our community. The text was coordinated within the entire press team, our release masters, the head of the technical commitee and the DPL. IMHO there's no need for an apology. It's remarkable how often people who should be apologising don't think there's cause for an apology. Personally, I would suggest that the press team made the mistake here of making an announcement on behalf of the project of something pretty major that hadn't actually already been discussed on any developer lists. I'm very surprised that neither Bdale nor Steve made that point... On Wed, Jul 29, 2009 at 04:30:07PM +0200, Alexander Reichle-Schmehl wrote: That was meant in a more general way: It seemed to me clear, that such a change would be picked up by the journalists as soon as they get to know. I think you agree on that? Yeah. Journalists do things like that. It's one of the costs of working in public. That's not important; independently of whether there was time for mail to d-d-a or not, it's not the press teams job to keep Developers informed. The press teams job is external communication. Yes, and announcing this as a finished decision before it's even been discussed amongst the developers is very misleading. Cheers, aj, watching master get shutdown as he types -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Voting on messages: a way to resolve the mailing list problems
On Sat, Dec 20, 2008 at 10:35:14AM +, Jurij Smakov wrote: * Vocal minority dominates silent majority by contributing a disproportionate amount of list traffic, [...] Note that voting can have a similar drawback -- in that if you've got enough like-minded people voting for a particular viewpoint (eg, Joe Random sucks, give him what for!) people with a different viewpoint (eg, stop berating people, argh) aren't going to bother voting (the score's already +50, why bother with a -1?). This seems to happen on digg a fair bit. Probably someting to be aware of. Anyway, another idea I was pondering, was having posting credits. Everyone gets, say, five a month, and whenever they make a post, they use one up. _But_, everytime you get a reply to a post you made, critical or complimentary, you get one back. Benefits: - rate limits people, rather than censoring them. got a lot to say? if you can say it in one post a week, rather than a hundred, you're set. if people think you're intersting, it's easy for them to follow what you've got to say, if people think you're boring, it's easy to ignore you - allows discussions to happen (I say something, you reply, I reply to you, you reply to me, etc, and I've spent one credit, and we just keep swapping the other one) - discourages people from feeding the energy beast -- replying to trolls then *technically* enables them to post more not just socially (and likewise prevents you posting on other subjects technically, not just due to the distraction); so unless you've got something you *really* want to add, your best way to shut someone stupid up is just to ignore them (both technically and socially) Optionally: also allow people to give someone else one of their credits without posting a +1. Maybe also limit who can get the five credits a month (eg, DDs, DMs, people recommended by someone with credits), so random anonymous trolls with throwaway accounts have to get vetted first, before posting. Cheers, aj -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19, 2008 at 09:10:25PM +0100, Robert Millan wrote: ,[ The social contract is a goal, not a binding contract ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is an aspirational document: while we aim to achieve as | much of it as feasible at all times, we don't expect to get it | completely right for some time yet. This includes DFSG-freeness of all | firmware ` ,[ The social contract is a non-binding advisory document ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is a statement of principle only, and has no particular | force on the day to day operations of Debian, except in so far as it | influences individual contributors' actions. ` How does this differ from the previous one in practice? The main difference is in direction -- the former indicates that current issues of non-compliance are bugs, that we promise to incrementally fix, but aren't able to immediately. The latter indicates the social contract is more of a vision or mission statement -- something we might individually look to for guidance when making decisions, but not something that's of practical influence. So what's a practical difference? If you file a (valid) bug about some package not-complying with the social contract (but somehow causing no other ill-effects that would also justify the bug report), in the former case the maintainer might reasonably defer it to post-lenny or post-squeeze (perhaps with an -ignore tag in cooperation with the RMs, or perhaps just by leaving a note in the bug log), while in the latter the maintainer might reasonably close it outright, if that's what they thought was appropriate. (In none of the other cases could valid bugs about non-compliance with the social contract reasonably be significantly deferred /or/ closed, where reasonably means in line with the project's expectations. stable releases are one reasonable milestone for significantly deferred, but not the only one, IMO) Cheers, aj signature.asc Description: Digital signature
Re: RFC: General resolution: Clarify the status of the social contract
On Fri Dec 19 21:10, Robert Millan wrote: ,[ The social contract is binding but may be overridden by a simple GR ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract should apply to /almost/ everything Debian does, now | and in the future; _AND_ for the few cases where it should not apply | now, there should be an explicit GR affirming that variation (by simple | majority) ` I don't like the workaround approach to supermajority requirements. If we don't want 3:1, why don't we ammend the Constitution instead? If you don't like an option, preference a different one. That's the way (preferential) voting works. The reason some people might like the workaround option is it makes it clear what the goal is, and requires specific, clear, repeated effort to /not/ meet the goal. They might like that either because you think it'll make people think it's easier to meet the goal than not, or because it puts the focus where we want it (front and centre in the social contract: 100% free), but still makes it clear to everyone what's going on (project wide vote acknowledging we haven't freed some firmware yet, eg). On Fri, Dec 19, 2008 at 08:31:34PM +, Matthew Johnson wrote: I assume any final proposal would explicitly amend the SC/constitution to state this. In fact, I'm tempted to say that _all_ of these should include SC/Constitution amendments to make them explicitly state that position All of those proposals are position statements on issues of the day, they don't purport to modify the social contract or the DFSG or the constitution; they just give the project's understanding of where things are at. As such they only require a simple majority to pass. As far as voting for a position statement along the lines of the social contract doesn't matter, we'll upload Microsoft Word into main, yay!, I believe that would also require a simple majority (1:1) to pass, and would hope that a vast majority of the project would join me in voting against it. If a majority of developers are making position statements out of line with the social contract, I don't think there's much point being part of some honourable minority trying to keep them in check. Cheers, aj signature.asc Description: Digital signature
Re: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19, 2008 at 12:18:01PM -0800, Russ Allbery wrote: I think these have the same flaw as our current situation: none of them state who interprets the Social Contract and the DSFG if there is a dispute over what they mean. If there is a dispute in Debian, there are three levels at which it's dealt with formally: 1) the maintainer asks for advice, and decides 2) the technical committee reviews the technical impact of the decision, and offers advice, adjudicates or overrules (const 6.1(2,3,4)) 3) the developers as a whole decide by general resolution Informally, the DPL (and others) can influence the people responsible at point (1) pretty effectively, and the tech-ctte at point (2). I guess there's some small possibility that there's a relevant impact to a social contract decision that's both completely non-technical and in some way enforcable, but I can't think of one. And there's the GR process as back up then, anyway. Witness the arguments that led up to the editorial changes GR, for example. Up until that social contract amendment GR, the relevant maintainers decided (some maintainers split packages, others didn't, and the ftpmasters accepted packages into main so long as the programs in the package were DFSG-free). It wasn't referred to the tech ctte iirc, and eventually there was a GR. That went fine, with the exception that perhaps people didn't give enough attention to that GR, in the context of the attempts to freeze and release sarge, the just finished don't drop non-free GR, and the 2004 DPL elections. Obviously the result of the GR turned out to be arguably ambiguous in and of itself, though I still don't think I've seen anyone saying that releasing non-free documentation/firmware/etc complies with the current text. It certainly turned out to be a surprising result to many, at least. In any event, at the first stage, my interpretation (as maintainer of the release and I guess to a lesser extent as one of the ftpmasters) was it meant we needed to immediately drop non-free stuff and I posted to -devel to that effect [0], offering all the alternatives I could see. There were lots of responses, and they quickly got heated enough [1,2,3,etc] that I metaphorically threw my hands up in the air to let the other mechanisms operate (and eventually stepped down as RM). The tech-ctte didn't go anywhere [4], the GR process did [5]. [0] http://lists.debian.org/debian-devel/2004/04/msg01929.html [1] http://lists.debian.org/debian-devel/2004/04/msg01959.html [2] http://lists.debian.org/debian-devel/2004/04/msg01996.html [3] http://lists.debian.org/debian-devel/2004/04/msg02664.html [4] http://lists.debian.org/debian-ctte/2004/05/msg4.html [5] http://www.debian.org/vote/2004/vote_004 That seems to me to have been a perfectly adequate way of resolving disputes then, I don't see why a different one would be needed. Otherwise, even if we say the social contract is binding, it doesn't resolve the current problem or future problems like it. Wouldn't it be nice to know if we consider the social contract explicitly binding though? Not everyone did then [6] or does now [7], eg. [6] http://lists.debian.org/debian-devel/2004/04/msg02022.html [7] http://www.earth.li/~noodles/blog/2008/12/debian-king-of-procrastination.html In any event, as far as the current problem is concerned, is there anyone who thinks the current situation complies with the social contract as it stands today? If not, in what doesn't knowing that the social contract is binding (along with what we actually want the social contract to say wrt this) resolve the current problem? Cheers, aj, who personally thinks Debian would already be 100% free stuff in main (docs, fonts, firmware, blobs, etc), if we hadn't distracted outselves by promising it prematurely -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Updated Debian Developers Keyring
On Fri, Apr 18, 2008 at 07:53:15AM +0200, Andreas Tille wrote: On Fri, 18 Apr 2008, Anthony Towns wrote: The following changes to the Debian keyring have been made: May I guess that this good news is somehow connected to [1]? If yes, thanks once more to our former DPL! I don't see any evidence of it: [EMAIL PROTECTED]:~$ ls -l /srv/keyring.debian.org/pub/keyrings/ total 28056 -rw-r--r-- 1 troup root 25393210 Apr 17 19:13 debian-keyring.gpg -rw-r--r-- 1 troup root 949211 Apr 17 19:13 debian-keyring.pgp -rw-r--r-- 1 troup root 4924 Apr 17 19:13 debian-role-keys.gpg -rw-r--r-- 1 troup root 583785 Apr 17 19:13 emeritus-keyring.gpg -rw-r--r-- 1 troup root 104871 Apr 17 19:13 emeritus-keyring.pgp -rw-r--r-- 1 troup root26468 Apr 17 19:13 extra-keys.pgp -rw-r--r-- 1 troup root 1232873 Apr 17 19:13 removed-keys.gpg -rw-r--r-- 1 troup root 366193 Apr 17 19:13 removed-keys.pgp [EMAIL PROTECTED]:~$ groups joerg noodles joerg : Debian webwml nm newmaint qa debadmin planet ftpteam noodles : Debian keyring Over the past few years (2005, 2006 and 2007 at least), there's been a keyring update during the DPL election period; this one's not long after that. It might likewise be correlated with the Ubuntu .04 releases. Cheers, aj signature.asc Description: Digital signature
Re: RFC: Introducing Debian Enhancement Proposals (DEPs)
On Fri, Jan 18, 2008 at 09:12:53AM +0100, Bas Wijnen wrote: If people want to do this, it's useful. The problem that is described is that people don't actually want to do this, because they don't know if their solution will be used. That seems a pretty bad rationale -- implementing your solution (demoing, prototyping, whatever) is a first step in convincing people your idea's good, not something you do after everyone agrees with you. Obviously this doesn't guarantee that the work is used, but it improves chances, which may be enough to just go and do it. Sure, getting a second opinion before starting is useful; but you'd do that before a DEP anyway? bugs.debian.org/ gives us a central index of ways in which Debian should be improving, along with all of: Not the sort of things that DEPs are proposed for IMO. Or at least it isn't used as such. It certainly has been in the past. Reasons to use it again would be: it already exists, it integrates well with lots of other things we do in Debian. Reasons not to use it would be that it doesn't do something that's needed. For example, the machine-parsable copyright thing seems (to me) to be pretty much accepted as a Good Thing, but it's unclear when it would be a good idea to start suggesting or even mandating it in policy. Well, that's an issue with how -policy is working, not an issue with the BTS. Also, I disagree that the BTS is a usable storage place for completed proposals. [...] bugs.debian.org/10 is a much more reliable reference for a closed report than most wikis, or even mailing lists. And IME they are much harder to find when they are, which makes the system less useful as an archive. That's mostly because people tend not to look through old bugs. They're certainly searchable, eg: http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=yes;package=project http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;package=project Right. The BTS is one place where these things can happen. The BTS is a *tracking* system -- it helps you keep track of where a bug fix is up to. If you're wanting to track feature requests (which is what the states and unique id assignment is about), then the BTS is a useful tool. In other cases, other places are used, for example wiki.debian.org, or mailing lists. The proposal is as non-invasive as possible and leaves all these options open. If you leave all options open, you're not doing anything. 2. a document that can be referred to later on without having to dig up and read through large discussions. What's the benefit of this, as distinct from maintained documentation that's distributed with the feature? Are you suggesting that each new feature must be implemented by one person (or a small team with lots of communication), and they can then present the idea including a full implementation with documentation? Huh? I've no idea where you'd get that from. If you have documentation that describes what was originally proposed, but not what was implemented, let alone changes that've been made since, what's so great about it? For example, if a proposal for changing debconf travel funding was made, what's the great advantage of having the original proposal, when it will have almost certainly changed as soon as it's actually tried, and will have changed further later. Another example. The original proposal (well, one of them) for the current new maintainer process, was http://lists.debian.org/debian-project/1999/10/msg3.html But the current documentation for the n-m process is http://www.debian.org/devel/join/newmaint The original discussions are interesting for historical reasons, but I'm not seeing what the win is in having a document that can be referred to later on without having to dig up and read through large discussions. and at the end, people may forget to write proper documentation about it. Both these problems are solved by the proposal, without forcing much policy on the implementors. It's not writing documentation in the first place that's hard; it's writing it so it's useful for the people who'll use it (not the people who're implementing it), and keeping it up to date as changes are made. In so far as a DEP is about tracking a feature request, the BTS seems the right way to handle it. No, that would be _a_ right way. The whole point of DEPs is to not mandate such a thing. It's instead mandating deps.debian.net for indexing, a new rfc822 format, a bunch of manually managed states, posts to lists to manually claim a number, all of which we already have a tool for? * this period must be long enough that there is a consensus that the enhancement works (on the basis of implementation evaluation) Adding delays seems to contradict the previous notes about DEPs not changing who gets to make decisions -- if it takes five minutes for the maintainer of a package to say omg, what a great idea,
Re: RFC: Introducing Debian Enhancement Proposals (DEPs)
On Fri, Jan 18, 2008 at 12:15:33PM +0100, Bas Wijnen wrote: For example, the machine-parsable copyright thing seems (to me) to be pretty much accepted as a Good Thing, but it's unclear when it would be a good idea to start suggesting or even mandating it in policy. Well, that's an issue with how -policy is working, No, it isn't. Changes in policy shouldn't be made unless there is consensus that it's a good idea. Yes, and you get that consensus by proposing a change and addressing any problems people raise with it. You propose the change by filing a bug report against the debian-policy package. That's mostly because people tend not to look through old bugs. They're certainly searchable, eg: I know, but it doesn't look nice. So this all sounds like changing things for the sake of changing things, rather than actually solving any problems to me. Count me as not interested. Cheers, aj signature.asc Description: Digital signature
Re: Using the BTS instead of a different system? (Was: RFC: Introducing Debian Enhancement Proposals (DEPs))
On Fri, Jan 18, 2008 at 01:16:29PM -0500, Joey Hess wrote: If we called this field a summary, one interface to use it could be to mail [EMAIL PROTECTED] to set a new summary. This would add the message to the detailed bug log, [...] That more or less means having a particular message in the bug log be the summary, so adding: Summary-Mail: 6 to db-h/nn/nn.summary, a -summary alias that updates the Summary-Mail field to that mail's number, and probably a summary bug msg control command as well. Presumably Summary-Mail: should either default to unset (there is no summary), or the initial bug report. Not sure what the display should look like. It could be just a link to the particular message, or it could be the entire summary message separated by hr's or similar, or it could be the first paragraph or n lines of the summary message. would be available, and the newest summary would be displayed at the top of the bug report. It would probably also be useful to have a way to get a bug report's newest summary out of the bts and into $EDITOR so minor modifications can easily be made and sent back to the bts. In that case it'd probably be good for the summary messages themselves to be considered boring. Cheers, aj signature.asc Description: Digital signature
Re: Update #1 [RFC: Introducing Debian Enhancement Proposals (DEPs)]
On Thu, Jan 17, 2008 at 09:55:19AM +0100, Raphael Hertzog wrote: On Thu, 17 Jan 2008, Stefano Zacchiroli wrote: Why can't we manage the DEP list just like the rest in a VCS ? A VCS commit is atomic. :) To avoid religious was on which VCS to choose :-) Just use svn for that part. Uh, if you're just trying to get a unique number, why not use the BTS? Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Introducing Debian Enhancement Proposals (DEPs)
On Wed, Jan 16, 2008 at 12:18:30PM +0100, Adeodato Sim?? wrote: Currently, when having discussions about improvements to Debian, it is not always clear when consensus has been reached, and people willing to implement it may start too early, [...] Isn't it useful to have sample implementations before trying to decide whether an idea is good or not? PEPs often seem to have patches for the feature they're suggesting, before they're accepted. Secondly, we lack at the moment a central index in which to list such proposals, which would be useful to see at a glance what open fronts there are at a given moment in Debian, [...] bugs.debian.org/ gives us a central index of ways in which Debian should be improving, along with all of: and who is taking care of them and, additionally, to serve as a storage place for successfully completed proposals, documenting the outcome of the discussion and the details of the implementation. Workflow A Debian enhancement can be pretty much any change to Debian, technical or otherwise. Examples of situations when the DEP process might be or might have been used include: * Introducing new debian/control fields (Homepage, Vcs-*). * Making debian/copyright be machine parseable. * Agreeing upon a meta-package name or virtual package name. These sorts of issues are already tracked with the BTS, for instance when they're dealt with by the tech-ctte or -policy. * Deciding on a procedure for the Debconf team for assigning travel sponsorship money. * Formalizing existing informal processes or procedures, e.g., the procedure for getting a new architecture added to the archive, or getting access to piatti.debian.org to run QA tests. Is it really a good idea to merge this is how we run our distribution and this is how we organise our project ? The result of all this is: 1. an implementation of the enhancement and That's kind of implied by any process that results in changes happening... 2. a document that can be referred to later on without having to dig up and read through large discussions. What's the benefit of this, as distinct from maintained documentation that's distributed with the feature? The actual discussions should happen in the usual forum or forums for the topic of the DEP. [...] In the same way, DEPs do not give any extra powers [...] The person or people who do the suggestion are the drivers of the proposal and have the responsibility of writing the initial draft, and of updating it during the discussions, see below. Proposal states --- The proposal goes through several states over its lifetime. The ideal progression is DRAFT - CANDIDATE - ACCEPTED, but reality requires a couple of other states as well. In so far as a DEP is about tracking a feature request, the BTS seems the right way to handle it. DRAFT: discussion until (rough) consensus * every new proposal starts as a DRAFT * anyone can propose a draft * each draft has a number (next free one from document index) * normal changes happen in this period * drafts should include extra criteria for success (in addition to having obtained rough consensus, see below), that is, for moving to the ACCEPTED state These are all possible with the BTS right now. CANDIDATE: implementation + testing * consensus exists for what should be done, and how it should be done * agreement needs to be expressed by all affected parties, not just the drivers; silence is not agreement, but unanimity is not required, either * implementation can of course start earlier * changes in this period are primarily based on feedback from implementation Tagging the bug confirmed allows this right now. * this period must be long enough that there is a consensus that the enhancement works (on the basis of implementation evaluation) Adding delays seems to contradict the previous notes about DEPs not changing who gets to make decisions -- if it takes five minutes for the maintainer of a package to say omg, what a great idea, why shouldn't it be implemented immediately? ACCEPTED: integrate to policy/devref/elsewhere (if applicable) * consensus exists that the implementation has been a success * also, the final version of the document is archived in a central place (vcs on alioth, plus web page generated from that), even if integrated to other documents as well Tag it patch or close the bug, and this already happens. DROPPED: no further action needed * the drivers are no longer interested in pursuing the DEP * if there are no modifications to a DEP in DRAFT state for six months, or there is a consensus that the implementation of a DEP in CANDIDATE state has been abandoned, the DEP is moved to DROPPED state (from which it can be resurrected by moving to DRAFT stage again) Tag it wontfix or close the bug, and this already happens. OBSOLETE: no longer
Re: Updated Debian Maintainers Keyring
On Sun, Dec 02, 2007 at 08:59:56PM -0800, Russ Allbery wrote: It was closer, but there were stray x89 and x94 strings (as literal strings, not as escapes or hex encodings of characters). Ah, well, that makes some sense. That's what gpg's dumping to me: $ gpg --with-colons --list-key 65B4B162 | hd ... 0040 2d 33 31 3a 3a 3a 2d 3a 41 75 72 c3 a9 6c 69 65 |-31:::-:Aur..lie| 0050 6e 20 47 c3 5c 78 38 39 52 c3 5c 78 39 34 4d 45 |n G.\x89R.\x94ME| 0060 20 3c 61 67 40 72 6f 78 6f 72 2e 63 78 3e 3a 3a | [EMAIL PROTECTED]::| ... except that I'm sending '\x89' to psql instead of '\\x89'. Doing the latter makes my output include the literal text \x89, and makes psql include the same thing. That at least stops it repeatedly reporting the name. And making the script de-escape '\\x89' into the actual chacter '\x89' makes it work properly. Yay! Cheers, aj signature.asc Description: Digital signature
Re: Updated Debian Maintainers Keyring
On Wed, Nov 28, 2007 at 02:57:22AM +0100, Cyril Brulebois wrote: dm:[EMAIL PROTECTED] Full name: Aur?lien G?R?ME (rewritten w/o half-broken encoding, maybe it would be nice to send mails using something different from us-ascii?) Patches welcome. A suggested Content-Type: header might be enough? debian-maintainers (1.6) unstable; urgency=low * Updated Ryan Finnie's key. Closes: #453075 * Added Debian maintainer Manuel Prinz. Closes: #453064 * Added Debian maintainer Simon Josefsson. Closes: #453138 Looks like there were actually no changes here. False positive of some sort? Or python/psql is getting a different value pulled out of psql to the one it thinks it's putting in, and Aurelian's name will be reported as updated with every upload... Cheers, aj signature.asc Description: Digital signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Mon, Nov 26, 2007 at 09:44:50PM +0530, Ramakrishnan Muthukrishnan wrote: As people have already explained, this is not the first mistake people have commited. And at the same time, I agree that it was a grave mistake on my part and I publicly apologize for this mistake. If you care to rectify this by removing my account, by all means do so. Right, and it won't be the last either -- but it seems to me the best approach is to prevent similar bugs from happening again. Unless there's some hidden mass of problems in packages you sponsor (and I imagine it would've become apparent by now if there were), removing your account or upload rights or ability to sponsor wouldn't actually be an improvement. But there has to be *something* that could reasonably have been done to avoid this mistake, that you and other sponsors could just make part of your routine in future so *this* mistake doesn't happen again. I've suggested some ways that might work, but your thoughts on the matter would seem much more useful, both since this was your mistake, and because you're much more actively involved in sponsoring than I am. Cheers, aj, who'd just like to see some failure analysis / air crash investigation type conclusions out of this, rather than just foo sucks and shouldn't upload signature.asc Description: Digital signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Sat, Nov 24, 2007 at 11:22:52PM +0530, Ramakrishnan Muthukrishnan wrote: [I did not recieve the original email addressed to me by aj, so I am literally reading between the lines to digest the original message] It was sent to your @d.o address, and is in the list archives at: http://lists.debian.org/debian-project/2007/11/msg00145.html Ramakrishnan, how did your sponsorship checking miss both this error and the RC bug (442093) the previous upload introduced by the i386 binary's absence? I have tried to catch and feed the lintian and linda errors back to Kartik all the time. I really don't know how I missed it. Well, it was overriden, so unless you'd use lintian with --show-overrides, it wouldn't've shown up. If I remember right, I did an upload of this package only once. You sponsored both the 0.4-1 and 0.4-2 uploads according to the signatures on the .changes files [0]. AFAICS, there were three places where, as sponsor, you could have picked this issue up: - in the 0.4-1 upload, you should have found that the program didn't work at all after being built, ie spotted Bug#442093 prior to uploading; working more closely with Kartik in solving that bug might have avoided including abs_fdisk at all - in the 0.4-2 upload, you should've seen the changelog entry added abs_fdisk binary and wondered why a binary was being added to an arch:all package. Or why it wasn't using fdisk from util-linux. - in the 0.4-2 upload, you might've looked at the debdiff against 0.4-1 and noticed the addition of the debian/lintian.override file containing: linhdd: arch-independent-package-contains-binary-or-object ./usr/bin/abs_fdisk and asked what was going on. Please go ahead with my upload rights removal and also removal from debian keyring, if you judje people by just one of their actions. In this case it's inaction, and it'd be better if you'd acknowledge the problem and do what you can to avoid it in future. From the above, it seems like when sponsoring packages you're not always: - testing to see if they work - reviewing the changelog with an eye for problems - running debdiff to see if anything looks odd - agreeing to sponsor packages only when you've got time to review them That's only my inference from the results though; maybe you are doing some or all of the above normally, and just slipped up this time. Or maybe you have some other technique to catch problems that makes more sense than the above? Removal of your upload rights is one way of avoiding this mistake in future, but there are lots of other sponsors who could make the same mistake, and given you sponsor other things, it has a lot of collateral damage... Cheers, aj [0] [EMAIL PROTECTED]:/srv/ftp.debian.org/queue/done$ gpgv \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ 2007/09/06/linhdd_0.4-1_amd64.changes gpgv: Signature made Thu Sep 6 11:01:25 2007 MDT using DSA key ID 6A9F3C38 gpgv: Good signature from Ramakrishnan M [EMAIL PROTECTED] ... [EMAIL PROTECTED]:/srv/ftp.debian.org/queue/done$ gpgv \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ 2007/09/19/linhdd_0.4-2_amd64.changes gpgv: Signature made Wed Sep 19 10:19:22 2007 MDT using DSA key ID 6A9F3C38 gpgv: Good signature from Ramakrishnan M [EMAIL PROTECTED] ... signature.asc Description: Digital signature
linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
Hi Ramakrishnan, Mohammed, Jaldhar, Kartik, It's been pointed out that Kartik's latest upload of linhdd has included an i386 binary in arch:all package, and explicitly overriden the lintian warning for it (see the mail quoted below). That seems pretty dodgy. Kartik what possible reason did you have for overriding the lintian error report, rather than changing your package to remove the error? Did you ask anyone's advice before doing so? Why are you asking for the removal of linhdd now (Bug#452629), instead of *fixing* the package, eg, by making the package architecture specific instead of arch:all and either the binary built as part of debian/rules, or simply using the fdisk that's already packaged as part of util-linux? Ramakrishnan, how did your sponsorship checking miss both this error and the RC bug (442093) the previous upload introduced by the i386 binary's absence? Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have anything to add here? For the record, Ramakrishnan also seems to have sponsored uploads of the following packages for Kartik that are still present in the archive: of festival, festival-doc, fontypython, speech-tools, tagtool, and uni2ascii. His only other sponsored upload still in the archive is kpsk 1.0.1-3 in sarge for Sebastian Muszynski. Kartik is listed as maintainer of: aspell-gu | Kartik Mistry [EMAIL PROTECTED] ayttm | Kartik Mistry [EMAIL PROTECTED] bake | Kartik Mistry [EMAIL PROTECTED] blast | Kartik Mistry [EMAIL PROTECTED] chmlib | Kartik Mistry [EMAIL PROTECTED] clara | Kartik Mistry [EMAIL PROTECTED] dvdrtools | Kartik Mistry [EMAIL PROTECTED] festival | Kartik Mistry [EMAIL PROTECTED] festival-doc | Kartik Mistry [EMAIL PROTECTED] fontypython| Kartik Mistry [EMAIL PROTECTED] freetalk | Kartik Mistry [EMAIL PROTECTED] gnome-specimen | Kartik Mistry [EMAIL PROTECTED] gtkdiskfree| Kartik Mistry [EMAIL PROTECTED] kphotobymail | Kartik Mistry [EMAIL PROTECTED] ldtp | Kartik Mistry [EMAIL PROTECTED] ldtp-doc | Kartik Mistry [EMAIL PROTECTED] libyahoo2 | Kartik Mistry [EMAIL PROTECTED] linhdd | Kartik Mistry [EMAIL PROTECTED] mpy-svn-stats | Kartik Mistry [EMAIL PROTECTED] pygtkmvc | Kartik Mistry [EMAIL PROTECTED] pyslide| Kartik Mistry [EMAIL PROTECTED] recoll | Kartik Mistry [EMAIL PROTECTED] scanmem| Kartik Mistry [EMAIL PROTECTED] sitecopy | Kartik Mistry [EMAIL PROTECTED] speech-tools | Kartik Mistry [EMAIL PROTECTED] tagtool| Kartik Mistry [EMAIL PROTECTED] tepache| Kartik Mistry [EMAIL PROTECTED] uni2ascii | Kartik Mistry [EMAIL PROTECTED] xchm | Kartik Mistry [EMAIL PROTECTED] xmms-crossfade | Kartik Mistry [EMAIL PROTECTED] xmountains | Kartik Mistry [EMAIL PROTECTED] xosview| Kartik Mistry [EMAIL PROTECTED] On Fri, Nov 23, 2007 at 06:49:24PM +, Steve McIntyre wrote: dm:[EMAIL PROTECTED] Full name: Kartik Mistry I don't know if that was such a good idea, see #452464 Wow, the linhdd package is *special*. Based on initial analysis of this package, please remove: * the DM (Kartik Mistry) from the keyring (he clearly needs to learn more before he should be allowed to upload directly) * the upload rights of the sponsor (Ramakrishnan M [EMAIL PROTECTED]) who uploaded this to incoming without any suitable level of checking. This is a *much* more important problem IMHO. * the package itself The package contains an i386 binary (abs_fdisk)in a binary-all package, directly installed from a binary that comes in the upstream source packages. To accompany that, there are the following highlights: * a README.Debian stating linhdd also has binary called 'abs_fdisk' which is used for linhdd working correctly. util-linux is provided for its source. To save archive space, the package is set to Architecture: all. Please do not report this as a bug on the mentioned architectures. * a lintian.override file to suppress errors about it * changed source files that claim to be used in fdisk and abs_fdisk I expect a *much* higher standard of packages in our archive, and I hope I'm not alone here. Cheers, aj signature.asc Description: Digital signature
Re: Updated Debian Maintainers Keyring
On Wed, Nov 21, 2007 at 12:10:41PM +0100, Pierre Habouzit wrote: Here is the current list. When psql on merkel gets updated to a version that can load the dumps from ftp-master, you can get a more accurate view of who can upload what by ssh'ing to merkel and running: psql projectb EOF SELECT s.source, s.version, u.uid FROM src_uploaders su JOIN source s ON (su.source = s.id) JOIN src_associations sa ON (s.id = sa.source) JOIN maintainer m ON (su.maintainer = m.id) JOIN uid u ON (m.name LIKE u.name || ' %') WHERE u.uid LIKE 'dm:%' AND sa.suite = 5 ORDER BY u.uid, s.source, s.version; EOF The current output for that is: source | version| uid --+--+- apt-transport-debtorrent | 0.1.1| dm:[EMAIL PROTECTED] bittornado | 0.3.18-5 | dm:[EMAIL PROTECTED] debtorrent | 0.1.4.4 | dm:[EMAIL PROTECTED] libphp-adodb | 4.96-1 | dm:[EMAIL PROTECTED] torrentflux | 2.3-6| dm:[EMAIL PROTECTED] a7xpg| 0.11.dfsg1-2 | dm:[EMAIL PROTECTED] gunroar | 0.15.dfsg1-2 | dm:[EMAIL PROTECTED] tumiki-fighters | 0.2.dfsg1-1 | dm:[EMAIL PROTECTED] iso-codes| 1.6-2| dm:[EMAIL PROTECTED] (9 rows) I note that the 4th package made an interesting choice indeed. The Dm-Upload-Allowed: field is only relevant for DM when there're non-DD uploaders listed. It's relevant for dak in that only packages with that field set get their uploaders put into the database where they can be referred to later. Cheers, aj signature.asc Description: Digital signature
Re: Updated Debian Maintainers Keyring
On Thu, Nov 22, 2007 at 06:10:42PM +1000, Anthony Towns wrote: On Wed, Nov 21, 2007 at 12:10:41PM +0100, Pierre Habouzit wrote: Here is the current list. When psql on merkel gets updated to a version that can load the dumps from ftp-master, you can get a more accurate view of who can upload what by ssh'ing to merkel and running: ...or I could script it and you could just look at an automatically updated web page like: http://ftp-master.debian.org/dm-uploaders.txt Cheers, aj signature.asc Description: Digital signature
Re: Updated Debian Maintainers Keyring
On Thu, Nov 22, 2007 at 03:13:52PM +, Stephen Gran wrote: This one time, at band camp, Anthony Towns said: When psql on merkel gets updated to a version that can load the dumps from ftp-master [...] Can we just open the postgres port on ftp-master to merkel, and grant read only access (over ssl if it makes people feel better)?. I think that'd require code changes to dak. It probably also means the dak install on merkel wouldn't be an exact mirror of the one on ries, which would be a nuisance as far as keeping it an exact mirror of the live install is concerned. Also, restoring the dump to merkel has the advantage that we know our backups can actually be restored. Anyway, updating merkel to etch looks set to happen fairly soon anyway. Cheers, aj signature.asc Description: Digital signature
Re: NM process, AMs, advocates, mentors and applicants
On Tue, Nov 20, 2007 at 02:51:42PM -0800, Russ Allbery wrote: Hm, it didn't seem like a mentor role to me. Being a mentor involves telling the mentee how to solve a problem and helping them work through the learning process. I would've said it involves helping them work through the process repeatedly, until they don't need any help; possibly introducing new difficulties at each cycle. A good mentor ought to be able to tell when the mentee's reached the point that they no longer need any help. I'd consider the release assistant stuff to follow that sort of structure, personally; it definitely has an educational component as well as practical work, and it also has the mentors evaluating the progress and deciding at some point that they've reached the point where they can do the work on their own. It felt more like a practical examination to me than a mentor relationship. Which is fine too, of course; but it's the sort of thing that works well for people who're already competent and confident in their abilities, and really badly for people who're nervous or just don't know where to start. Of course, if someone is already skilled, then it's better to just have them demonstrate that than try to teach them things they already know, in which case worrying too much about mentoring is a bad idea. Cheers, aj signature.asc Description: Digital signature
test mail from ajt@ via d...@ftp-master
If this were a real mail, there would be some useful content here. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Updated Debian Maintainers Keyring
Apparently bouncing messages to -project doesn't work so well, so this is a forward of [0] instead. Future messages will be sent direct to -project when an update d-m package is accepted. [0] http://lists.alioth.debian.org/pipermail/d-m-team/2007-November/13.html -- aj With the upload of debian-maintainers version 0.08, the following changes to the keyring have been made: dm:[EMAIL PROTECTED] Full name: Jose Parrella Added key: 7C1081B53C566C78AC7D3A2D51602C8D005C3B82 A summary of all the changes in this upload follows. Debian distribution maintenance software, on behalf of, Joey Hess [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 16 Nov 2007 22:05:57 -0500 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 0.08 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Changes: debian-maintainers (0.08) unstable; urgency=low . [ Joey Hess ] * Add James Troup, Michael Beattie, Ryan Murray, Joerg Jaspert, Brian Nelson, Marc Brockschmidt, and Christoph Berg to the admins keyring. Per the GR, they all have commit access already, so it seems they might as well be able to easily jetring-accept changes too. * Add Anibal Monsalve Salazar to the admins keyring. Anibal is the newest member of the DM team. * Use pgp-clean from signing-party to strip signatures from the admins keyring, saving a couple megabytes from the source package. * Update docs, manual announcements are no longer needed since aj automated them at package accept time. . [ Anibal Monsalve Salazar ] * Added added myself to the uploaders list. * Added Homepage line in debian/control. * Added Debian maintainer Jose Parrella. Files: 7e140d55433bc453b78cbc5da7ddb311 846 misc extra debian-maintainers_0.08.dsc f1360e1e31d55d04c52939716eeb8337 185505 misc extra debian-maintainers_0.08.tar.gz 8bccafce4e6a5912a4eff26ccb8a3b63 32930 misc extra debian-maintainers_0.08_all.deb 71e49a5a21da0537542a801fcbfcf04f 41984 raw-keyring - debian-maintainers_0.08_all.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPlvz2tp5zXiKP0wRAtjTAJ9IGLVtXNCnmkIB57AJL7u9Jeb+SACfTvfv QGj6W0De7dAUaVNR0mShOr4= =AaGu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers
On Fri, Oct 26, 2007 at 09:55:57AM +0200, Bart Martens wrote: I'm sure that the intentions are good, but Joerg has a point about these three DM's. Maybe it is better to replace these three DM registrations in the DM keyring by three artificial DM's owned by DD's. For the record, the code for this was tested first by limiting my own key to only have DM rights for some months. The limitations inherent in separating keys/rights for DMs include: - not having the same key being a DD and DM - not having a DD and DM with the same name - having the DM's name from the gpg key be included in the Uploaders: field I don't think having dummy uploads introducing made up names into Uploaders fields is a great idea, and limiting testing to DDs means you don't get reports of things that are obvious to DDs but aren't for people who've never uploaded before. Then nobody can complain about real DM's already being added without following the rules. Joerg's already made other complaints of that form: 19:25 Ganneff aj: wasnt there a dont accept your own package? 19:27 Ganneff (i know, i violated that myself already). 19:28 Ganneff gpg --list-keys in build without gnupghome. as buildd maintainer i would file rc bugs. 19:31 aj good thing arch:all packages aren't build on buildds then? ffs I don't think any solution short of revert the GR entirely would stop those complaints -- and in turn is why they're correlated with the original votes. Cheers, aj signature.asc Description: Digital signature
Re: Debian Maintainers
On Fri, Oct 26, 2007 at 12:45:54AM +0200, Stefano Zacchiroli wrote: On Thu, Oct 25, 2007 at 10:44:29PM +0200, Joerg Jaspert wrote: Please follow your own rules. Thanks. Besides, and with a sharp different tone, if Debian Maintainers are a reality now ... It's not yet; remaining holdups are: - only one non-DD beta-tester to shake out bugs; I'd prefer two before announcing or having any uploads I'm not willing to personally take responsibility for - debian-maintainer keyring uploads aren't processed automatically, mean that, in effect, only ftpmaster is able to change the keyring I've been more low-key (and hesitant) about implementing this than I would've liked to have been in order to try to avoid offending the people who're worried about this, but I should probably have expected those to find fault with this no matter what happens anyway. For amusement's sake, correlating GR votes with respondents in this thread up until now: V: 1-js Jonas Smedegaard V: 12 don Don Armstrong V: 12 zack Stefano Zacchiroli V: 12 joeyh Joey Hess V: 12killer Kalle Kivimaa V: 12 hertzog Raphael Hertzog V: 21he Marc Brockschmidt V: 21 faw Felipe van de Wiel V: -1 acid Julien Danjou V: -1 bartm Bart Martens V: 21 joerg Joerg Jaspert V: 21schizo Clint Adams V: -1 madcoder Pierre Habouzit Point is, right now nobody knows DM can be used practically. To be clear, it can't. It's in final beta-testing. Developers who are interested can monitor it by examining the projectb database (on ries if you have access, or on merkel otherwise), eg: Packages with Dm-Upload-Allowed: yes and corresponding allowed uploaders: SELECT S.source, S.version, M.name FROM src_uploaders U JOIN source S ON (U.source = S.id) JOIN maintainer M ON (U.maintainer = M.id); source | version|name --+--+ debtorrent | 0.1.4.4 | Cameron Dale [EMAIL PROTECTED] a7xpg| 0.11.dfsg1-2 | Miriam Ruiz [EMAIL PROTECTED] gunroar | 0.15.dfsg1-2 | Miriam Ruiz [EMAIL PROTECTED] tumiki-fighters | 0.2.dfsg1-1 | Miriam Ruiz [EMAIL PROTECTED] apt-transport-debtorrent | 0.1.1| Cameron Dale [EMAIL PROTECTED] torrentflux | 2.3-5| Cameron Dale [EMAIL PROTECTED] Recognised DM uploaders: SELECT U.uid, U.name, F.fingerprint FROM uid U JOIN fingerprint F ON (F.uid = U.id) WHERE U.uid like 'dm:%'; uid | name | fingerprint -+--+ dm:[EMAIL PROTECTED] | Fathi Boudra | CEE06509A9D42D28D2573EA88CF535F6... dm:[EMAIL PROTECTED] | Miriam Ruiz | AA46F4F2BD5975A4EE4282237DB96D2E... dm:[EMAIL PROTECTED] | Cameron Dale | FF0784FEE439DA85CAF1EA950F1F76E2... (fingerprints trimmed by hand at 80 characters) Sources currently in the archive uploaded by DMs: SELECT S.source, S.version, S.install_date, U.uid FROM source S JOIN fingerprint F ON (S.sig_fpr = F.id) JOIN uid U ON (F.uid = U.id) WHERE U.uid like 'dm:%'; source| version | install_date | uid -+-++--- torrentflux | 2.3-5 | 2007-10-23 00:00:00+00 | dm:[EMAIL PROTECTED] torrentflux | 2.3-4 | 2007-10-21 00:00:00+00 | dm:[EMAIL PROTECTED] debtorrent | 0.1.4.4 | 2007-10-19 00:00:00+00 | dm:[EMAIL PROTECTED] Those queries should continue to work once the system's out of beta. Cheers, aj signature.asc Description: Digital signature
Re: Multi-winner elections, soc-ctte (Was: Re: soc-ctte discussion at DebConf7)
On Sat, Jun 30, 2007 at 10:00:47AM +0300, Antti-Juhani Kaijanaho wrote: On Fri, Jun 29, 2007 at 02:43:24PM -0500, Manoj Srivastava wrote: It should be relatively straight forward for Devotee to find the winner, take the winner out of contention the next round, find the next winner (ignoring any pairwise contests dealing with any candidate no longer in the contest), and continue until the number of candidates desired has been reached. This is no doubt true. As I mentioned in another mail, this procedure does have the problem of not delivering proprtional results. A scenario. A simpler scenario. A bunch of candidates divide themselves into essentially two parties, people focussed on free software, and people focussed on our users. As it turns out, one group has 60% support within the project, the other group has 40% support within the project. There are six candidates, and three places to fill. Votes go along the lines of: 60% [ 1 ] A-1 [ 2 ] A-2 [ 3 ] A-3 [ 4 ] B-1 [ 5 ] B-2 [ 6 ] B-3 40% [ 4 ] A-1 [ 5 ] A-2 [ 6 ] A-3 [ 1 ] B-1 [ 2 ] B-2 [ 3 ] B-3 Condorcet gives the winner as A-1. Excluding A-1 gives you a Condorcet winner of A-2. Excluding A-1 and A-2 gives you a Condorcet winner of A-3. A more desirable outcome, IMO, would have given B-1 a seat in the above circumstances. Which is what proportionality is all about... Whether A is free software and B is our users or vice-versa is left as an exercise for the reader. ;) Other plausible scenarios might involve soc-ctte candidates promoting freedom of speech versus improving signal:noise. Cheers, aj signature.asc Description: Digital signature
Re: message from Sven Luther
On Fri, Jun 29, 2007 at 03:51:32PM +0200, Robert Millan wrote: I don't personaly think being publicly discredited by our mistakes is something we want as a community. Being publicly discreditted for our mistakes seems like exactly the right thing to happen to me, actually. Helps discourage us from making mistakes in future, helps other people avoid making the same mistakes, helps people understand how Debian works. That's why we have a publically available BTS, do our development in public, try to avoid using private lists, etc, after all... Cheers, aj signature.asc Description: Digital signature
Re: Micros*ft deal
On Mon, Jun 25, 2007 at 03:57:39PM +0200, Alexander Schmehl wrote: I would to see some kind of statement, too. How about To the best of our knowledge, Debian is free of patent encumberance. We will, however, happily accept patent indeminfications for our users, upstream developers, and derived distributions; and will be happy to offer any company that offers such an indemnification any number of copies of Debian to provide to their customers that they may desire. ? :) Cheers, aj signature.asc Description: Digital signature
Re: Debian Trademarks Summary
On Sat, Jun 23, 2007 at 12:48:26AM +0100, MJ Ray wrote: http://people.debian.org/~mjr/legal/trademarks.html ] Just to be clear, the two debian logos are currently under the restrictive ] copyright licences described on http://www.debian.org/logos/ (set by ] votes in 1999) and not currently suitable for inclusion in the debian ] operating system, but the project is currently in the process of changing ] this. I expect an announcement from SPI soon. That's no longer the case; both logos are now available under the MIT license, however a public announcement hasn't been made pending some details. ] Personally, I'm not surprised that there was not much progress on ] our trademark during 2006-2007, with a Debian Project Leader who writes ] utter rubbish like The DFSG [...] doesn't cover patents or trademarks ] but maybe we can get moving again now, and make debian more fun by ] fixing this mess at long last, instead of it being thrown up over our ] shoes each time we complain about someone else using trademarks to ] obstruct free software. Yes, clearly no progress was made, and certainly all the progress that wasn't made was in spite of anything I might have done. http://lists.debian.org/debian-project/2007/02/msg00019.html * there's a draft trademark license that we've been waiting for the project to do something with it for many months (mentioned on-list Sep 2005 and on planet May 2006 AFAICT), so please don't blame -legal or SPI for our delays. It's likewise nice to see we're back to -legal not being a mailing list, but an unconstituted advisory body that manages to be a responsible body, somehow. Yeesh. Cheers, aj signature.asc Description: Digital signature
Re: Debian release cycle for enterprise ?
On Fri, Jun 08, 2007 at 09:41:09AM +0200, Fr??d??ric PICA wrote: This the follow up of the same thread in debian-release : http://lists.debian.org/debian-release/2007/06/msg00039.html In that thread, Martin Krafft wrote: ] To support a release for 4-5 years, we would need substantially more ] resources: people who backport security fixes and maintain the ] archive, mirror operators who don't mind additional gigabytes, ] package maintainers who don't mind cooperating on old packages, and ] upstreams who are equally cooperative. There's a lot of value to being able to update regularly and take advantage of new developments, whether you do that at a twice-daily interval (testing, unstable), three monthly interval (ubuntu), which is an important consideration in regards to regular releases and minimising freeze times and so forth. I'm going to ignore it completely for the rest of this mail though. One thing I think's interesting is comparing the lifetime of systems like Windows 98 or Windows XP to Debian -- ie, considering people still running hamm today, or still doing installs of potato or woody, and what it would take to support that sort of usage. I think there's probably a few factors to take into acocunt here: i = initial time to review the upgrade and be confident it will work d = planning and downtime to actually do an upgrade l = preferred lifetime of installations For i, it's probably fair to say that major Windows upgrade tend to have a longer burn in period due to people preferring to wait for bugs to be worked out and service packs to be released before considering major upgrades. For Debian, most of the bugs are worked out before the stable release (or at least, most of the bugs that are going to be fixed anyway), and it's easy to get experience with the new OS while it's in development. Likewise d is reduced for Debian systems because it is fairly easy to do an upgrade -- some configuration may need to be retested and updated, and some packages may need to be replaced instead of upgraded, but that work is relatively minor compared to reinstalling and reconfiguring a system from scratch. For l, in Windows circles it's traditional to take that as the lifetime of the hardware, so three-to-five years; though in Debian circles you might often expect an installation to last through multiple changes of hardware, and thus be able to consider it independently. It's probably worth considering a variation of that, l' = preferred availability for new installations so that if l'=2 and l=3, you know you have a two year period when you don't need to worry about installing anything but XP, and you also know you're not going to be forced to upgrade any of those computers for three years -- which means two (l') years of commercial availability, and five (l+l') years of security support. If we define s = desired length of security support r = release cycle length and we calculate: t_release = date release is released a_release = date release is available to be installed e_release = date release ceases having security support as t_lenny = t_etch + r a_etch = t_etch + i e_etch = t_etch + s a_lenny = a_etch + l' t_lenny = t_etch + l' r = l' e_etch = a_etch + l' + l = t_etch + i + l' + l = t_lenny - (t_lenny - t_etch) + i + l' + l = t_lenny - r + i + l' + l = t_lenny + i + l + (l' - r) e_etch - t_lenny = i + l + (l' - r) So oldstable security support (how long we do etch security support after lenny is released) needs to last for at least i+l (since l' = r), and i+l+l'-r if you're not synchronising your upgrade cycle with Debian's release cycle (ie, l' r). At the moment that's one year, so we can work backwards and estimate for Debian users, l'=r = 1.5 years (minimising l'-r) i+l = 1 year (oldstable security support) So the usable lifetime of a release (l'+l) is 2.5y-i, and the maximum amount of time you can guarantee a Debian release is usable is 1y (if you're required to install the day before a stable release comes out, you'll need to do an upgrade within a year). If we want to choose l', l and i rather than calculate them, then sample figures like: l' = 1y6m ; i = 0y (always install the newest release) l = 3y (only do new installs on new hardware) might be appropriate, in which case you get: e_etch - t_lenny = i+l = 3y ie, you would need oldstable support to last three times as long as it currently does. Alternately, you might consider: l' = 3y ; l = 0 ; i = 0 (have a 3 year cycle of upgrades, where every machine gets upgraded, including ones that were just installed yesterday; all machines run the same
Re: Social committee proposal
On Sun, Jun 03, 2007 at 10:56:32PM +0100, Mark Brown wrote: On Fri, Jun 01, 2007 at 10:30:24PM +0200, Josip Rodin wrote: Also, I can already see opposition to a committee which is only elected once, and can then change its own membership at will, while retaining all of its the powers that the originally elected members were given. That simply sounds evil. It does mirror the arrangements for the TC. Is that meant to be a good thing? :) Cheers, aj signature.asc Description: Digital signature
Re: Debian Maintainers oup
On Thu, May 31, 2007 at 03:15:06PM +0200, cobaco (aka Bart Cornelis) wrote: - do we really need to make this more complicated than: 1) sponsor officially declares this person can in his opion handle the sponsored package? 2) sponsoree gets upload rights for that package We need some way to identify this person -- ie, a gpg key that's verified by a DD in some way. We probably want some assurance that this person's going to be trustworthy and honourable and support Debian's goals, like affirming the social contract and such. Cheers, aj signature.asc Description: Digital signature
Re: Jury (was Re: Two GR concepts for dicussion)
On Thu, May 31, 2007 at 11:30:28PM -0400, Philippe Cloutier wrote: Hey, why not? A third idea: instead of having delegates or a committee or whatever to decide amongst disputes, how about randomly selecting a jury from DDs and having their word (on who's right, on what punishment is plausible) be absolutely final, with no appeal, ever? I don't like it at first read, but you may provide examples of situations where such a procedure could be useful. In particular, just determining who's right doesn't help much. As for determining what punishments are plausible, isn't this better done by a committee specialized in the Constitution? Randomly selected juries avoid the cabal problem -- it's transparent who gets involved, it's not limited to some people, it's not the same people all the time, and it's a bit easier to deal with (perceived/claimed/whatever) conflicts of interest. I dunno, it's just something I've been wondering about for a little while now. Cheers, aj signature.asc Description: Digital signature
Two GR concepts for dicussion
Hey all, As a slight distraction from other discussions going on, I'd like to throw a couple of ideas out there for consideration, particularly with debconf coming up and a chance for many of us to discuss things in person. First, the Debian Maintainers concept, ie giving limited upload access to people prior to, or instead of, them becoming developers. For this to be useful, the process should be lightweight, but still provide a good means of ensuring we (and our users) can maintain our trust in the packages that get uploaded. I think the process should involve: - automated application process - as close as feasible to automated keyring maintenance - policies developed by consensus and implemented individually by developers, in a similar manner to policies for sponsored uploads at present, rather than an individual or group setting policy or approving applications (like DAM or NEW processing) - minimal requirements: gpg keyring signed by either one or two developers, recommendation by a developer, use of existing fields such as Maintainer: and Uploaders: to control access, no provision for uploaders to do NMUs or upload NEW packages etc Both Joerg (DAM) and James (DAM, DSA, ftpmaster, keyring-maint) objected to me pushing ahead with this a couple of months ago [0], and not much was achieved after it was discussed at debconf last year either, ttbomk. My best summary of Joerg's objections are: - having me be pushy about it, particularly in the lead up to a DPL election in which I'm a candidate, doesn't work - there isn't a sufficiently concrete plan - it's taking over some of the DAM role (in principle if not precisely in practice) so should be done with DAM's approval and support - there should be a general consideration of other DD priveleges (voting, machine access, @debian.org addresses) and having more granular control of those too Personally, I'd rather leave a general consideration of other priveleges until after we've tried generalising uploads and seeing how (if) that works, which makes me pretty reluctant to worry about the last point; and I'd like to think that you don't need to have a DAM hat (or approval) to work on improving this area of Debian, so while I certainly respect Joerg's opinion (which is why I'm trying to paraphrase and reply to it!), I'd rather that only be due to his experience and insight wrt helping newbies join Debian satisfactorily, than his current position in the project. James hasn't made his particular objections clear, apart from that it should go through keyring-maint. The thread following [0] includes various criticisms and responses too. So, the reason I call it a GR concept is that I think a reasonable approach would be to work out a concrete plan over the next few weeks, and hopefully come up with something that has a demonstrable consensus behind it, rather than just a pushy DPL candidate, a couple of cabal members, or whatever. Whatever happens, it won't be perfect, but surely we can think of and implement *something* better than what we've currently got within a few weeks. [0] http://lists.debian.org/debian-project/2007/03/msg00074.html Another thought. Sam's written about having more people in our core teams a few times, and no doubt will have more to say in the future; but a single person can only focus on helping one or two teams at any one time, and there's no limit to the number of teams that can have problems. Maybe it's worth thinking about a more general solution than DPL intervention for helping teams that have calcified to grow and improve. My idea was to have an annual round where any DD could nominate themselves to join any team -- DSA, ftpmaster, maintenance of some particular package, www team, whatever. Acceptance would be automatic, provided: * no more than three people are joining the team (if so, the existing team can select three, or the DPL can if the existing team don't) * the role isn't core, or the person isn't already involved in two or more other core roles (eg, ftpmaster assistant isn't core, ftpmaster is; release assistant isn't, release manager is) * the person can demonstrate some minimal existing competence in the area * the person is willing to agree in writing to make every reasonable effort to work with the existing team (which the DPL will enumerate on request) (That's intended to be in *addition* to the existing members of a team finding people to join in and help, not instead of it.) That has two major prerequisites in order to work: that we're *all* willing to give up some of the control we're used to exercising over our domain within Debian (whether that be a package or some infrastructure or a role or whatever); and that we
Re: Proposed name change for DWN
On Wed, May 02, 2007 at 11:56:02AM -0300, Felipe Augusto van de Wiel (faw) wrote: Hopefully, I think we can start having DWN weekly again, so let's try. :-) The DWN contribution howto is at: http://www.debian.org/News/weekly/contributing The most relevant points are probably: Right after an issue of DWN is released, Joey will start with an empty new issue. The issue is online at Joey's private website which is available using anonymous CVS as well. Check it out using cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/infodrom.org \ co -d dwn public_html/src/Writing/DWN (empty password for cvs login) and Anybody, who would like to add an item to DWN or who has an issue that should be mentioned in the next DWN, should contact us* at any time with enough information. * mailto:[EMAIL PROTECTED] Cheers, aj signature.asc Description: Digital signature
Re: When Debian 4.1 will arrive... will anyone care?
On Wed, Apr 11, 2007 at 10:34:47AM +0900, Charles Plessy wrote: I propose another idea: having a major.minor release scheme in which we guarantee the upgrade path from major.x to major+1.0, and from one minor release to the other. One big obstacle common to all these directions is to find a security strategy which would not drain all the workforce of the Project. Isn't that essentially the same idea as http://kitenet.net/~joey/code/debian/cut/ with a mapping between major.x and cut x ? (I think it is the same thing in effect, and I'm really hoping we can make that happen; somewhat interested in discussing any differences though) Cheers, aj signature.asc Description: Digital signature
Re: Google SoC - Bug Triaging and Forwarding Tool
On Mon, Mar 19, 2007 at 09:12:40AM -0300, Gustavo R. Montesino wrote: 1. Query BTS according to paramaters given by the user. It could filter the bugs by maintaner, uploader, package, usertags, tags, etc. Display a list with bug number, title and tags to the user. 2. The user may select one of the bugs. The user would be then able to do the following on the selected report: * See the full bug report, followups, etc * Follow-up to the bug (launch the mail client with the right headers) reportbug-ng already does something like this. Have you looked at that program? * Change the bug tags (generate and send a control mail with the choices made by the user) * Search the upstream BTS for similar bugs [...] Philip Kern worked on this for last year's SoC, but I'm not sure if the code actually ended up working and I can't remember where it was now. :-/ The best I can find is some mock-up screenshots at: http://lists.alioth.debian.org/pipermail/soc-coordination/2006-August/58.html Personally, I find triaging mostly involves grouping rather than followup -- ie, the process is look at all the bugs, group related ones together into a bloc (by what area of the code they impact, how important they are, whether there's anything that can be done about them yet, etc), and then choose a group and do detailed followup/resolution on those bugs. Would it make sense to focus on the tagging aspect (either with the standard tags or usertags) so that your program just makes it really easy to set tags so maintainers can get a good idea of the state of their package (and share that idea through the use of tags), and fire off reportbug or a web browser for following up or reading bug logs? Cheers, aj signature.asc Description: Digital signature
SPI resolution formalising Debian as an SPI associated project
Hey all, At their meeting today, SPI passed [0] a motion formalising Debian's relationship with SPI. AIUI, the text of the motion is as per: http://lists.spi-inc.org/pipermail/spi-general/2007-March/002245.html Cheers, aj [0] The votes were four in favour (Ian Jackson, Michael Schultheiss, Jimmy Kaplowitz, Neil McGovern) with the two non-DDs on the board abstaining (David Graham and Josh Berkus), and Bdale Garbee, Branden Robinson, and Joey Schulze not present. signature.asc Description: Digital signature
Re: Developers vs Uploaders
On Thu, Mar 15, 2007 at 02:47:22PM +0100, Pierre Habouzit wrote: Well at first it is. One of my main sponsoree is Fathi[0]. I sponsor him for quite a long time now, I'd say a year at least. The beginning of our relationship was indeed really a teacher/student one. [...] But for now something like 6 months, I've nothing to say wrt his packages. I merely do cosmetics remarks, he knows his stuff. [...] At least, with the DM proposal, he would not depend upon me anymore, except for the introduction of NEW packages. That would allow me to take new sponsoree, that would need the teaching part I quite like to do, and that Fathi no longer needs for months. That sounds like a recommendation... From what I can see [0], in the past six months you've sponsored about 83 uploads for (afaict): Aurelien Gerome Jeremie Corbier Cyril Brulebois Jeremy Bobbio Emmanuel Bouthenot Julien Louis Fathi BoudraKhalid El Fathi Gregory Colpart Ludovic RESLINGER of which about 52 were for Fathi. To me, that sounds like it meets the requirement of sponsored 30 uploads in the last six months that I suggested for being able to recommend a DM originally [1]. It seems sensible to me to have the recommendation take the form of a file that we can just dump directly into jetring. I was thinking something like this (for holger) looked sensible: ---cut-- Changed-By: Anthony Towns [EMAIL PROTECTED] Comment: adding holger as debian-maintainer Date: Mon, 26 Feb 2007 18:25:59 +1000 Advocates: ajt - http://lists.debian.org/debian-newmaint/2007/01/msg00037.html kaol - http://lists.debian.org/debian-newmaint/2007/01/msg00038.html zobel - http://lists.debian.org/debian-newmaint/2007/01/msg00043.html tolimar - http://lists.debian.org/debian-newmaint/2007/01/msg00044.html sgran - http://lists.debian.org/debian-newmaint/2007/01/msg00044.html 93sam - http://lists.debian.org/debian-newmaint/2007/01/msg00047.html neilm - http://lists.debian.org/debian-newmaint/2007/01/msg00048.html damog - http://lists.debian.org/debian-newmaint/2007/01/msg00050.html KeyCheck: [output of keycheck.sh] NM-Page: https://nm.debian.org/nmstatus.php?email=debian%40layer-acht.org Action: import Data: [ascii armoured key to be imported] ---cut--- The required fields are Changed-By, Comment, Date, Action and Data; the others are just useful extra information for people who're trying to find out about the maintainer. The advocacy there is probably well above what should be necessary (it was an AM report, after all), but some brief comments on what they're like from various DDs who've worked with them is still probably worthwhile. Some brief comments to the effect that they'll follow the social contract and Debian policies, and that they understand how to keep their key secure might be worthwhile too. I guess Fathi's worked closely with Daniel Glassey (clucene-core), Gustavo Franco (desktop-base) and Mark Purcell (KDE extras) so some of them might have nice things to say about him that might be worth including. If any of the KDE team or Enrico (as his AM) have any comments, likewise. Anyway, what do you think about having a go at creating a jetring stanza something like the above for Fathi? Cheers, aj [0] cd queue/done touch -d '6 months ago' ~/date find -maxdepth 1 -newer ~/date | xargs grep -l 'Arch.*source' | while read a; do gpgv $a 21 | grep -q A1EE761C (grep -q Pierre Habouzit $a || echo $a); done [1] http://lists.debian.org/debian-project/2007/03/msg00074.html signature.asc Description: Digital signature
Developers vs Uploaders
Hey all,
Over the past few weeks, after Joey Hess created the jetring keyring
management tool from whole cloth [0], I've been poking at changing dak
to support a maintainers keyring [1] so that we can make it possible for
people who want to work on just one or two packages able to do exactly
that. I think that's at a point that I'm happy with now, so ftpmaster
now effectively has the ability to:
a) add a third keyring for people allowed to upload to the archive,
(in addition to debian-keyring.{gpg,pgp}) that contains keys for
maintainers and is managed separately to the developer keyring
b) restrict certain uploaders from sponsoring packages
(ie, giving signing a .changes file that claims to be made by
someone else) and from doing NMUs (ie, uploading a package that's
maintained by someone else and that they're not listed as an
Uploader for, or anything that needs NEW or BYHAND processing)
My theory is that we should do something like this:
1) create a class of contributors called debian maintainers
2) have a group of people authorised to maintain the keyring for
those people, using jetring
3) allow existing developers who're already involved in mentoring
and the new-maintainer process to recommend people for inclusion
in the maintainer keyring
If people don't do a good job as a maintainer they should have their
priveleges removed fairly promptly; and if a developers recommends
people to be listed as maintainers who turn out to be a problem, or if a
developer just doesn't stay around to help them out when the need arises,
they should stop being allowed to recommend people.
My thought for showing that you're involved in mentoring was something
like has sponsored 30 uploads in the last six months or has AMed at
least ten applicants through to DD status or similar, though I don't
see any reason to make those rules too hard and fast.
The idea is that not everyone who wants to be involved in Debian is
(currently) able to do everything we expect of DDs, or (currently)
wants to do anything more than maintain a couple of packages. At the
moment people who fit that description need a sponsor to help them with
every contribution they make, even if they've already been contributing
for years. I think we can optimise that without losing quality at all,
and leave our sponsors and mentors more time for carefully reviewing
the packages that do need review.
I'm happy to manage the keyring as a trial for a few months, though
I'd prefer not to do it alone, or longterm. ATM I don't know of any
non-developers whose work I'm familiar enough with to be comfortable
recommending myself though, so I definitely can't do (3).
In the long term, I think it would be sensible to have keyring-maint
be a group looking after both this keyring and the developer keyring;
and also to have the members of that team not be part of DSA or DAM to
avoid concentration of powah.
To get a vote, you'd still need to be approved as a DD by the DAM, and
you wouldn't get a login on any d.o machines just by being a maintainer.
Either of those could be changed if we decided we wanted to at some point,
of course.
Cheers,
aj
[0] http://lists.debian.org/debian-project/2007/02/msg00274.html
[1] http://azure.humbug.org.au/~aj/blog/2006/04/12#2006-04-11-maintainers
...is my original blog post on the subject. Marc Brockshmitt posted
about this to d-d-a last year too:
http://lists.debian.org/debian-devel-announce/2006/04/msg6.html
(see the section Separate upload permissions, system accounts and
voting rights). Christoph Berg gave a talk on the topic at debconf6
as well, and the video of that is downloadable, see:
http://meetings-archive.debian.net/pub/debian-meetings/2006/debconf6/
signature.asc
Description: Digital signature
Re: Developers vs Uploaders
On Wed, Mar 14, 2007 at 08:50:06PM +0100, Bastian Venthur wrote: My first thought: do we really need this new class of contributors? I mean how many people do you currently know fitting in this category (don't like to become DD just maintainers). It's not don't want to be a DD, it's aren't a DD, but are still able to be trusted to some extent. For example, we've got around 2000 unique maintainers these days [0], which is about twice the number of DDs we have... My second thought: Should we really allow anonymous people to upload packages? Shouldn't they at least prove that they are who they claim to be (via gpg-key singed by an existing DD)? Yes, definitely. (That's mentioned in some of the references in my earlier email) Who is responsible if a maintainer uploads malware, the one who recommended him? The maintainer who uploads it is responsible. The one who recommended him is responsible for recommending someone who uploaded malware. Both those would likely be treated differently if it was repeated or deliberate compared to rare or accidental, of course. If we decide it's worth more than a warning in either case, we'd respond by removing the maintainer's ability to upload or stop accepting recommendations from the developer, respectively. Oh, and will there be a vote about this issue or is it still in the discussion-phase or is it already decided? If discussion wasn't worthwhile, I wouldn't have posted... Cheers, aj [0] projectb= select count(name) from maintainer where name not like '%lists%'; count --- 2056 (1 row) signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On Sat, Feb 24, 2007 at 01:59:07AM -0500, Joey Hess wrote:
How would you convert gpg --refresh-keys into changeset based
operations, I wonder? Maybe you could do it by something like: [...]
That's beautiful, if we can figure out what changed-keys is. :-)
Two ways: either parse the output of gpg as it's running:
gpg: requesting key CA57AD7C from ldap server keyserver.pgp.com
gpg: key CA57AD7C: PGP Global Directory Verification Key not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: requesting key DDD11D8A from hkp server subkeys.pgp.net
gpg: key DDD11D8A: Ted Percival (midg3t) [EMAIL PROTECTED] 74 new
signatures
gpg: Total number processed: 1
gpg: new signatures: 74
or run gpg --list-keys --verbose on the old and new keyring, and see
what differences you find.
I guess we need something that'll do that anyway, though. How about the attached
as a proof of concept?
] $ ./diffring.pl ./debian-keyring.list ./debian-keyring-aj.list
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -181)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -86)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -191)
] Removed uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: 173)
or
] $ ./diffring.pl ./debian-keyring-aj.list ./debian-keyring.list
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +181, -0)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +86, -0)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +191, -0)
] Added uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: 173)
It works on the output of `gpg --verbose --list-sigs', which is a bit
slow on a full keyring. Oh well.
On Sat, Feb 24, 2007 at 03:04:57AM -0500, Joey Hess wrote:
[EMAIL PROTECTED]:~ls jetring
May Manoj's typos live forever :)
[EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringshead
emeritus-keyring/add-001B3BA1
Comment: extracted from emeritus-keyring.pgp by keyring-explode
Action: import
Data:
-BEGIN PGP PUBLIC KEY BLOCK-
No import date?
Ok, no significant changes, only id rearrangement and dup removal.
diffring.pl should deal with those fwiw. Doesn't deal with revocations, and
may not deal well with subkeys.
Cheers,
aj
#!/usr/bin/perl -w
# Copyright (c) 2007 Anthony Towns
# GNU GPL; v2 or later
# Gives an overview of what changed between two keyrings
use strict;
my $l = parse_keyring($ARGV[0]);
my $r = parse_keyring($ARGV[1]);
foreach my $ku (sort keys %{$l}) {
if (not defined $r-{$ku}) {
my $n = @{$l-{$ku}};
print Removed uid $ku (sigs: $n)\n;
} else {
my $a = $l-{$ku};
my $b = $r-{$ku};
my ($i, $j) = (0,0);
my ($del, $add) = (0,0);
while() {
my $A = $a-[$i] || G;
my $B = $b-[$j] || G;
# avoid dupes:
if ($i 0 $A ne G $A eq $a-[$i-1]) { $i++; next; }
if ($j 0 $B ne G $B eq $b-[$j-1]) { $j++; next; }
# compare:
my $x = $A cmp $B;
if ($A eq G and $B eq G) { last; }
if ($x == 0) { $i++; $j++; next; }
if ($x 0) { $add++; $j++; next; }
if ($x 0) { $del++; $i++; next; }
}
if ($add or $del) {
print Updated uid $ku (sigs: +$add, -$del)\n;
}
}
}
foreach my $ku (sort keys %{$r}) {
if (not defined $l-{$ku}) {
my $n = @{$r-{$ku}};
print Added uid $ku (sigs: $n)\n;
}
}
sub parse_keyring {
my $k = shift;
my $fd;
#open $fd, gpg --no-default-keyring --no-auto-check-trustdb --keyring $k --verbose --list-sigs | or die couldn't open keyring $k: $!;
open $fd, $k or die couldn't open gpg--list-sigs-output $k: $!;
my $x = build_key_hash($fd);
close($fd);
return $x;
}
sub build_key_hash {
my $f = shift;
my $keys = {};
my ($k, $u);
while ($f) {
chomp;
if (m/^\s*$/) {
# skip
} elsif (m/^pub/) {
$k = substr($_,6);
$k =~ s/\s.*//;
$u = undef;
} elsif (defined $k m/^sub/) {
$u = substr($_,6);
$u =~ s/\s.*//;
$keys-{$k-$u} = [];
} elsif (defined $k m/^uid/) {
$u = substr($_,21);
$keys-{$k-$u} = [];
} elsif (defined $k m/^rev/) {
# skip
} elsif (defined $k defined $u m/^sig/) {
push @{$keys-{$k-$u}}, substr($_, 13, 19);
} else {
#print XXX: $_\n;
}
}
foreach my $ku (keys %{$keys}) {
$keys-{$ku} = [ sort( @{$keys-{$ku}} ) ];
}
return $keys;
}
signature.asc
Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 10:44:55AM +0100, Pierre Habouzit wrote: So sorry, but I don't buy a single word of your argumentation here. It wasn't an argument; it was just a statement of things are, as I see them. In so far as how things are isn't well communicated in those areas, I don't see any other way of addressing that other than the above. We're far beyond trying to help them, at least for me, [...] Your opinions are only ever going to be considered in so far as you're willing to help make them a reality. If you're not willing to help, find something else to worry about. Cheers, aj signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: The primary reason why there's only one keyring-maint is the binary blob problem: [...] [...] This issue has been mentioned briefly in the past a few times, but to the best of my knowledge, no one's taken up the challenge so far. One of those mentions was in a mail to Branden as DPL in November 2005. I figure since I'm DPL now, it's fair game for me to quote the bits of that mail that don't go into any personal stuff: ] To: Branden Robinson / Debian Project Leader ] Subject: Re: keyring-maint assistance needed? ] From: James Troup ] Date: Tue, 22 Nov 2005 02:46:34 + ] ] [...] ] ] I think in the long term, keyring maintenance should obviously be done ] by more than one person. ] ] But I also think the ill-effects of forcibly or hurriedly adding ] additional maintainers vastly outweigh the ill-effects of its current ] one-man state. ] ] There's also a bunch of stuff that could be done, most of which is ] being worked on, that doesn't involve adding more people or have the ] problems associated with that. ] ] The three things most need to be worked on are: ] ] (a) spam. The keyring-maint address gets something like, ] conservatively, 500 spams for every non-spam email. This is ] after 4 layers of spam filtering. Thanks to Ryan's stellar work ] on our email infrastructure there are now options available to us ] that should allow us to drop this down to 0 spams (by requiring a ] specific tag in the subject, a pseudo-header in the body or a ] specific address to be used). ] ] (b) if/when (a) gets fixed[0], I'm going to look at setting up a ] Request Tracker instance to manage the keyring. Apart from ] helping me in terms of managing (and not losing track of) ] requests, it will also allow better transparency in terms of ] people being able to see how many and what requests are ] pending[1]. The only potential problem here is finding a ] suitable machine as RT is a big scary perl web app that can ] require a lot of resources. ] ] (c) right now changes to the keyring are fundamentally unauditable ] unless they're done by a single person on a trusted machine with ] trusted scripts. There are a bunch of ways to solve this, but ] the best suggestion I've heard so far is something that breaks ] down the 17Mb binary blob of 'debian-keyring.gpg' into single key ] auditable chunks that can then be managed in a sane way. The ] scripts to do these would have to be simple first and foremost so ] they could be audited. ] ] I'm working on (a) and (b) but I'm not working on (c) because I simply ] don't have time - others are of course welcome to. I've discussed the ] idea with several people in real life, and it's come up in the thread ] on -private. I also believe that with (a) and (b) done there is no ] pressing need for (c) although it'd obviously be nice to have. ] ] [...] ] ] -- ] James ] ] [0] RT sends auto-replies so it isn't an option as long as the email ] address is getting this much spam. ] ] [1] Although given the nature of some of the emails sent to ] keyring-maint things in the RT will be private by default and only ] public when they're moved to a public queue. I summarised this portion of the mail this time last year, too, fwiw: http://lists.debian.org/debian-vote/2006/03/msg00275.html Cheers, aj signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:57:01PM +0100, Frank K?ster wrote: Anthony Towns aj@azure.humbug.org.au wrote: We're far beyond trying to help them, at least for me, [...] Your opinions are only ever going to be considered in so far as you're willing to help make them a reality. If you're not willing to help, find something else to worry about. So you think that from the project's point of view it is okay if nobody can expect basic support from core infrastructure teams? I think we're talking about different things, so the following's a bit verbose in hopes that it makes it a bit clearer. If they don't do it, and it's important, someone else will. Cf the security team versus testing security support, backports or volatile versus ftpmaster, alioth versus DAM, or whatever. So yes, I do think it's okay even if we couldn't expect basic support from core infrastructure teams. All we are allowed to consider with respect to these teams is to help *them*, not to achieve help? You can reasonably expect them to do what they've said they will, or what the role obviously entails. You can also expect that every now and then you'll be disappointed and that won't be achieved, and that the only things you can really do about that is not worry about it and hope it's better next time, work out how to do it yourself, or figure out some way of helping them out. That's not what I was referring to though: I was talking about when you want someone else to do things in the way you'd like, rather than the way they prefer. That's something that only ever happens if you help out, whether you're talking about a user making suggestions to a maintainer, a maintainer making suggestions to upstream, or anything of the sort. You're not owed anything by people who freely donate their time to maintain things you use, it works better if you remember that. All I'm saying is it's a two-way process -- if you spend lots of time actually helping out someone, and they don't return the favour by helping you out, you shouldn't keep wasting your time. If yes, what is then the purpose of having infrastructure teams? If you don't have infrastructure teams you don't have infrastructure in the first place, well maintained or not... And if we didn't have useful infrastructure, someone would make it, and we'd have an infrastructure team. No purpose required... I don't think I understand the question. Cheers, aj signature.asc Description: Digital signature
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 08:05:33PM +0100, Josselin Mouette wrote: Anthony Towns wrote: I've been delaying this mail for a while now Is it purely coincidental that it was sent the same day as your nomination for the DPL elections? Not remotely; I was delaying the nomination until I'd finished that mail (which I've been working on since end of January) and the trademark thing. Cheers, aj signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On Sat, Feb 24, 2007 at 12:54:41AM -0500, Joey Hess wrote: That means you can't reorder changesets easily. I wonder if it'd be better say del uid [EMAIL PROTECTED] and have the tool work out which uid (if any) that is. I don't feel that reordering changesets is a good thing in general, since it can lead to other problems (for example, reordering a key deletion to come before a key addition), and it loses history that can be useful for reviewing why and when a given change was made. I was more meaning it as an optimisation so you could ignore key add 0x7172daed if there was a key delete 0x7172daed changeset later. Likewise a uid add followed by a uid del or whatever. How would you convert gpg --refresh-keys into changeset based operations, I wonder? Maybe you could do it by something like: cp real-keyring.gpg tmpkeys.gpg gpg --keyring tmpkeys.gpg --refresh-keys for x in $(changed-keys); do ( echo Changed-By: me echo Comment: new signatures/uids for key $x echo Action: import --keyserver-options merge-only echo Data: gpg --keyring tmpkeys.gpg --ascii --armour --export $x | sed -e 's/^/ /' ) changeset-refresh-$x done rm tmpkeys.gpg echo Now you just have to apply changeset-refresh-* to real-keyring.gpg :) ? Cheers, aj signature.asc Description: Digital signature
Bits from the DPL: DSA and buildds and DAM, oh my!
Hey all, I've been delaying this mail for a while now, because I haven't been able to work out a way of writing it that doesn't strike me as not treating some of the concerns I've heard seriously enough. I still haven't come up with a way of avoiding that unfortunately, but it seems better to get something happening, even if it isn't really good enough. I'm trying to be descriptive here rather than prescriptive or proscriptive -- we've got a DPL campaign coming up where there'll be plenty of time to talk about various ways of improving things, so to me the most useful thing to do now seems to be providing a good understanding of how things are at the moment, and have an informed discussion over the next few weeks, rather than a repeat of all the arguments we've already had. So the first thing I'd like to note is that despite all the criticisms there are of things like new-maintainer, buildd administration, ftpmaster, system administration, and whatever else, objectively all of those areas are very impressive: compared to other distributions, we still have a huge number of contributors, we still support a huge number of architectures at an amazing level of quality, we still have a huge number of packages that are maintained at an amazingly high quality, we have a huge number of services that are administered in an 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. Okay, this is going to get really long, so if you've read this far and don't really care about any of the above areas, now's the time to skip to the next message and get on with your life. I think a good step is to cover what rights some of the more controversial roles actually have, as best I understand it. Again, this is just meant to be a description of what is, not necessarily what I think things should be, or was originally intended or anything else. * Debian Account Manager(s) (DAM) - Joerg Jaspert and James Troup - delegated authority to determine who is a developer - may only exercise this authority in cooperation with keyring-maint - have created assisting roles in the form of FrontDesk and Application Manager - nm.debian.org documents current progress of active applications - numerous amounts of documentation and sample reports around for what form applications should take * Debian System Administration (DSA) - James Troup, Martin Schulze (Joey), Ryan Murray, Phil Hands - delegated authority to determine official Debian services via delegation of debian.org subdomains - delegated authority to determine unofficial Debian services via delegation of debian.net subdomains - default administrators (root@) for machines donated to Debian - have created db.debian.org for tracking machines and accounts and controlling debian.net subdomains - listed as group adm on DSA adminned machines - have a repository for customised packages at deb-src http://db.debian.org/ debian-admin/ * System admin for host (root@host) - determined by owner/sponsor of hardware/bandwidth - responsible for security of machine - determines who is allowed access to host - determines what services are provided by host * Debian Archive Maintainer(s) (ftpmaster) - Ryan Murray, James Troup, Anthony Towns - responsible for maintianing the archive on ftp-master.debian.org - determines what may be accepted into the archive - determines the process by which software is accepted into the archive - listed as group debadmin on DSA adminned machines, have access to role user dak on DSA adminned machines - assisted by Joerg Jaspert, Jeroen van Wolffelaar, Randall Donald, Michael Beattie - ftpmaster and assistants are listed as group ftpteam on DSA adminned machines - maintain various bits of information about how the archive is administered at http://ftp-master.debian.org/ and have a developer-accessible mirror of the archive software on merkel.debian.org - BTS psuedopackage is http://bugs.debian.org/ftp.debian.org * Debian Kerying Maintainer (keyring-maint) - James Troup - responsible for maintaining the keyring containing public keys for all developers as used by DSA for db.debian.org, ftpmaster for the archive and others - provides http://keyring.debian.org/ interface to the keyring - maintains debian-keyring package - listed as group keyring on DSA adminned machines - assisted in the past by Michael Beattie - some procedures documented in section 3.2 of the developers reference and at http://keyring.debian.org/replacing_keys.html * Buildds... * Local admin of buildd
Re: BREAKING NEWS: Debian developers aren't trusted
On Fri, Feb 16, 2007 at 07:55:10PM -0800, Steve Langasek wrote: On Thu, Feb 15, 2007 at 10:00:25AM +0100, Frank K?ster wrote: Are you so overworked, or are you deliberately forgetting? It has been suggested multiple times in the past to use existing or new hardware and add it to the set of standard autobuilders. Many arches do not meet the redundancy requirement, Um, the only archs that don't meet the redundancy requirement today are i386 and ia64. http://release.debian.org/etch_arch_qualify.html says alpha, amd64, arm, hppa, i386, ia64, and m68k don't meet it, fwiw. Cheers, aj signature.asc Description: Digital signature
Re: Debian logos and trademarks
Hi SPI! As per the thread on debian-project [0] I'm writing to request that SPI relicense the Debian logos that they hold the copyright to [1] under the MIT copyright license: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. I'm further requesting that SPI not enforce the open use logo (ie, the swirl) as an exclusive trademark, and to limit any enforcement activities to ensuring the trademark remains available to be to refer to and promote Debian. The official use logo (ie, the swirl and bottle) should continue to be enforced as an unregistered trademark, with that logo (or similar logos) only being authorised to be used where the product or service being referred to is officially related to Debian (such as an official CD image, a t-shirt promoting debian.org, a Debian developer's business card, etc). In cases of doubt, [EMAIL PROTECTED] may be contacted to determine whether something is officially related to Debian. If the board has any concerns or questions regarding this course of action, please don't hesitate to raise them. Cheers, aj [0] http://lists.debian.org/debian-project/2007/02/msg00019.html [1] http://www.debian.org/logos/ signature.asc Description: Digital signature
Re: BREAKING NEWS: Debian developers aren't trusted
On Thu, Feb 15, 2007 at 06:34:16PM +1100, Hamish Moffatt wrote: On Thu, Feb 15, 2007 at 01:13:36PM +1000, Anthony Towns wrote: -vote dropped On Wed, Feb 14, 2007 at 03:06:01PM +0100, Martin Zobel-Helas wrote: i think someone running more than one autobuilder for more than _two_ years now (okay, not for the officical archive, but i see that as nonrelevant here) demonstrats very good that he mets your mentioned technical constraints. AIUI, Aurelian doesn't have the capability to run a non-emulated arm buildd. While http://blog.aurel32.net/?p=25 is a good demonstration of some things, I don't think it's the level of buildd we want for our release architectures. Wow, was there a point to your post or was pure insult? What's insulting in that (apart from the misspelling of Aurelien)? From http://blog.aurel32.net/?p=33: Yes I agree that real machines would be better, but I dont have a stack of fast ARM machines at home. so, afaict, he doesn't have the capability to run a non-emulated arm buildd. And hacking together a buildd quickly and easily is impressive and useful for new ports, but it's more important for buildds for release architectures to be well-connected and reliable over a long period. We probably could change that expectation and have buildds be put together by DDs from whatever they have lying around and hosting them at home; I don't think it'd be a good idea, but others mileage may vary. Not every criticism is an insult, and if you want to know why things don't happen you need to be able to take criticism without taking insult. Cheers, aj signature.asc Description: Digital signature
Re: BREAKING NEWS: Debian developers aren't trusted
On Thu, Feb 15, 2007 at 08:37:27AM +0100, Martin Zobel-Helas wrote: On Thu Feb 15, 2007 at 13:13:36 +1000, Anthony Towns wrote: -vote dropped And readded apparently. Do we really have to have these conversations across multiple lists? i think someone running more than one autobuilder for more than _two_ years now (okay, not for the officical archive, but i see that as nonrelevant here) demonstrats very good that he mets your mentioned technical constraints. I didn't thought of Aurelien, but of a few other persons, who are acting as buildd maintainers for experimental and non-free packages. Experimental and non-free packages go to the official archive... I'm not seeing what you're asking for here. Beyond re-enabling access for those packages to be uploaded over the past couple of months (which has now happened) I haven't heard any requests related to any of that. Cheers, aj signature.asc Description: Digital signature
Re: BREAKING NEWS: Debian developers aren't trusted
On Thu, Feb 15, 2007 at 03:17:58PM +0100, Aurelien Jarno wrote: FYI, I am running a wanna-build database for hurd-i386, kfreebsd-i386 and kfreebsd-amd64 on my home server, and running three build daemons, two for kfreebsd-i386 (yes, contrary to some official architectures we have buildd redundancy), and one for kfreebsd-amd64. And that for almost 2 years. Aren't you running emulated buildds for m68k too? Or was that someone else? _That_, imo, is awesome both for demonstrating emulated buildds work, and reviving m68k... Assuming I'm not confused. Cheers, aj signature.asc Description: Digital signature
Re: BREAKING NEWS: Debian developers aren't trusted
On Thu, Feb 15, 2007 at 10:00:25AM +0100, Frank K?ster wrote: i think someone running more than one autobuilder for more than _two_ years now (okay, not for the officical archive, but i see that as nonrelevant here) demonstrats very good that he mets your mentioned technical constraints. I didn't thought of Aurelien, but of a few other persons, who are acting as buildd maintainers for experimental and non-free packages. Experimental and non-free packages go to the official archive... I'm not seeing what you're asking for here. (If there's something more than the general comments Frank made, I'm still not seeing it. TTBOMK, the non-free and experimental builds aren't at all integrated with the buildd.d.o stuff, and there's been no particular interest in changing that. If that's not the case, it's probably worth talking about sometime) Are you so overworked, or are you deliberately forgetting? It has been suggested multiple times in the past to use existing or new hardware and add it to the set of standard autobuilders. Many arches do not meet the redundancy requirement, and we don't have autobuilders for i386 at all AFAIK. Moreover, the current buildd admin's apparently don't have adequate time to communicate, which could be ameliorated by adding people. Even if nobody had asked so far, we should ask people who seem capable of doing it. I've been thinking for a few days now that people in Debian disagree too much (hence the comments preceding my responses to Raphael in an earlier message), so starting now, I'm going to stop replying to mails by focussing on differences, and start with agreements. Let's see how long it takes until I can't stop myself from adding a but. [0] There are a number of serious problems in how the Debian infrastructure's managed. That may be too strong: I mean to say that they're important, without being critical to be solved immediately [1]. And often the impact of these problems is to block other people's attempts to contribute to Debian, and in so doing disrespect their contributions and discourage further contributions, though in some cases those contributions are merely thrown out as collateral damage along with something that should be blocked, whether that be a buggy upload or some changes that need further review. The right way of dealing with that is to work with the potential contributor to ensure they understand the issues that're involved so that their future contributions can be accepted and will be useful. IMO, that applies whether the contribution's a patch, or an emulated buildd. I guess I'd argue that it applies to existing contributors too, if you want to critique their performance. I've found it difficult to work up the energy to try working with potential contributors on this score because there seems to be so much rage about the way things work now that I can't really imagine reaching that level of mutual understanding. I can't say I like that state of affairs much. Anyway, I already have a related email that I've promised to send out that I hope will show something of a step towards fixing these problems. I think I'm going to bow out of the discussion for the minute until I can get that off my plate. Unfortunately, that'll take longer than YA inconsequential mail where I'm able to just write what I think... [2] Cheers, aj [0] Or if I can even work out how to start the next paragraph without a but... [1] They're mostly long-term problems, so if they were critical, frankly we'd not be having this conversation, and people wouldn't be asking if Debian was dying, they'd be getting us confused with AmigaOS... [2] Wow, I'm really in the habit of qualifying everything I write. That was much harder than I expected... signature.asc Description: Digital signature
Google Summer of Code
Hey all, The Google's running a Summer of Code again in 2007, mentoring organisations need to submit applications between the 5th and 12th of March. Announcement: http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html Deadlines: http://code.google.com/support/bin/answer.py?answer=60325topic=10729 Deadlines paraphrased: March 5th -- decide whether we want to be a mentoring organisation, and if so, have a list of suggested projects up, along with recommendation on what students should expect if they get accepted by Debian March 14th -- be ready to start working with potential applicants March 24th - April 9th -- review applications April 9th - May 28th -- introduce accepted students to Debian May 28th - August 20 -- Summer of Code work Anyone want to volunteer to take the lead on the first couple of steps? Cheers, aj signature.asc Description: Digital signature
Re: BREAKING NEWS: Debian developers aren't trusted
-vote dropped On Wed, Feb 14, 2007 at 03:06:01PM +0100, Martin Zobel-Helas wrote: Maintaining a buildd isn't trivial, there's: - making sure they don't get rooted, and their builds compromised - keeping the chroot up to date - keeping in sync with w-b / sbuild changes - keeping in sync with the infrastructure upstream (building from incoming, access to the buildd.d.o, etc) - keeping the hardware available and running - keeping the buildd building packages that will work It's not /that/ hard either (even if it's not something I could do without a chunk of learning), but basically, yeah there are technical constraints. The only policy constraint is that we're aiming to keep the number of buildds limited to two or three per architecture (where possible); the social constraints are mostly about convincingly demonstrating that the technical constraints will be met on an ongoing basis. i think someone running more than one autobuilder for more than _two_ years now (okay, not for the officical archive, but i see that as nonrelevant here) demonstrats very good that he mets your mentioned technical constraints. AIUI, Aurelian doesn't have the capability to run a non-emulated arm buildd. While http://blog.aurel32.net/?p=25 is a good demonstration of some things, I don't think it's the level of buildd we want for our release architectures. In general, I could pretty easily imagine a buildd that fails every one of those points still being suitable for a non-release arch for two years. Cheers, aj signature.asc Description: Digital signature
Re: Debian logos and trademarks
On Wed, Feb 07, 2007 at 11:57:13PM -0800, Don Armstrong wrote: On Thu, 08 Feb 2007, Anthony Towns wrote: The DFSG refers to copyright licensing, it doesn't cover patents or trademarks. It actually doesn't refer to any of them specifically. It does talk about licensing, but it doesn't clarify whether it's refering to copyright licensing or trademark licensing. It talks about modification and distribution, which are copyright issues. In any event, this entire line of argument isn't particularly important, so long as no one puts the official logo into main or contrib. That's a completely new line of argument to the best of my knowledge, and not one which Debian should support, in my opinion. Having a free copyright license, and a reasonably permissive trademark license is sufficient for a name or logo to be in main, cf the terms Gnome, apache, java, or Debian for example. If you want to do an in depth legal/dfsg analysis in response to this, please limit it to -legal; if you want that response to be taken into account, please make it persuasive to people who don't already agree with you -- consider people who hold each of the opinions represented by the GFDL ballot from last year, eg. Please note that historically we've protected both logos (the swirl and the bottle) using a non-free copyright license, and as unregistered trademarks. Cheers, aj signature.asc Description: Digital signature
Re: Debian logos and trademarks
On Wed, Feb 07, 2007 at 10:03:52AM +0100, Bastian Venthur wrote: I have a question. If I understand you correctly you want to put the official use logo under the MIT license AND enforce it as an unregistered trademark so that someone can only use it if we (who?) authorize it. This sounds contradicting to me and how does this meet the DFSG? The DFSG refers to copyright licensing, it doesn't cover patents or trademarks. The difference between trademarks and copyright, is that copyright covers all copies and derivatives, while trademarks cover anything that's confusingly similar. So if you independently create a logo that looks confusingly similar, you need a trademark license but not a copyright license; while if you create a derived works that's not similar at all, you need a copyright license, but not a trademark license. Having a restrictive trademark license prevents people from using confusingly similar logos, while a DFSG-free copyright license allows people to make derivatives as long as they're not confusingly similar. BTW I am not a lawyer, so what does to enforce an unregistered trademark actually mean? See http://www.ggmark.com/protect.html eg. Cheers, aj signature.asc Description: Digital signature
Debian logos and trademarks
Hi all, Back in October, during the firefox/iceweasel dispute, Branden Robinson and I expressed a little exasperation on IRC that Debian wasn't really setting a great example itself in how it licenses its logos. We had a bit of a chat about that and that resulted in a rough agreement on what to do, which Branden wrote up on the Debian wiki at: http://wiki.debian.org/ProposedTrademarkPolicy Since then, that hasn't seen much real feedback, so I've been reluctant to push it any further -- it's hard to tell whether a lack of feedback means we don't care, that sounds fine, this is too complicated, whatever you do is wrong, or just we haven't heard about this or looked at it. Fortunately, I had the opportunity to do a bit of a straw poll at the Debian miniconf at LCA of what people thought about freeing up the Debian trademark policy, and it seems that people there were pretty much for the idea. As such at the end of this week, I'm planning on asking the SPI board to relicense the Debian logos as follows: * both logos shall be released under the MIT copyright license: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. * the open use logo will not be enforced as a trademark; anyone may use it or create similar logos in whatever way they like, though we will continue using it to refer to and promote Debian. * the official use logo will be enforced as an unregistered trademark; and we will only authorise use of the logo or similar logos where the product or service being referred to is officially related to Debian (such as an official CD image, a t-shirt promoting debian.org, a Debian developer's business card) I think that's a good way of ensuring both our logos meet the DFSG, and also provides both a good experiment in a completely free trademark license that fairly accurately reflects our current treatment of the open use logo as well as a reasonable example for groups who want to have some protection for their brand but still be a good citizen of the free software community. Anyway, if anyone has some fairly convincing reasons why the above is a bad idea, please do speak up now. If you think it's a good idea, and want to refute the no feedback issue mentioned above, feel free to comment too. :) Cheers, aj signature.asc Description: Digital signature
Re: Sven Luther, report of the mediation attempt and further actions
[-private bcc'ed] As well as this mail on -project, Sven's also written to both -kernel and -powerpc: http://lists.debian.org/debian-powerpc/2007/01/msg00012.html http://lists.debian.org/debian-kernel/2007/01/msg00042.html On Tue, Jan 02, 2007 at 09:30:01AM +0100, Sven Luther wrote: On Tue, Jan 02, 2007 at 05:47:36PM +1000, Anthony Towns wrote: On Fri, Dec 29, 2006 at 05:38:19PM +0100, Sven Luther wrote: On Sat, Dec 30, 2006 at 12:44:46AM +1000, Anthony Towns wrote: skipped private comment from Anthony Towns where he asks me to be banned from debian lists I said i would, and i will do it. I am a man of word, contrary to others. But as there seem to be a technical and ethical problem in banning someone from the lists, i propose a self-imposed not access to the lists until end of february, with the lone exception of problems i am currently working on (like the infamous xserve/udev/d-i/initramfs bug), and the BTS. skipped hypocrit private comment from Anthony Towns where he denied me the right to participate in the discussion about if i was to be baned or not skipped comment from Anthony Towns, where he believes mediation is useless The context Sven summarises above was, in fact: On Fri, Dec 29, 2006 at 05:38:19PM +0100, Sven Luther wrote: On Sat, Dec 30, 2006 at 12:44:46AM +1000, Anthony Towns wrote: Do you, in fact, accept the result of this mediation? I said i would, and i will do it. I am a man of word, contrary to others. But as there seem to be a technical and ethical problem in banning someone from the lists, i propose a self-imposed not access to the lists until end of february, with the lone exception of problems i am currently working on (like the infamous xserve/udev/d-i/initramfs bug), and the BTS. Sven, in the three days since the post quoted above, you've made twenty-nine posts to -private, including nine posts in this particular subthread. While that isn't cause to doubt that you're fundamentally a man of your word, you aren't managing to keep it in this case. While that remains the case, I don't think further mediation or arbitration is likely to be useful. The result of the mediation referred to was: The main problem so far is that Sven still brings the issue over and over: this does not help at all, and the only effect of this behaviour is growing the conflict. With this e-mail, I'm asking who is concerned to take this action in the interest of Sven, the d-i team and the whole Debian: * Ban for 2 months Sven Luther from all the debian-mailing lists. (I am not sure that it is also possible for debian-vote) If Sven bug-reports or IRC conversations in the next two months will still contain references to the revocation of his SVN access to the d-i repository or to this ongoing dispute, I'll ask for his permanent ban from Debian mailing-lists. To make it more clear: Sven, if you don't stop with those non-technical e-mails and messages the issue won't be solved. When I proposed myself as mediator, I knew that I couldn't make the magic happen, but at least I need some collaboration from you as well as from the d-i team. If somebody did not want to apply your patch, or if you do not like what somebody wrote about you, or if your opinion does not match the others' one, please ignore them. My hope is that a ban from debian mailing lists for two months could help you to understand the weight that your messages have in this context. (quoted with permission) I don't think it's productive to move this conversation from -private to -project; but given it has been, it seems appropriate to give people following this more than just Sven's side of the story. Anyway, i take this as announcement that i will now retire from debian until end of february, and not post on debian mailing lists until the end of february, with a few lone exceptions : 1) If someone bashes me on irc or on mailing lists, i will ask you as DPL to immediately apply the ban to him too, and if you fail to do so in a timely fashion, i will stop my self-imposed ban, and immediately ask for your revocation as DPL. 2) I will write a mail on a few chosen lists (like debian-powerpc) to announce my decision. If someone else than Fabio replies to these, i will ask you as DPL to extend the ban to them, and if you fail to do so in a timely fashion, i will stop my self-imposed ban, and immediately ask for your revocation as DPL. Sven, the mediation was an attempt to help you and the d-i team work together effectively in future. If you don't want to accept it, you don't have to; but if you do, you cannot use it as a bargaining chip to threaten other developers if they don't follow your demands. 3) I ask the permission to take Frans email public, so that everyone will see how i hold to my world and he does not. As a developer, you're expected to respect the privacy
Re: Sven Luther, report of the mediation attempt and further actions
On Wed, Jan 03, 2007 at 09:42:17AM +0100, Sven Luther wrote: Oh well, i guess it is ok for me to reply to a few points on this. No, Sven, it is not okay to say I agreed instead to a self-imposed removal from lists, so this will be my last post until end of februrary, and then keep posting. Anthony, i asked that exclusively Fabio did reply to my mails, because you have proven to not be able to be neutral and objective in this. Should i ask you now to ban yourself from the lists for as long as i am banned :) ? You can ask for whatever you like, but as I said: On Wed, Jan 03, 2007 at 06:05:08PM +1000, Anthony Towns wrote: Sven, the mediation was an attempt to help you and the d-i team work together effectively in future. If you don't want to accept it, you don't have to; but if you do, you cannot use it as a bargaining chip to threaten other developers if they don't follow your demands. If you were to follow Fabio's suggested course of action and stop posting to lists, you may be able to find a way to work effectively with other people in Debian. But that's _all_ that will achieve, and it certainly doesn't obligate anyone else to stop discussing anything, no matter how much you might want to be involved in such a discussion. Cheers, aj signature.asc Description: Digital signature
Re: Help for OSS Survey
On Sat, Dec 23, 2006 at 01:30:48PM +0100, Sven Luther wrote: Indeed, it was her which i had in mind originally, and which i urged Anthony as DPL to contact. I was mostly ignored except one post saying why don't you contact them yourself. Do you know her contact info ? Would you like to ask her what is possible or such ? Err, she's on Planet Debian -- which links to her blog at: http://www.healthhacker.org/satoroams/ She links to her CV from that page, via: http://healthhacker.org/satoroams/?page_id=531 and the CV and contact information itself is at: http://www.healthhacker.org/biella/web_cv.pdf Cheers, aj signature.asc Description: Digital signature
Re: Please appoint one new person to the DSA Team
On Sun, Dec 17, 2006 at 09:06:01PM +0100, Aurelien Jarno wrote: It is known among debian developers that the Debian System Administration Team (aka DSA or [EMAIL PROTECTED]) is not really responsive. So apparently this complaint was immediately followed up by setting up an emulated autobuilder not synced in with the regular buildd.debian.org stuff [0]. This resulted in James and Ryan adding a quick hack to disable arm uploads, which have remained disabled over the past few days, apparently with some of the deferred uploads from the official autobuilder getting overwritten by later uploads by Aurelian's autobuilder. This was brought to my attention as a result of the release team trying to get a fixed version of attr into unstable; for the time being, I've re-enabled arm uploads signed by James Troup, Ryan Murray, and Martin Michlmayr, as well as (hopefully) security uploads. Everyone else will get a REJECT saying not signed by authorised uploader. That means contrib and non-free builds for arm will probably all be REJECTed. This will stay this way until someone in ftpmaster is confident arm builds signed by other people are likely to be reliable and the check is removed. Cheers, aj signature.asc Description: Digital signature
Re: Please appoint one new person to the DSA Team
On Wed, Dec 20, 2006 at 04:27:41PM +, Simon Huggins wrote: So apparently this complaint was immediately followed up by setting up an emulated autobuilder not synced in with the regular buildd.debian.org stuff [0]. [...] PS you're missing your footnote. [0] http://blog.aurel32.net/?p=33 Cheers, aj signature.asc Description: Digital signature
Re: Please appoint one new person to the DSA Team
On Wed, Dec 20, 2006 at 08:38:33PM -0800, Russ Allbery wrote: Would you, as DPL, please try to address the original issue? Martin, Branden and myself have all been trying to address the original issue as DPL; messages like the one beginning this thread don't help, and setting up unofficial autobuilders when you can't work out how to get an official one accepted are seriously counterproductive. I would greatly appreciate it if people would help the process by supporting the efforts of the DSA team consistently rather than heaping praise on them when they fix compromises and scorn on them the rest of the time. It would also be helpful if there were people who are able to commit time to do significant but boring tasks to help DSA, expecting neither praise, acknowledgement or, most importantly, any additional rights/priveleges in return. If that's you please mail me privately, probably at [EMAIL PROTECTED] Cheers, aj signature.asc Description: Digital signature
Re: Please appoint one new person to the DSA Team
On Wed, Dec 20, 2006 at 10:43:48PM -0800, Mike Bird wrote: 4) What kind of Debian Project unprivileged admin tasks are so secret that discussion thereof must occur in private? The issue isn't that secrecy is required; just that discussing these things in public on Debian fora turns into a grandstanding exercise or a lot of bikeshedding, neither of which help resolve the initial concern. Technically, fixing security vulnerabilities in packages used by on d.o machines is an answer to your question. There's been some discussion recently about help potentially being wanted on that score for etch backports. Cheers, aj signature.asc Description: Digital signature
Re: Please appoint one new person to the DSA Team
On Thu, Dec 21, 2006 at 04:06:56PM +1000, Anthony Towns wrote: I would greatly appreciate it if people would help the process by supporting the efforts of the DSA team consistently rather than heaping praise on them when they fix compromises and scorn on them the rest of the time. It would also be helpful if there were people who are able to commit time to do significant but boring tasks to help DSA, expecting neither praise, acknowledgement or, most importantly, any additional rights/priveleges in return. If that's you please mail me privately, probably at [EMAIL PROTECTED] Oh, given the no rights/priveleges part, that's probably applicable to non-DDs too, if there are any reading who are interested. If that's you, please also provide a gpg key id, and some evidence that you're a real person, not a pseudonymous committee of AIs at Microsoft Labs or whatever, if possible. :) Cheers, aj signature.asc Description: Digital signature
Re: Debian Etch Stable.
On Thu, Dec 14, 2006 at 03:32:16PM +1000, Anthony Towns wrote: On Wed, Dec 13, 2006 at 01:24:32PM +, MJ Ray wrote: Actually, I believe you'll find that that wasn't even put forward as a metric for the experiment. In your own words, the experiment was to allocate sufficient funds so that Steve Langasek and Andreas Barth can dedicate a month each to getting etch out on time (and Mon 4 Dec 06 was already given as the release date). If you consider that to be the success condition, it seems it was already a success -- that amount of funds was allocated, for exactly that purpose. I've said a few times in this discussion things like as long as you learn something, an experiment isn't a failure. If you combine that with the fact that when you learn something you do things differently, that's equivalent to saying that if the experiment needs to be repeated, it's a failure, and if it's a success, it doesn't need to be repeated. I'm going to continue avoiding trying to draw any conclusions about the effect on Debian while the release is still pending, but at the very least there's been a few things learnt: - Debian shouldn't do funding of Debian work for various reasons, that add up to it not having the support of the developer body - there's no need to do funding through Debian/SPI -- it's possible to raise decent amounts of money for Debian work in short amounts of time - lots of people don't like key Debian people to be involved in funding Debian things, due to potential or actual confusion and other potential or actual conflicts of interest - some people don't like paying people at all and would rather that not affect their hobby - some people actively disendorse/disclaim the goal of releasing on a set date, even as subordinated to when it's ready A number of those were found out during discussion on -private, and Dunc-Tank aimed to address them as best it could; posts to this list and elsewhere demonstrate that any future projects should be able to do a better job of that IMO. I'm pretty sure there're other lessons that could be drawn out of a better understanding of the objections related to how the task was selected and whatever too. No doubt some of these conclusions were obvious to some people before this was ever raised; unfortunately not everyone's that well informed. So as far as I can see, questions like Has the experiment failed now? Will it be repeated? [0] are related in the opposite way to what people are assuming -- yes, things were learnt, therefore no it hasn't failed, and no, the experiment doesn't need to be repeated [1]. I presume the real question is whether anyone gets funded to do Debian stuff in the future. But ultimately I don't get /any/ say in that -- it's totally up to the people who are actually going to do the funding. If you're against this sort of thing, it's not me you've got to convince of the evils of funding or the superiority of other ways of doing this; it's all the people who can afford to fund Debian-related activities, and have the desire to do so. Because in the end, they'll do whatever they want with their money, no matter whether you, or I, or Debian thinks it's good or bad, or whether we dance for joy, or sulk and swear. (As an aside, one question that has been at the back of my mind following some of the more intense opposition is just how easy it might be to disrupt Debian by applying small amounts of money -- either to recruit developers to work on other projects, or just to create arguments that distract people from doing work (ie, trolling). If it's really possible to repeatedly disrupt Debian with just $12,000, eg, I'd imagine Microsoft would be happy to do that in a heartbeat if they ever started feeling threatened by us. Again, I don't want to judge things 'til etch is out, but my initial impression is that in spite of the flamewars and claims of demotivation, the primary negative effect has been an increased focus on quality assurance (in support of the widely recognised goal of making the next stable release as reliable and well-tested as possible), at the expense of releasing on the 4th (which was a less expected goal, and less widely recognised amongst developers). If that's actually the case, that's a fine kick in the pants to me or Dunc-Tank supporters or whatever, but at the same time it's a good demonstration that Debian's willing and able to keep its own priorities in the event of monetary interference) Cheers, aj [0] http://www.infodrom.org/~joey/log/?200612190920 [1] ...at least if you're not trying to get published in an academic review and have to demonstrate repeatability under laboratory conditions or similar. signature.asc Description: Digital signature
Re: Debian Etch Stable.
On Thu, Dec 14, 2006 at 08:40:41AM +0100, Sven Luther wrote: I would further expect that you didn't try to pollute the experiment result with stuff like the mail starting this thread. From the tone of that mail, it indicated clearly that for you the experiment was over, and that you called for experiment oponents to be remotivated for that. Sorry, but again, this cannot happen until the final report is there, and your mail was all but a good idea. Dunc-Tank's activities for the etch release are almost over, aside from some logistical things that still need to be completed. If you're worried about people being payed to do work, and not doing it because you're not being paid, well, that's ceasing very shortly. If it's the concept of an experiment at all that bothers you -- ie, doing something that some people (including yourself) don't agree with, that might not work, that's controversial, that hasn't been 100% thought out and proven to be correct and already tried elsewhere -- well, it's fair enough that you should continue being upset. Though I think you'll have trouble finding somewhere in free software that people are that conservative that you won't continue getting upset. Personally, if you're already upset by things I've said or done, I wouldn't recommend you rely on any report I might work on to make you feel that much better. :-/ Cheers, aj signature.asc Description: Digital signature
Re: Debian Etch Stable.
On Wed, Dec 13, 2006 at 01:00:38PM +0100, Marc Haber wrote: As far as I remember, the experiment has two steps, paying Steve for a month and paying Andi for a month. Steve's month is already over, and Andi is like in his third week. So - again - as far as I remember there is only one week of experiment left in _any_ case so it does not make too much sense talking about continuing or not. It's over soon anyway. If I'm wrong, please correct me. You're not. There's still logistical issues (getting the money to Steve and Andi, dealing with taxes and whatnot -- they haven't been paid in advance) that have to be sorted out but they're entirely a matter for the Dunc board to deal with. Personally, I don't consider the experiment over 'til all those loose ends are tied up; and it could easily turn out that the logistical issues alone are enough of a problem to make this sort of endeavour not worth the effort. Cheers, aj signature.asc Description: Digital signature
Re: Debian Etch Stable.
On Wed, Dec 13, 2006 at 01:24:32PM +, MJ Ray wrote: Actually, I believe you'll find that that wasn't even put forward as a metric for the experiment. In your own words, the experiment was to allocate sufficient funds so that Steve Langasek and Andreas Barth can dedicate a month each to getting etch out on time (and Mon 4 Dec 06 was already given as the release date). If you consider that to be the success condition, it seems it was already a success -- that amount of funds was allocated, for exactly that purpose. I think the experiment has even failed to provide useful information it could have, partly due to the refusal to take or request any recognisable measurements. Any future DPL funding initiative could be [...] Given this isn't a DPL funding initiative, I think you're way off base. Further, it's cynical and unrealistic to demand that those unhappy with the experiment to fulfil the DPL's wishlist at this busiest time of year for festivals and so on. [...] You are, of course, free to do what you want, and you don't need to come up with any excuses for that. I hope that reporters are smart enough to recognise both that demand and the refusal to report yet as the politicking of a DPL trying to hide the negatives of his decisions. If this were politicking, what makes you think that I'm not suggesting the very thing I'm worried most about, safe in the knowledge that yourself and others will say oh, if aj suggested it, it must be an evil, political idea and I shall do the exact opposite? Cheers, aj signature.asc Description: Digital signature
Re: Debian Etch Stable.
On Wed, Dec 13, 2006 at 02:17:35PM +0100, Sven Luther wrote: [...] Personally, I don't consider the experiment over 'til all those loose ends are tied up; and it could easily turn out that the logistical issues alone are enough of a problem to make this sort of endeavour not worth the effort. What about the analysis and resulting conclusion, report, whatever of this experiment ? I wouldn't expect those to be started until the experiment is over. Cheers, aj signature.asc Description: Digital signature
Re: Debian Etch Stable.
On Tue, Dec 12, 2006 at 09:56:33AM +, MJ Ray wrote: In the context of an experiment to find out whether paying people to do Debian work can be useful, it'd certainly provide some useful information as to whether there are better alternatives for encouraging contributions and getting things done. The release was the only metric put forward for the experiment, despite various requests. Actually, I believe you'll find that that wasn't even put forward as a metric for the experiment. As per [0], it wasn't even the primary goal of the payments. One of the major arguments against changing the rules of the game is that paying some people and not paying others will discourage (some of) the people who don't get paid from contributing. When people are reviewing this experiment and working out whether to try similar things in the future, whether within Debian or elsewhere, I'd expect one of the things they'll consider is whether the people who claim to be demotivated now were really going to contribute much more otherwise. This is, IMO, a fairly unique opportunity to demonstrate just how much contribution is being lost due to jealousy or unfairness or whathaveyou. Obviously, there's no requirement for anyone to take advantage of that opportunity, but if I thought paying people was a bad idea even in principle, I'd be making the most of this opportunity to prove that I was right. Actions speak louder than words and all that. Cheers, aj [0] http://lists.debian.org/debian-devel-announce/2006/10/msg00027.html signature.asc Description: Digital signature
Re: Debian Etch Stable.
On Tue, Dec 12, 2006 at 12:11:07PM +0100, Sam Hocevar wrote: It looks to me that you are now asking others to set up the experimental protocol you failed to deliver when the experiment was being discussed. As of now, anything that might happen can be reused for a Dunc-Tank PR explaining how much the experiment helped. As far as any hypothetical PR is concerned, vocal critics of the Dunc-Tank procedure declined to contribute any effort to getting the release out sooner, even to demonstrate how effective Debian can be in the absence of paid work seems like it would be entirely sufficient. I don't really see the point of caring about PR for Dunc-Tank though -- from Debian's POV it's a separate project, so it can say what it likes and if it lies to the press it'll pay the price soon enough, and from Dunc-Tank's POV, it needs to fulfill its various obligations -- eg, a thorough post-etch report on what happened -- before it even starts thinking about promoting itself to do new things in the future. But if it turns out there really is a huge cost to paying people, it seems to me like it'd be a lot easier to do a PR saying this is what development looks like with money, this is what community development looks like without money with the latter being obviously a lot more effective than the former. And you already know exactly how effective the former is in this case, so you just have to beat that. Nowhere have I seen an official statement, explicit or implied, that Dunc-Tank will be a failure if XYZ happens, hence I fail to see how the so-called anti-payment people could be motivated to do anything yet. Please correct me if such a statement exists. As an experiment, the only way it can be a failure is if it doesn't teach us anything, and personally I think there's already plenty to be learnt from this, so I don't think that's a question. As to whether anything similar should be done in future, I'm going to continue to reserve judgement on that until etch is out, and there's a chance to consider the exercise in its entirety, with all the results in. You're not in any way obligated to do the same, of course. To be clear: I'm well aware that there are a number of people who don't agree or approve of the Dunc-Tank project -- whether in concept or merely in execution -- who are working on getting the release out at our usual quality as soon as possible in spite of that difference of opinion. There's nothing wrong with that, and I'm not suggesting that they need to put it any more effort than they otherwise might for their opinion to matter. But there are at least some people who are specifically contributing less, whether as a deliberate protest against payments, or simply because the project's doing things that don't interest them as much as it might otherwise. This is a chance to turn that around, take the momentum from the Dunc-Tank project and put it towards not only helping Debian, but convincing other developers and free software hackers that free, voluntary contributions are vastly better than even trying to pay people. And hey, maybe it won't work first go, but so what? Anyone who's going to look beyond didn't make 4th Dec release for Dunc-Tank will surely do the same for an unpaid endeavour, if the people undertaking it are serious about it. Cheers, aj signature.asc Description: Digital signature
