Re: GR: welcome non-packaging contributors as Debian project members
Hi, Stefano Zacchiroli lea...@debian.org writes: --- The Debian project aims at producing the best free operating system. To that end the project benefits from various types of contributions, including but not limited to: package maintenance, translations, infrastructure and website maintenance, porting, bug triaging and fixing, management activities, communication, testing, legal advice, quality assurance, etc. The Debian project acknowledges that: * To pursue Debian goals, package maintenance as well as a wide range of other technical and non-technical contributions are all valuable. * Active contributors of non-packaging work, which share Debian values and are ready to uphold Debian Foundation Documents, deserve the opportunity for becoming Debian project members. The Debian project therefore invites the Debian Account Managers to: * Endorse the idea that contributors of non-packaging work might become Debian Developers without upload rights to the Debian archive. These new developers shall be recognized as Debian Contributors (DC). * Establish procedures to evaluate and accept Debian Contributors. * Initiate the appropriate technical measures to enable Debian Contributors to participate in Debian decision making and to access Debian infrastructure. --- Seconded. Thanks for finally pushing this to a GR. Marc -- BOFH #429: Temporal anomaly pgph5tGMdtUjV.pgp Description: PGP signature
Re: Question about membership.
Charles Plessy ple...@debian.org writes: In this thread it was proposed to trust DDs to nominate other members and I found the idea very interesting. In order to make it more consensual, there is probably a need for making concessions like shortlisting the trusted DDs according to some criteria like the time they have already spent in the project. I would actually be tempted to propose a more variable but more symbolic measurment of time: having been part of the project for at least one full release cycle. I don't see why someone who joined the project a few months ago should be trusted less than someone that got in, for example, before we had any formal checking of new members. This idea just doesn't work. Marc -- BOFH #198: Post-it Note Sludge leaked into the monitor. pgp9Xipk3outH.pgp Description: PGP signature
Re: No answer for insulting and accusatory emails.
Charles Plessy ple...@debian.org writes: just for the record, I will not answer to insulting or accusatory emails. Some of them may contain interesting questions or comments, though. Please feel free to repeat them in a separate message if you also found them interesting. OK, so I do have a few followup questions: (1) What do you consider to be insulting or accusatory? (2) As example: Will you, as DPL, consider You haven't answered in the past four weeks as accusatory? (3) How will we, as DDs, know if you consider something as insuluting or accusatory? (4) Do you believe ignoring conflicts to be a solution? Marc -- BOFH #408: Computers under water due to SYN flooding. pgpcnaicNKrUm.pgp Description: PGP signature
Re: Bits from the release team and request for discussion
Manoj Srivastava sriva...@debian.org writes: On Tue, Aug 11 2009, Gunnar Wolf wrote: I basically oppose such a GR, as it is is merely speculative (who knows _now_ or at the GR voting time when we will be close to achieving our release goals?), and because it is a ruling on a technical subject (at least according to some metrics). But if the vote were to be held at all, I would add: 6. The Debian project recognizes the responsible team to take any decisions regarding the freeze date and reach to be the Release Team, and accepts their best judgement in this regard. Perhaps you should look at this less confrontationally. The vote is a non-binding recommendation, it is an information gathering vote where people provide feedback to the release team; by voting for the option that best suits their development plans. While I can't really disagree with this, I don't think a GR will actually provide all the needed information. In a GR, quite a few people will prefer one option over the other for reasons that have nothing to do with the feasibility or quality of a freeze at a given point [1]. I believe answers to a short questionnaire (what will be released when? should it be in squeeze) would help a lot more, and thus I'm currently working with the rest of the release team to send such mails. At this point, I would like to once again apologize for the less than optimal handling of communication between the release team and the rest of the project in the past month. [2] The last weeks were shaped by discussions that would have been unneeded if we had explained proposals in a better way (and marked them more clearly as proposals) and avoided some (now obvious) mistakes. Marc Footnotes: [1] As example, people who know that they have a few thousand machines running lenny will probably prefer a later date, so that they don't need to do mass dist-upgrades after just 30 months. [2] Please note that this statement is not a coordinated release team statement, but an expression of my personal feelings. pgpCcwup5wpgI.pgp Description: PGP signature
Re: call for seconds: on firmware
Robert Millan [EMAIL PROTECTED] writes: On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). When you say chooses a certain interpretation, are you referring to the one in which SC #4 is interpreted in a way that cannot be complied with no matter what, only to use this impossibility as proof that SC #4 and SC #1 contradict each other, and in turn resolving that because the SC is inconsistent, SC #1 is meant to be read figuratively? I discussed this with Andi in the past, so let me answer: From our point of view, SC#4 is relatively clear: Our users need to be able to use a stable release of Debian and the free software community (not free software!) needs us to spread the use of _free_ software. Driving off people to another distribution because we have found yet another sequence of magic numbers that might, or might not, have source code somewhere is a clear violation of SC#4 in our eyes. This is also the reason why I am unhappy about the 3:1/1:1 discussion: From my point of view, releasing with possibly sourceless firmware blobs is what the SC asks us to do, so these options should be 1:1. Not doing that would violate it, so those options should require a 3:1 majority. Now, other people, including our secretary, have quite a different opinion. The problem here is that the secretary's opinion is actually more important than mine, because Manoj can decide the majority requirements. And that sucks - not because Manoj doesn't share my opinion, but because his opinion has a bigger influence on the outcome of this than mine. I think we discussed this before [1]. In any case, if you think the SC is so badly broken, you should be ammending the text to disambiguigate it, like we did in GR 2004 / 003, or even in GR 2003 / 003. What, more editorial changes? This is going to be a lot of fun. Marc -- BOFH #333: A plumber is needed, the network drain is clogged pgp11AqMYJkIz.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
Robert Millan [EMAIL PROTECTED] writes: or that we help our users by moving the Linux kernel plus the installer out of main, How is shipping packages in non-free instead of main supposed to be against the interests of our users? You seem to forget that non-free is not a part of Debian. Technically, you are right - moving the Kernel to non-free wouldn't be against the interest of our users. Debian wouldn't have any users anymore, so their interests couldn't be violated. It's a great idea: Stopping a (felt) steady decline of Debian with a big bang. Yay. Marc -- BOFH #333: A plumber is needed, the network drain is clogged pgpr9u2Ix9OGL.pgp Description: PGP signature
Re: Call for seconds - DC concept
Peter Palfrader [EMAIL PROTECTED] writes: I hereby propose this alternate option/amendment and am asking for seconds. | The Debian Project recognizes that many contributors to the project are not | working withing established frameworks of Debian and thus are not provided by | the project with as much help as might be possible, useful or required, nor | opportunities to join the project. | | We thank Joerg Jaspert for exploring ideas on how to involve contributors more | closely with and within the project so that they can get both recognition and | the necessary tools to do their work. | | We realize that the proposal posted to the debian-devel-announce mailinglist is | not yet finalized and may not have the support of a large part of our | community. We invite the DAM and all the contributors to further develop their | ideas in close coordination with other members of the project, and to present a | new and improved proposal on the project's mailinglists in the future. | | Significant changes should only be implemented after consensus within | the project at large has been reached, or when decided by a general | resolution. Seconded. Marc -- Fachbegriffe der Informatik - Einfach erklärt 46: Schulversion legalisierte Raubkopie (Kristian Köhntopp) pgp2YPc6lbDqa.pgp Description: PGP signature
Re: [DRAFT] resolving DFSG violations
Robert Millan [EMAIL PROTECTED] writes: Option 1 (set an upper limit) ~ [move stuff to non-free after some time] I believe this to be a bad idea. Would we enforce this at the moment, Debian main would be empty, as glibc (and consequently, all of it's r-build-deps) would need to go to non-free. We would probably not do it, even if it is required by this GR - creating the first of a probably long line of exceptions. Re-affirming the Social Contract (or actually changing it) in this way thus seems to be fundamentally dishonest, as we are not actually willing to use this rule in all cases. [1] Even if, magically, the DFSG violations in core packages would just be fixed (after being known for a few years) I firmly believe that such a strict rule would hurt the cause of free software. Yeah, flame on, but read my rational before doing so. Most DFSG violations have been fixed quite fast in the past. If such an issue stays open for a longer time (for example, more than 60 days), usually one of the following three option applies: (a) Noone cares because the package simply isn't in use. (b) People care, a clarification from upstream would be enough, but that takes a lot of time. (c) People care, code needs to be rewritten or data needs to be regenerated, but there is nobody available who's both interested and able to do so. We solve (a) with a simple removal from the archive, so a move to non-free wouldn't actually happen. If we are in case (b) or (c), we would need to move the package to non-free. The biggest example would be texlive, I think. So, what do you think what happens when we move texlive to non-free? [2] I think people using tex either switch to another distribution or add non-free to their sources.list. This will not help to put free software on more machines, it will actually make it harder to do so. Anyway, I do not think that this discussion will lead to a useful result. We are seeing two fundamentally different beliefs here - I believe that Debian has to stay relevant and useful to make it possible to distribute a completely free universal operating system in the future. From what I can gather from your mails, it seems to me that you would prefer to distribute a completely free operating system now, even if this means that quite a few users will switch to something different. Yes, this description is biased and I know it, but I don't claim to be objective. Perhaps I'm wrong to believe that Debian is about bringing free software to users. Perhaps it's just about free software and users actually don't matter when there's a higher goal. Marc Footnotes: [1] At this point, I assume that moving all packages to non-free is not something people would actually consider. If you do feel that it's a viable option ... Well, then we have nothing to discuss and nothing to agree on, so let's just vote. [2] Let's just ignore all the (build-)r-deps... -- BOFH #336: the xy axis in the trackball is coordinated with the summer soltice pgpxZErScK6fa.pgp Description: PGP signature
Re: Proposal - Project infrastructure team procedures
Josip Rodin [EMAIL PROTECTED] writes: [DPLs] Because by default we elect nice people, who avoid stepping on people's toes. What, like Overfiend? Marc -- BOFH #69: knot in cables caused data stream to become twisted and kinked pgpNgu2i9Q8TH.pgp Description: PGP signature
Re: Q: Marc Brockschmidt: tight-knitted groups of friends
Raphael Hertzog [EMAIL PROTECTED] writes: On Thu, 13 Mar 2008, Marc 'HE' Brockschmidt wrote: OTOH, experience shows that enforced addition of new members doesn't work as one would expect. What case are you referring to? I don't think it ever happened up to now. Constant pressure from the outside lead to interesting constructs such as ftp-assistants and an account manager without actual permissions to manage accounts. I agree however that we have to go further and that the assistant status must not become the end of the road for the members who have shown that they can do more and they want to do more. There are no rules describing when an assistant (or however they are called) should get full permissions. In fact, this simply hasn't happened yet in teams that have been problematic in past. Marc -- BOFH #281: The co-locator cannot verify the frame-relay gateway to the ISDN server. pgppB8eia3Ff0.pgp Description: PGP signature
Re: Question for all candidates: Handling declassification of debian-private (GR 2005-02)
Steve McIntyre [EMAIL PROTECTED] writes: On Wed, Mar 12, 2008 at 03:21:23PM +0100, Raphael Hertzog wrote: On Tue, 11 Mar 2008, Fabian Fagerholm wrote: If you were elected DPL for the next term, what would you do about this GR and when? How would you ensure that the declassification can happen in a timely manner and fulfil all the requirements? What would your declassification team look like -- how many members would it have, how would they be selected and would you impose any structure among them? I would _not_ organize this myself. The DD who are interested in declassification of those mails should come up with a proposition and I'll gladly bless them (if it doesn't contain anything objectionable - that said I don't see what could go wrong). Without wishing to just add aol here, I think Raphael and I are in broad agreement. I'm not going to treat the declassification effort as a personal priority, but I'd love to hear from people who would like to get involved. If I can help them get the job done (resource allocation, delegation, etc.) then so much the better. For the sake of completness: I would need to put a ME TOO 1 here. The declassification of -private mail will involve big amounts of manual work. The DPL can't force people to do so, so we just need to wait for someone to come forward interested in doing this and then provide as much help as possible. Marc -- BOFH #55: Plumber mistook routing panel for decorative wall fixture pgpmDQwQZ2Jgq.pgp Description: PGP signature
Re: Q: Marc Brockschmidt: tight-knitted groups of friends
Clint Adams [EMAIL PROTECTED] writes: Your platform contains the following claim: This can hardly be solved from the outside - but a start would be to not defame these groups as evil cabals hindering the rest of the project out of spite. Why can this not be solved from the outside? One possible way out of this is replacing the whole team, but the entailed pain in the transition period and the loss of experience is usually too big to make complete replacement a viable option. OTOH, experience shows that enforced addition of new members doesn't work as one would expect. The usual pattern is that old members end up in a closed circle of masters, while the new members get to help as assistants, ensuring that the additional help can't actually help with all tasks. As we are working with volunteers here, there's no real way to enforce a change in this pattern, so the only option left is constant constructive criticism with an emphasis on the fact that letting new people in could solve most issues. Flaming usually just wastes everyones time and only makes the involved parties resent changes more than before. Marc -- BOFH #288: Hard drive sleeping. Let it wake up on it's own... pgp8CVuEGiESi.pgp Description: PGP signature
Re: All DPL Candidates: www.debian.org licensing?
MJ Ray [EMAIL PROTECTED] writes: Will you delegate someone to resolve bugs.debian.org/238245 and bugs.debian.org/388141 at long last? That is, get www.debian.org to follow the DFSG and to display better copyright statements. In particular, delegation seems necessary to avoid bureaucratic blocks to getting impartial legal advice. I think www.debian.org needs to be worked on anyway (as I've written in my platform). In the course of reviewing our web pages and reworking parts, licensing issues should be reviewed as well. After an initial review of the current state of www.debian.org, I would like to see some facts about our web pages (especially how much content was generated by people who are not reachable any more). After that, we should be able to list specific examples for all different problems that could be in need of legal advice, which should be requested at that point. Marc -- BOFH #180: ether leak pgp3aRimYUSVD.pgp Description: PGP signature
Re: Question for all candidates: inter-dependancy of works the growing Debian project.
Charles Plessy [EMAIL PROTECTED] writes: Debian is growing bigger everyday. I would like to know if you think that it should adapt to its new size, and if yes, how can you help this process as a DPL. Debian has steadily grown in the past few years, at least in respect to the number of packages. On the other hand, from a QA point of view, it sure looks like the amount of work spent on Debian hasn't grown as much, leading to a lower overall packages quality. There is not much a DPL can do about this, besides starting discussions about various aspects of this development. One of the things I would like to discuss (and implement at some point) are stricter rules for the removal of packages - not because I want to remove fewer packages than we do at this moment, but because I believe we should kick out *more* packages. This is easier to do when you don't need to decide on new rules on a case-by-case basis, but have fixed rules that can be applied for each problematic package. In particular, I would like to know what you think about how the work of each DDs and teams are tied, and if the ties should get stronger or looser. Debian offers a lot of features, in particular security support, stable releases, and portage on multiple architectures. I guess this question has something to do with your recent problems with the MIPS architecture and your packages [1] While I understand your concerns as package maintainer about packages being blocked from migrating to testing, I value the efforts to port Debian to a bigger set of architectures. Knowingly breaking packages on some architectures is something I don't like, as it moves important issues for the release to the end of the release cycle. Back to your actual question, which was more general: Our package maintainers, porter, release and QA teams need to work together closely to make Debian as it is possible. I firmly believe that trying to remove these dependencies can only end up in a worse Debian. One of the main advantages Debian has over other distributions is the close integration of a big number of packages on quite a few architectures. Installing Debian on a s390 is as easy as installing it on your laptop or the MIPS-based router at home - in all cases, you can expect the same quality and using the system feels similar (well, apart from speed limitations). This is only possible due to the relatively tight integration we are enforcing at the moment. Marc Footnotes: [1] [EMAIL PROTECTED] and [EMAIL PROTECTED] -- BOFH #212: Of course it doesn't work. We've performed a software upgrade. pgpEJkiysFXlq.pgp Description: PGP signature
Re: Marc: So, is any of the other candidates above 'NOTA' for you?
Gunnar Wolf [EMAIL PROTECTED] writes: Nominations are over. It's you, Raphaël and Steve. So... I think your opinion here is fundamental: Are you still running? Yes. What is your stand on them (well, yes, I know we don't yet have Steve's platform, and that'll be a fundamental point for your answers - but still, consider this question as formulated as soon as you can comment on it). I expect Steve's platform to be as sane as always, so I'm answering this question now, before reading it. I think both Raphael and Steve could do the DPL job well, but I have my reasons to believe neither of them to do things the same way as I would do them and that's why I haven't left the field to them. Marc -- Fachbegriffe der Informatik - Einfach erklärt 99: EDV Experimentelle Daten Verarbeitung (Andreas Frackowiak) pgpAoJggHFCm8.pgp Description: PGP signature
Re: All Candidates: Do you plan to be prominently visible during your term?
Marc Haber [EMAIL PROTECTED] writes: What is your plan to ensure your ongoing visibility during your term? Do you plan to post regular bits from the DPL, Regular reports to the project are planned, not only about DPL activities, but about anything that is going on in the project and wasn't announced on debian-(devel-)announce. and which measures will you implement to prevent a failure similiar to the failures of your predecessors? Asking for help when it is needed, delegating work to people who are experts on a specific field, report problems (even lack of time) when they become a blocker. Marc -- BOFH #399: We are a 100% Microsoft Shop. pgpSa2j3hbTJg.pgp Description: PGP signature
Debian Project Leader Elections 2008: Marc Brockschmidt
Dear Debian, .:%%%:. .:%%%:. .%'''%. .%'''%. .%::' ':::%:::' '::%. %::. Roses are red, .::% %::. Violets are purple, .::% '%:: It is today time I said ::%' '%:. I candidate for DPL!.:%' '%:. .:%' '%:::. .:::%' '%:::. .:::%' '%::.::%' '%' [stolen from [EMAIL PROTECTED]] I would like to point out that I had already resolved not to run for DPL this time due to the small amount of free time available to me in the next year. I will *not* make being DPL my top priority in the next year, real life issues (finishing my studies, most notably) are more important to me. Electing me as DPL will also reduce the time I can spend on release tasks, new maintainer stuff and package maintainance. If you can't decide between me an another candidate who is more committed, rank me lower on your ballot. Love, Marc pgpOdV5cyV3EV.pgp Description: PGP signature
Re: Debian Project Leader Elections 2008: Marc Brockschmidt
Bas Wijnen [EMAIL PROTECTED] writes: On Wed, Mar 05, 2008 at 11:40:11AM +0100, Marc 'HE' Brockschmidt wrote: I would like to point out that I had already resolved not to run for DPL this time due to the small amount of free time available to me in the next year. I will *not* make being DPL my top priority in the next year, real life issues (finishing my studies, most notably) are more important to me. Electing me as DPL will also reduce the time I can spend on release tasks, new maintainer stuff and package maintainance. While I see you have good reasons not to run, you still candidate yourself. I'm interested to know why. :-) I think that having someone I more or less trust as DPL, even if he has not enough time to do all that he wants to do, is better than the confusion when no-one candidates. Also, I fear a bit that if noone candidates, someone I wouldn't like as DPL [1] might throw their hat in the ring 5 minutes before the nomination period ends, ending up as the only choice next to NOTA on the ballot. Marc Footnotes: [1] No, I don't have a list of such people -- BOFH #127: Sticky bits on disk. pgpcg7J92rk8S.pgp Description: PGP signature
Re: Debian Project Leader Elections 2008: Marc Brockschmidt
Lucas Nussbaum [EMAIL PROTECTED] writes: On 05/03/08 at 13:49 +0100, Marc 'HE' Brockschmidt wrote: Also, I fear a bit that if noone candidates, someone I wouldn't like as DPL [1] might throw their hat in the ring 5 minutes before the nomination period ends, ending up as the only choice next to NOTA on the ballot. Constitution for the Debian Project (v1.3) [...] 5. Project Leader [...] 5.2. Appointment [...] 6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. So, nothing too dramatic if what you feared had happened. That I consider someone not to be a good candidate for DPL doesn't mean they won't be ranked over NOTA by a majority of people. Also, the classic answer to I don't have enough time is delegate. Are you planning, if elected, to create some sort of DPL team? Don't you think that it will allow you to be a good enough DPL despite your lack of free time? Yes. As I've written in my platform [1], I would like to delegate one area of the DPL's tasks to other people: Presenting Debian to the rest of the world, for example at conferences. My schedule allows for many small time slots to be used for Debian activities, but it's quite hard to free up a few days to go somewhere, hold a talk and speak with people. As I believe this to be important, the delegation of this task is one of the things I have planned. For the rest of the DPL's tasks, I haven't made a decision yet: Doing all the work alone doesn't seem to be a good idea, but I have to admit that I can hardly describe areas of authority that can (and should) be delegated. On the other hand, I don't see a problem with solving this dynamically, asking people for help whenever I notice a problem coming up. In my platform, various goals touch the issue of collecting and distributing information. In the past, my release team work has often included similar tasks, which I have usually solved by finding people who are experts on a certain area and thus could give me the needed information easily. I plan on doing something similar as DPL. The same question can be asked as will you be our DPL team candidate, or are we still looking for someone to fill that role? I have contacted a few people about helping out with the tasks above (and some I plan to contact) but I can't hand out a definite list of people who are willing to help me at this time. Marc Footnotes: [1] Soon to appear on vote.debian.org, for now on http://ftwca.de/dpl-platform.html -- Fachbegriffe der Informatik - Einfach erklärt 72: Repost Kristian K=F6hntopp (Sebastian Kokemohr-Schmidt) pgp9umbVuILB3.pgp Description: PGP signature
Re: The Debian Maintainers GR
Steve Langasek [EMAIL PROTECTED] writes: On Wed, Aug 01, 2007 at 10:44:00AM +0200, Marc 'HE' Brockschmidt wrote: Anyway, now Rperl-lover can upload the package on his own, but as a pure perl robot, he is bound to fuck up. After a year, *you* will need to kick him to understand how SONAMEs work :) And yet I'm speaking in favor of the proposal, yes? The only reasonable explanation is that you like to kick maintainers :-P Getting folks to understand how SONAMEs work is such a high bar that I don't think it should be a requirement even for DDs, let alone DMs. Well, i was desperately searching for something that you encounter on a regular basis. In reality, you are right - if we would only allow people who understand all technical details to be DDs, the project would be a lot smaller. And have different problems. But there are a lot of basic issues that lead to problems on a regular basis, some of which every maintainer should know about. Instead, my interest is in improving our toolset so that it can do the work for me of letting maintainers know, ASAP, when they've done something wrong with a library. :) Besides the fact that I have always been favor of a mandatory remote stabbing device (if possible directly connected to some QA system), I'm not saying that we should try to solve our quality problems by allowing only perfect packages to be uploaded, but that we should discuss which and how many mistakes we can identify after an upload and what the average input quality should be. (For one thing, consider that this proposal wouldn't let a DM change library or dev package names for a transition on their own, so there would have to be a DD involved as well in the case of a wrongly-renamed package.) Heh, that's not a good example. The usual mistake is to *not* change the package names when breaking the interface. My whole argument boils down to I don't trust DDs. I would be happy to vote in favour of this proposal if the list of packages each DM can upload is controlled by a small group of people (the DM keyring maintainers) and not a group of ~1000 people. I don't trust DDs either; I trust the system, because it's essentially the same system we've used all this time for creating the best Linux distro around, with just a few parameters tweaked. The problems I fear stem from the fact that the DM proposal *changes* the system we are used to. The advantage of having Debian Maintainers is that they don't need to go through a sponsor every time, in other words reducing the time that needs to be spent by all involved people on a single upload. I don't believe that all of the time saved is spent on quality checks that we will miss in the future, but a part is. That *will* have an effect, the only question is how big the change actually is. Marc -- BOFH #379: We've picked COBOL as the language of choice. pgpgipprcEZDz.pgp Description: PGP signature
Re: The Debian Maintainers GR
Steve Langasek [EMAIL PROTECTED] writes: On Mon, Jul 30, 2007 at 10:36:46AM +0200, Marc 'HE' Brockschmidt wrote: ... without ever *asking* if that would be true. I assumed this idea to be dead because last year's discussion on -newmaint showed that most DDs were against that proposal. Surely, discussion on -newmaint and most DDs are contradictory? :) I think it was crossposted to -project. At least a lot of non-NM people were part of the discussion. (i) You have added a policy for everything, but removal from the DM list is still under-defined. This is a crappy idea. Imagine a Sven Luther case in DM - someone who's technically capable and invests a lot of time, but leads to regular flamewars. There is no question that we would need to have some procedure to decide what should happen in such cases. Are you aware that one of the crimes Sven says Debian has committed against him is that the DAMs didn't follow their own procedure for expelling developers? Yes. I think it's rather silly to accuse the DAMs of wrongdoing given that the procedure in question was the documented procedure by which a developer could *request* an expulsion, and this in no way binds the DAMs to not act of their own accord as they think appropriate; but I think it puts the lie to the claim that defining expulsion procedures in advance is a necessary (or sufficient) safeguard against flamewars... Now, back to the Sven Luther example: Imagine how *that* flamewar would look if the procedure to kick him out would have been hand-crafted just for his case? I don't think that calls for much imagination at all, I think the flamewar would looks about like the one we already had... Well, the problem with the Sven Luther example is that the procedure actually wasn't followed by the letter, but used as a, eh, guideline. I don't think it was wrong to expelulse [1] Sven, but if you *know* that you face the danger of being accused of doing something solely for personal reasons, you should IMO try to stick to the letter of the rules. Of course, the DAMs are free to do do whatever they want with people's accounts, but starting with a procedure and ending the process by switching to one's absolute power over Debian accounts feels foul. So basically, I won't accept your proposal as remotely sane until the initial policy includes some guidelines on removals from the DM list. And is that something you're interested in helping to specify? I at least want to see some rules that describe who can ask for a removal from the keyring, how that should be done and (that's the most important thing for me) how the DM keyring maintainers, a *team*, should decide what to do with the request. (ii) Debian has a QA problem. Sponsorship did nothing to improve it. In fact, I believe sponsorship to be one of the reasons for it. Let's explain this a bit: Sponsorship is one of the main factors that lead to the explosion of the number of packages in the archive. The growth in the number of packages is, in fact, much bigger than the growth in the number of users. This means that the number of users per package has fallen [2], directly translating to the fact that packages receive less testing before they are released. This is equivalent to bugs and packaging mistakes staying unnoticed for a longer time. This problem is almost exclusive to packages that are priority: optional|extra, ie packages likely to be maintained by newcomers to Debian. This is a fair point, but I'm afraid that you haven't convinced me that adopting a more lightweight process for *maintaining* those packages *after* they've been uploaded (remembering that the proposal doesn't let DMs upload new packages autonomously) is going to increase the QA problems over the present case. It reduces the number of checks done on each package. The problem I see is when someone (let's say, Rperl-lover) maintains, say, some perl packages and gets his key in the DM keyring. After a year, he needs some C++ application and a library in the archive and wants to maintain it. Some developers sees Rperl-lover is already a DM, so assumes he knows what he is doing. There is a short package check, a sponsored upload to NEW with the DM-Upload-Whatever-it-was-called-field set to yes. For some reason, Joerg isn't doing an in-depth check of the package, or some other ftp-team member is working on NEW, the package goes on without much review. All in all, it's not too unlikely that this happens - and FWIW, I don't want to rely on the NEW queue for basic QA checks. Anyway, now Rperl-lover can upload the package on his own, but as a pure perl robot, he is bound to fuck up. After a year, *you* will need to kick him to understand how SONAMEs work :) My whole argument boils down to I don't trust DDs. I would be happy to vote in favour of this proposal if the list
Re: The Debian Maintainers GR
Anthony Towns [EMAIL PROTECTED] writes: On Mon, Jul 30, 2007 at 10:36:46AM +0200, Marc 'HE' Brockschmidt wrote: (ii) Debian has a QA problem. Sponsorship did nothing to improve it. In fact, I believe sponsorship to be one of the reasons for it. On that score, I agree. I would further say there are three main aspects to that: Thanks for taking the time to read, understand and reply to my explanation of what I feel to be the problem with sponsorship. I feel that you value my opinion. Especially the part were you completly ignore it shows off your amazing leadership skills. - sponsored maintainers are inhibited from fixing bugs they introduce; if their regular sponsor is missing or they don't have a regular sponsor, bugs will be left unfixed until they can find someone else -- in spite of someone being aware of the problem, ready with a fix, and wanting to upload it. You mean those myriads of bugs tagged pending, waiting for a sponsor to come along? People begging on -mentors to finally let them fix their bugs, as they weren't able to find a sponsor yet? - there's no tracking of sponsored maintainers, so it's possible for sponsored-maintainers to shop around for someone to sponsor their packages if they're uploading something someone rejects; when mummy says no, ask daddy, except multiplied by up to 1000 developers. Sure, giving those people direct upload privileges fixes the problem of nagging a thousand developers. Usually, the way to shut up children who want cookies is to give them a car, a hundred bucks and map with the way to the next supermarket marked, right? - it doesn't matter if the maintainer is good, only if the package is, so sponsorship doesn't promote skills that help avoid bugs being introduced so much as remove specific bugs that the sponsor manages to spot Whereas the DM keyring team has a magic wand turning white when a maintainer is good, so that they can give upload priviliges only to those people who are good? The proposal addresses all those things It doesn't. Please start coping with reality before fucking up Debian even more. [6] In fact, my original understanding of the whole idea was that a small set of DDs (like the proposed DM keyring maintainers) would check every package before a DM would be allowed to upload it on its own. I thought that to be something very, very positive, as it would ensure at least one thorough and proper check, instead of the current tradition of minimal checking done by sponsors. I don't think I've ever seen that interpretation before. You have. We discussed it. I certainly don't remember seeing it. That's probably why you didn't quote the relevant private IRC logs in one of your past mails. I don't think reviewing packages like that is something I'd like to do, personally. Right, reviewing packages is not really your kind of work. NEW certainly looks like you never do that. Marc -- BOFH #198: Post-it Note Sludge leaked into the monitor. pgp5rCPYmhNHE.pgp Description: PGP signature
Re: Constitutional amendment: reduce the length of DPL election process
Anthony Towns [EMAIL PROTECTED] writes:
=
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is None
Of The Above.
8. The Project Leader serves for one year from their election.
=
Seconded. This was overdue.
Marc
--
Fachbegriffe der Informatik - Einfach erklärt
31: Multimedia-Multitasking
CD-ROM mit Kopfhöreranschluß. (VOBIS Denkzettel)
pgpQXGqdnyzS7.pgp
Description: PGP signature
Re: The Debian Maintainers GR
Anthony Towns [EMAIL PROTECTED] writes: After that meeting [0], I'd assumed it was in Christoph and Marc's capable hands, ... without ever *asking* if that would be true. I assumed this idea to be dead because last year's discussion on -newmaint showed that most DDs were against that proposal. Some of them have had some progress including a bunch of accounts created during the DPL election, but, some didn't, such as Peter Samuelson's DAM processing, which I'd explicitly referred to as an example that should have been trivial for the DAMs to process, as any problems should have been resolved at AM stage since it was AMed by a FrontDesk member. Peter's still in the DAM queue at the time of writing. As the background for that is private, it would have been nice to keep it out of this discussion. Anyway, the reason why this problem ended up in the DAMs hands is because *only* the DAMs were mailed with some doubts, not the AM. And that only after the AM report was done... Anyway, I'm really not going to tear apart the little bubble in which you have placed yourself - I simply don't see how this would help anyone. Now to the actual matter at hand. I had this discussion in IRC yesterday and it seems that I should explain my opinion about the GR a second time: [1] (i) You have added a policy for everything, but removal from the DM list is still under-defined. This is a crappy idea. Imagine a Sven Luther case in DM - someone who's technically capable and invests a lot of time, but leads to regular flamewars. There is no question that we would need to have some procedure to decide what should happen in such cases. Now, back to the Sven Luther example: Imagine how *that* flamewar would look if the procedure to kick him out would have been hand-crafted just for his case? So basically, I won't accept your proposal as remotely sane until the initial policy includes some guidelines on removals from the DM list. (ii) Debian has a QA problem. Sponsorship did nothing to improve it. In fact, I believe sponsorship to be one of the reasons for it. Let's explain this a bit: Sponsorship is one of the main factors that lead to the explosion of the number of packages in the archive. The growth in the number of packages is, in fact, much bigger than the growth in the number of users. This means that the number of users per package has fallen [2], directly translating to the fact that packages receive less testing before they are released. This is equivalent to bugs and packaging mistakes staying unnoticed for a longer time. This problem is almost exclusive to packages that are priority: optional|extra, ie packages likely to be maintained by newcomers to Debian. On the other hand, sponsorship is (besides the few cases were people only want to maintain a few packages and not invest more time in Debian) used as an education system. It's training people on the job, allowing them to understand policies and procedures when bugs are reported or their sponsor notices a problem while uploading. The shrinking user:pkg ratio has already shown it's effect: Packages of seldomly used, specialized software are often of low quality, ignore licensing problems and aren't integrated into the rest of the Debian system as tight as they could be. The ever-growing number of RC bugs in sid is a sign for that, a better sign is the number of unfixed important bugs [3] and there is always the simple test of taking 20 random packages from the archive and checking them for obvious packaging problems [4]. I'm also believing that sponsoring is not as good as it should be - people often sponsor software without doing the thorough checks that *should* be done. Now on to the actual matter: The proposed Debian Maintainers concept is splitted into two parts: (1) Someone needs to advocate a maintainer, some people need to decide if that maintainer should get added to the keyring and thus get upload permissions for all packages that carry him as Maintainer/Uploaders and have the DM-Upload-Allowed field set. Without spelling out how the approval by the DM keyring maintainers should happen, I guess most people are thinking about checking packages, looking at past work, bug handling, ... (2) As soon as someone is in the DM keyring, a DD can give him upload rights for virtually every package by adding the DM to the Uploaders field and adding the DM-Upload-Allowed field. This concept is completely ignoring the problems that sponsoring exposed - in fact, it makes these problems worse. The number of checks done by DDs is reduced to one examination of an initial set of packages by the DM keyring maintainers [5]. The set of
Re: The Debian Maintainers GR
Kalle Kivimaa [EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: (2) As soon as someone is in the DM keyring, a DD can give him upload rights for virtually every package by adding the DM to the Uploaders field and adding the DM-Upload-Allowed field. If there is a malicious DD who wants to do that, what would stop that DD from creating an automated system that accepts packages from the DM, signs them and sends them into the upload queue? I'm not saying that the DD is malicious, but simply a moron. That happens more often, really. Marc -- BOFH #60: system has been recalled pgplCQBnSVl0b.pgp Description: PGP signature
Re: The Debian Maintainers GR
Kalle Kivimaa [EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: I'm not saying that the DD is malicious, but simply a moron. That happens more often, really. OK, the DD is a moron and marks a random package X as a DM-allowed by doing a NMU. Maintainer of X notices this and does an immediate upload which removes the flag. I fail to see a big problem here, unless the moron continues the ping-pong, which would be grounds for expulsion, I guess. No. DD moron allows DM moron to upload crappy packages, noone notices. I'm amazed that you fail to see a problem. Marc -- Fachbegriffe der Informatik - Einfach erklärt 225: ActiveX Interaktive Rechnerdemolierung. (Manfred Worm Schäfer) pgp1JmGi1ADI0.pgp Description: PGP signature
Re: The Debian Maintainers GR
Kalle Kivimaa [EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: No. DD moron allows DM moron to upload crappy packages, noone notices. I'm amazed that you fail to see a problem. Ah, you're saying that a Joe R. Developer doesn't care to take a look at the changes when some random developer does an NMU on his package. No, I'm not. Is it so hard to imagine that a DM could maintain (adopt, co-maintain, ...) something and still do a horrible job? Marc -- BOFH #279: The static electricity routing is acting up... pgpJTLMV45Dqj.pgp Description: PGP signature
Re: The Debian Maintainers GR
Kalle Kivimaa [EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: No, I'm not. Is it so hard to imagine that a DM could maintain (adopt, co-maintain, ...) something and still do a horrible job? It isn't. But, as this is no worse situation than we currently have with sponsoring, I don't really see it as a showstopper, unless you suggest we should restrict sponsoring, as well. Could you just read the long email I just sent a few hours ago? You replied to it, so I assume you have noticed it, but somehow I get the impression that you didn't actually have a look at the content. Marc -- BOFH #374: Its the InterNIC's fault. pgpgC7Trlfgl1.pgp Description: PGP signature
Re: The Debian Maintainers GR
Manoj Srivastava [EMAIL PROTECTED] writes: On Mon, 30 Jul 2007 10:36:46 +0200, Marc 'HE' Brockschmidt [EMAIL PROTECTED] said: (ii) Debian has a QA problem. Sponsorship did nothing to improve it. In fact, I believe sponsorship to be one of the reasons for it. This seems like an issue for educating sponsors who are sponsoring packages without ensuring the package meets the requisite quality standards. I have personally found that sponsoring a package is, for me, an exercise that takes about two to three times the time I would need to package the software myself, from scratch; but I think this is far from the norm. No, it sounds about right. Of course, updates are costing only a few minutes because there is only a diff to check. It's actually in the interest of sponsorees to have one sponsor per package, but somehow this doesn't get advertised very often. Perhaps putting together guidelines and processes for the sponsor is something that we should look into? As long as there is no way to enforce such guidelines, I don't believe this would actually help. There already is the Debian Policy and the Developers Reference, which should be enough to guide people through sponsoring. The actual problem is that these people *don't* care enough to follow these rules, as there is no real way to enforce them and they *know* it. Marc -- BOFH #185: system consumed all the paper for paging pgpdqrRvbuzrP.pgp Description: PGP signature
Re: Debian Maintainers GR Proposal
Anthony Towns [EMAIL PROTECTED] writes: 1) A new keyring will be created, called the Debian maintainers keyring. It will be initially maintained in alioth subversion using the jetring tool, with commit priveleges initially assigned to: * the Debian Account Managers (Joerg Jaspert, James Troup) * the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt, Brian Nelson) *cough* It would have been nice to inform people that you are planning to involve them in something like this :) 2) The initial policy for an individual to be included in the keyring will be: [...] * that at least one Debian developer (preferable more) is willing to advocate for the applicant's inclusion, in particular to the fact that the applicant is technically competent and good to work with. I would like to change this to at least two, simply because I believe that this shouldn't be an actual problem for active maintainers. 3) The initial policy for removals for the keyring will be under any of the following circumstances: * the individual has become a Debian developer * the individual has not annually reconfirmed their interest * multiple Debian developers have requested the individual's removal for non-spurious reasons; eg, due to problematic uploads, unfixed bugs, or being unreasonably difficult to work with. This part is broken and shouldn't end up in a final proposal. We need to decide on actual rules, otherwise this can lead to endless flamewars. 5) The intial policy for the use of the Debian Maintainer keyring with the Debian archive will be to accept uploads signed by a key in that keyring provided: [...] I'm not too happy with this part. My idea was always to allow people upload rights for individual packages that have been checked once by a full DD - and even that doesn't make me happy. In general, there is a (not really small) number of DDs who sponsor crappy packages on a regular basis, simply because they don't know better. The number of RC bugs in such packages is quite high and often the packaging is not more than copying stuff from the DESTDIR of a make install to debian/$packagename. I agree that some software doesn't need more work, but a majority of packages could be improved a lot. The average (in)competence of DDs is what makes me believe that non-DDs shouldn't get to upload whatever software they would like to package. Ganneff has done a great job of doing QA in the NEW queue, but I don't want to rely on that. He is overworked anyway, the rest of the ftp-team doesn't really help with NEW processing and the number of packages waiting for manual actions usually doesn't help to do thorough individual QA checks. Call me bitter, I call it release team experience. Anyway, something more constructive: I think that from a QA point of view, allowing DMs to only upload packages that were once checked by some trustworthy person is a lot better than your proposal. Marc -- BOFH #229: wrong polarity of neutron flow pgprSfERzfwxt.pgp Description: PGP signature
Re: Debian Maintainers GR Proposal
Raphael Hertzog [EMAIL PROTECTED] writes: On Fri, 22 Jun 2007, Marc 'HE' Brockschmidt wrote: Anthony Towns [EMAIL PROTECTED] writes: * multiple Debian developers have requested the individual's removal for non-spurious reasons; eg, due to problematic uploads, unfixed bugs, or being unreasonably difficult to work with. This part is broken and shouldn't end up in a final proposal. We need to decide on actual rules, otherwise this can lead to endless flamewars. We take non-binary decisions every day (MIA, hijack, etc.). This is just one more of those. Usually it's pretty clear when someone isn't up to the task. We have a very hard time to kick DDs out - we don't do a binary decision there, we do have a defined procedure and we still come out with a flamewar. I would like to do better in this. unreasonable difficult to work with basically means that any group of DDs can come over and say Eh, we don't like that guy and the person should be kicked out ... or not? Who decides, actually? The whole keyring team? Will there be a vote? Is it enough if 50% of the people who voted are in favour of kicking someone out, or is it 50% of all people with voting rights? Do we have a period in which voting should happen? These are all things that should be decided *before* actually needing them, because an actual use-case will always make the discussion about a procedure personal. 5) The intial policy for the use of the Debian Maintainer keyring with the Debian archive will be to accept uploads signed by a key in that keyring provided: [...] I'm not too happy with this part. My idea was always to allow people upload rights for individual packages that have been checked once by a full DD - and even that doesn't make me happy. [...] Anyway, something more constructive: I think that from a QA point of view, allowing DMs to only upload packages that were once checked by some trustworthy person is a lot better than your proposal. I agree with you in the principle (and the first time this idea cropped up, I understood it that way). However this doesn't scale very well... in any big team, the usual DD maintainers should be able to grant upload rights fairly easily to DM. If they have to make a new request each time that they decide that a DM can have uploads rights on a new package, it's going to be somewhat painful. Yes. It should be. Granting permissions on an archive used by a few thousand people *should be painful*, as it needs consideration. One way to get out of this is to mark those new packages as maintained by a new team [EMAIL PROTECTED] and to add the maintainer in the Maintainer field only later once we trust him enough for that. Would that be acceptable for you? No. You know enough to German to understand what *T*oll *E*in *A*nderer *M*acht's [1] means. It's like the QA team as Maintainer - Noone cares until something breaks horribly. Marc Footnotes: [1] For those of you not speaking german [2]: Team can be expanded to something like Yay, someone else does the work in german [2] You do know that the g3rman cabal will make that mandatory soon, right? -- BOFH #236: Fanout dropping voltage too much, try cutting some of those little traces pgpszmG7kyh3S.pgp Description: PGP signature
Re: Debian Maintainers GR Proposal
Anthony Towns [EMAIL PROTECTED] writes: On Fri, Jun 22, 2007 at 11:03:50AM +0200, Marc 'HE' Brockschmidt wrote: Anthony Towns [EMAIL PROTECTED] writes: The average (in)competence of DDs is what makes me believe that non-DDs shouldn't get to upload whatever software they would like to package. If you're trying to get rid of all the DDs who make (frequent) mistakes, then I guess I should be one of the first on the chopping block. I won't comment on that, because your performance as maintainer has nothing to do with this discussion. IMO, and YMMV, the number of mistakes you make doesn't really matter very much, it's the amount your mistakes affect others, which you can minimise either by not making mistakes in the first place, or by fixing your mistakes afterwards. One way in which sponsorship works badly is that it imposes a large cost to getting the person who made the mistake to fix it -- they need to find a sponsor, coordinate with that sponsor, and the sponsor needs to independently verify the changes. Sponsorship is supposed to prevent serious mistakes by letting a second pair of eyes check the package before uploading it to the archive. This doesn't work properly, because people are allowed to sponsor even if they are not able to clean up their own packages. Your proposal doesn't fix this problem, it doesn't even acknowledge it to be a problem - it just ignores it and allows more people to do what they want. Anyway, something more constructive: I think that from a QA point of view, allowing DMs to only upload packages that were once checked by some trustworthy person is a lot better than your proposal. I'm a bit tired of dividing DDs into trustworthy and not, so I'm more inclined to just let every DD have the same level of trust. Wait, you were the one adding all those people to the ftp-team, right? Sorry, I believe that there groups in Debian that are too small (like the ftp-team) and groups that are far too big (like the number of people with full upload rights for everything). Marc -- Fachbegriffe der Informatik - Einfach erklärt 275: Luster-Format Positiv gemeint: Eßfreudig Negativ gemeint: Das Äquivalent von zwei Öltanks (Alexander Stielau) pgpRhmjDWfAuL.pgp Description: PGP signature
Re: A question to the Debian community ...
Sven Luther [EMAIL PROTECTED] writes: But, this insistence, which comes after the expulsion procedure against me which was restarted the day after i announced my DPL candidacy, while i was being utterly silent on the Debian mailing list, gives me a very very bad feeling. Sven, fuck off. It's not always about you. Marc -- BOFH #184: loop found in loop in redundant loopback pgpWDkxxUmskP.pgp Description: PGP signature
Re: Question for Sam Hocevar
Sam Hocevar [EMAIL PROTECTED] writes: On Sat, Mar 03, 2007, Stephen Gran wrote: Was that a purposeful attempt to dodge the GNAA question, or did you not understand the question? By the way, I hope you are not mistaking me with the individual who [...] OK, now I'm curious... We had DPL hats and Vanuata pants. Are you wearing GNAA socks from time to time? Marc -- BOFH #415: Maintence window broken pgp28YFREFx1S.pgp Description: PGP signature
Re: Question to the candidates: inclusion of the kFreeBSD-* ports
Sune Vuorela [EMAIL PROTECTED] writes: On 2007-02-27, Julien BLACHE [EMAIL PROTECTED] wrote: If an ftpmaster was to charge an amount of money to include the new architectures (as was the case for amd64), what would, according to Huh? what has been the case for amd64? please enlighten me. Please wait for -private declassification. kthxbye, Marc -- BOFH #224: Jan 9 16:41:27 huber su: 'su root' succeeded for on /dev/pts/1 pgpCZxpOvAQJt.pgp Description: PGP signature
Questions to all candidates: Release importance, release blockers, release quality
Hi, I would be happy to hear answers from all candidates to these questions, but I expect that they are at least partially answered by the platforms. Please simply point to them if you included an answer there, even if they are not online yet. So, to the questions: * How important are regular releases for the project? * How important are regular stable point releases for the project? * Should we fix up dak to allow point-releases for old-stable? * Could you list the issues that you think delayed the release of etch? Do you think that we need to restructure the release process for lenny to avoid these? If yes, how? * Do you think that a release of high quality is more important than a timely release? [ie: Should we switch from when it's ready to when we said we would release] Marc pgpY4Jx45FsYC.pgp Description: PGP signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Hi, I second this proposal: Don Armstrong [EMAIL PROTECTED] writes: == BEGIN PROPOSAL = The Free Software movement is about enabling users to modify the works that they use on their computer; about giving users the same information that copyright holders and upstream developers have. As such, a critical part of the Free Software movement is the availability of source (that is, the form of the work that a copyright holder or developer would use to actually modify the work) to users. This makes sure that users are not held hostage by the whims (or lack of interest or financial incentive) of upstreams and copyright holders. Different types of works have different forms of source. For some works, the preferred form for modification may not actually be digitally transferable.[1] For others, the form that originally was preferred may have been destroyed at some point in time, and is no longer available to anyone. However, to the greatest extent possible,[2] the availability of source code to users is a critical aspect of having the freedom to modify the software that is running upon ones computer. Recognizing this, the Debian Project: A. Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution. That is, works must include the form that the copyright holder or upstream developer would actually use for modification. B. Strongly recommends that all non-programmatic works distribute the form that the copyright holder or upstream developer would actually use for modification. Such forms need not be distributed in the orig.tar.gz (unless required by license) but should be made available on upstream websites and/or using Debian project resources. C. Reaffirms its continued support of users whose hardware (or software) requires works which are not freely licensed or whose source is not available by making such works available in non-free and providing project resources to the extent that Debian is capable of doing so. D. Requests that vendors of hardware, even those whose firmware is not loaded by the operating system, provide the prefered form for modification so that purchasers of their hardware can exercise their freedom to modify the functioning of their hardware. 1: Consider film negatives, or magnetic tape in the case of audio recordings. 2: Here it must be emphasized that we refer to technically possible or possible for some party as opposed to legally possible for Debian. We also assume digital distribution, and do not attempt to require the distribution of physical objects. = END PROPOSAL === Marc -- BOFH #311: transient bus protocol violation pgp2bfLr33MVz.pgp Description: PGP signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Heya, I second the proposal quoted below. Steve Langasek [EMAIL PROTECTED] writes: The application of DFSG#2 to firmware and other data The Debian Project recognizes that access to source code for a work of software is very important for software freedom, but at the same time source is often not a well-defined concept for works other than those traditionally considered programs. The most commonly cited definition is that found in version 2 of the GNU GPL, the preferred form of the work for making modifications to it, but for non-program works, it is not always clear that requiring this source as a precondition of inclusion in main is in the best interest of our users or advances the cause of Free Software: - The author's preferred form for modification may require non-free tools in order to be converted into its final binary form; e.g., some device firmware, videos, and graphics. - The preferred form for modification may be orders of magnitude larger than the final binary form, resulting in prohibitive mirror space requirements out of proportion to the benefits of making this source universally available; e.g., some videos. - The binary and source forms of a work may be interconvertible with no data loss, and each may be the preferred form for modification by different users with different tools at their disposal; e.g., some fonts. While the Debian Free Software Guidelines assert that source code is a paramount requirement for programs, they do not state that this is the case for non-program works, which permits us to consider whether one of the above points justifies a pragmatic concession to the larger context within which Free Software operates. THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. Marc -- BOFH #57: Groundskeepers stole the root password pgpnJizxpl83L.pgp Description: PGP signature
Re: Question to all candidates about the NM process
Andreas Schuldei [EMAIL PROTECTED] writes: * Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2006-03-04 13:06:37]: Though there are often threads about problems with it on our mailing lists, the NM process hasn't changed much in the last three or four years. What do you think about the most common problems (takes too long, is asking for too broad knowledge)? Do you think that we need to change the NM checks? Basically, we should let good people become Developers faster. I know that one of the core problems is currently that there are not enough developers involved with NM. That's one problem. Another problem is that NMs are not too happy to get asked a whole bunch of questions that seem to have no connection to the stuff they want to do. This is more than a simple problem of getting more people to help, it involves discussing more fine-grained privileges, which would more or less require changes to our infrastructure everywhere and are not a real solution at the moment. I did not have time yet to bring my thoughts about this in a useful form, but it's definitely something which concerns the whole project. Marc -- Fachbegriffe der Informatik - Einfach erklärt 11: Swapspace Raubkopierertreffen (Kristian Köhntopp) pgpJoscVtTqDC.pgp Description: PGP signature
Re: Question to all candidates about the NM process
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Sat, Mar 04, 2006 at 01:06:37PM +0100, Marc 'HE' Brockschmidt wrote: Do you think that we need to change the NM checks? [...] As an example where I think the current situation is suboptimal, the current template's library questions are too complicated if you're not going to work with C libraries, or especially if you're not going to work with C programs at all, but they are inadequate if you're actually going to maintain a C library. However, how to exactly change the templates then, I'm not sure about. Well, looking at the problems the release teams faces when yet another central library needs a major upgrades or changes its API in interesting ways, it seems like we need to educate a lot of developers about library packaging. They don't inform themselves enough, as far as I can see. What do you think about these problems with the technical skills of some DDs? Have you thought about educating people that already have their account? One of your fellow DDs candidates proposed to make DDs go through the NM process on a regular basis, what do you think about that? Marc -- BOFH #77: Typo in the code pgpyowe6X2yJO.pgp Description: PGP signature
Re: Question to all candidates about the NM process
Steve McIntyre [EMAIL PROTECTED] writes: On Sat, Mar 04, 2006 at 01:06:37PM +0100, Marc 'HE' Brockschmidt wrote: 2. Asks for too broad knowledge It has been suggested several times over the years that we ask too many questions of NM candidates. People want to do work for Debian, but not everybody needs to know the gory details of library symbol versioning (for example) if their interests and skills lie in translation. So far, our organisation has been tailored for a group of package maintainers, _not_ translators or sysadmins or artists or ... Actually, we have special NM templates for people who are interested in working on documentation and translation. But this leaves the problem if a translator or artist really needs to have all rights a DDs has, including shells on Debian hosts, upload permissions and other, potentially security-relevant stuff. Do we need to hand out real accounts to people who don't need them, or should we add new titles to allow them to identify with Debian (Debian Translator, for example)? Marc -- BOFH #51: Cosmic ray particles crashed through the hard disk platter pgp5VxHTaJ7cD.pgp Description: PGP signature
Re: Question to all candidates about stable point releases
Anthony Towns aj@azure.humbug.org.au writes: On Sat, Mar 04, 2006 at 01:02:20PM +0100, Marc 'HE' Brockschmidt wrote: Though Martin 'Joey' Schulze as stable release manager presents lists of packages that are accepted into the next stable point release on a regular basis, they normally are not released roughly two months after the last update (which is the official plan). Do you know why this doesn't work as planned? What would you do to make regular point releases possible? I think the first thing to note is that irregular point releases aren't a big deal -- since they are almost solely security updates that are already available via security.debian.org, and TTBOMK there haven't been any installer updates to either woody or sarge. They're not really important as technical upgrade, but they give the impression that Debian releases something - after our last painful release cycle, many people have decided not to use Debian because of our (seemingly) slow development. Stable point releases are a nice touch to get a bit of trust back. That means point releases get a fairly low priority when other things are going on, and if those are the only concerns, that's what it *should* mean. I have to admit that I don't know what other stuff was going on in the last 2 years, the ftp-team is not really transparent. But if the workload is too high for its current members, it might be a good idea to add other people to the team. Anyway, I already partially blogged about what I think will improvement, http://azure.humbug.org.au/~aj/blog/2005/11/26#2005-11-26-niv2 which is to change the queue structure so that uploads don't enter proposed-updates until approved by the SRM. That allows rejections to happen immediately, rather than only when a point release happens, and reduces the work that has to happen at a point release pretty significantly too. After following the thread on here on -vote, I have the impression that this fixes something that's not a problem - as it doesn't reduce the work needed to be done by the ftp-team, which seems to be the current bottleneck. Marc -- Fachbegriffe der Informatik - Einfach erklärt 25: Multithreaded Wir mußten ein Flußdiagramm malen, um es zu debuggen. (Kristian Köhntopp) pgpHIdn76qaNL.pgp Description: PGP signature
Re: Question to all candidates about stable point releases
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: [...] I personally don't think it's a huge issue if those point releases are not 100% regular, because for the majority it's security updates, but it's still good to have them not too far apart, esp. for those updates that are not also already distributed via security.debian.org. Let's look at the point releases for woody. There were 6 updates after the initial Debian 3.0 release: 3.0r0: 2002-07-19 3.0r1: 2002-12-16 3.0r2: 2003-11-21 3.0r3: 2004-08-26 3.0r4: 2005-01-01 3.0r5: 2005-04-16 3.0r6: 2005-06-02 It looks like the situation improved in 2005 - but 3.1r1 was released more than 6 months after 3.1r0 (and there's no 3.1r2 yet), so something became worse again. With significantly less effort required each time from the side of ftp-master, I think stable point releases can happen more regularly. There can be other ways to improve too, but not by direct intervention from the DPL role -- a DPL should not want to micro-manage. Who *should* intervene if it looks like a team controlling central parts of Debian's infrastructure is too busy to do everything it should do? Marc -- BOFH #67: descramble code needed from software company pgpG80GHjA4qT.pgp Description: PGP signature
Re: Question to all candidates about stable point releases
Anthony Towns aj@azure.humbug.org.au writes: On Wed, Mar 08, 2006 at 12:18:32AM +0100, Marc 'HE' Brockschmidt wrote: After following the thread on here on -vote, I have the impression that this fixes something that's not a problem - as it doesn't reduce the work needed to be done by the ftp-team, which seems to be the current bottleneck. *shrug* I guess you've got a right to your own impression. Mine differs, and I think I've got more to base it on than you do -- or than Joey does for that matter. Well, you could start to explain what work is needed for a stable point release - it's not really obvious for the average developer who needs to do what/how much work to release something. If you'd be so nice and give a short overview about the current process and how your (planned) changes make it easier to get a point release done, we would all actually know what we are discussing about. Perhaps this could be done as first step to documenting the tasks of the ftp-team, which has been requested more than once in the past. Marc -- Fachbegriffe der Informatik - Einfach erklärt 184: MP3 Kann von WinAMP abgespielt werden. (Felix von Leitner) pgptxcSzAJn6g.pgp Description: PGP signature
Question to all candidates about stable point releases
Heya, Though Martin 'Joey' Schulze as stable release manager presents lists of packages that are accepted into the next stable point release on a regular basis, they normally are not released roughly two months after the last update (which is the official plan). Do you know why this doesn't work as planned? What would you do to make regular point releases possible? Marc -- BOFH #395: Redundant ACLs pgpseIkCGNfKn.pgp Description: PGP signature
Question to all candidates about the NM process
Heya, Though there are often threads about problems with it on our mailing lists, the NM process hasn't changed much in the last three or four years. What do you think about the most common problems (takes too long, is asking for too broad knowledge)? Do you think that we need to change the NM checks? Marc -- BOFH #160: non-redundant fan failure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Delegations
Anthony Towns aj@azure.humbug.org.au writes: There are two ways of looking at roles in Debian; as being maintainer of a resource -- whether that be a package, or a web site, or a system, or something else -- and as being a delegate of the DPL with specific delegated powers. Traditionally, maintainers have near absolute authority over their resources, and get to choose who replaces them. Delegates, by contrast, can be replaced by the DPL on a whim, though rarely are. | The Delegates are appointed by the Project Leader and may be replaced by | the Leader at the Leader's discretion. The Project Leader may not make | the position as a Delegate conditional on particular decisions by the | Delegate, nor may they override a decision made by a Delegate once | made. Replacing delegates on a whim is not really an option, so that fear has no basis. Those are pretty extreme differences, and it makes sense for people to prefer to be come under the heading of maintainer in that it gives them more certainty in fulfilling the role; and given DPLs have traditionally been fairly reticent about managing delegations, it's also how things have tended to work in practice. In the end, I don't think the difference is that important -- whether your a maintainer or a delegate, it's no good if you go crazy and start doing horrible things. ACK. But my concerns about this issue are based on the various conflicts some people had with the DAM and the ftp-team in the past - not about things that were done wrong, but about things that were not done (or, more correct, done after a quite long delay). These problems were only fixed when the respective people chose developers to support them in doing their task, after a long period of whining, flaming and using nice language for each other. One can believe that if teams/persons who lead to such problems would be delegates, the DPL would be able to appoint people to help them, even if they don't have the time to search for fitting candidates. This may, or may not help. But it can't worsen the situation. But anyway, I dislike the idea that a large part of our Project resources are managed by people who are not delegates of the only elected person in Debian, which is probably why I care about this. Marc -- BOFH #79: Look, buddy: Windows 3.1 IS A General Protection Fault. pgpWMLXnsER02.pgp Description: PGP signature
question for all candidates
Heya, Two years ago, Branden Robinson talked about the issue of some tasks in the project that are neither delegated by the Project leader nor covered by the Constitution directly. [1] He referenced his platform from 2004 last year (when he was elected), but it seems that nothing has happened since then. So, to the question: Should we amend our constitution to reflect how Debian is structured in reality, or should the people doing these tasks now be recognized as delegates of the DPL? What will you do to clarify the situation? Marc Footnotes: [1] http://www.debian.org/vote/2004/platforms/branden#s2p4 -- BOFH #72: Satan did it pgp10kmKJyX2W.pgp Description: PGP signature
Re: GFDL GR: Amendment: invariant-less in main v2
Heya, I second the Amendment fully quoted below. Marc Debian and the GNU Free Documentation License = This is the position of the Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software, since it allows for non-removable, non-modifiable parts to be present in documents licensed under it. Such parts are commonly referred to as invariant sections, and are described in Section 4 of the GFDL. As modifiability is a fundamental requirement of the Debian Free Software Guidelines, this restriction is not acceptable for us, and we cannot accept in our distribution works that include such unmodifiable content. 2. At the same time, we also consider that works licensed under the GNU Free Documentation License that include no invariant sections do fully meet the requirements of the Debian Free Software Guidelines. This means that works that don't include any Invariant Sections, Cover Texts, Acknowledgements, and Dedications (or that do, but permission to remove them is explicitly granted), are suitable for the main component of our distribution. 3. Despite the above, GFDL'd documentation is still not free of trouble, even for works with no invariant sections: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under the same terms as the software they refer to, or any of the traditional free software licenses like the the GPL or the BSD license. pgpUVVkMHkV0c.pgp Description: PGP signature
Re: Amendment: GFDL is compatible with DFSG
Craig Sanders [EMAIL PROTECTED] writes: with one of you, as with all, there's no point in engaging in debate or any kind of civilised discourse. So ... Why don't you just stop the flaming, if there's no point anyway? I have the feeling that this would somehow improve the climate of the discussion here on -vote. Marc -- liw weasel, I don't know, *some* of us had several years of complicated sex experience before we got tired of it weasel liw: that's when you became a DD? :) liw weasel, nah, that's when I had sex removed from debian pgpYnxGROiqEF.pgp Description: PGP signature
