Re: DPL Elections 2010: Last call for nominations
Le Thu, Mar 11, 2010 at 02:13:13AM +0100, Wouter Verhelst a écrit : > > Well, if nobody but Zack is going to run, that would make for a rather > dull and boring DPL election period. So I'll run, too. Hi all, I was hoping this would not happen, but if Stefano is not the only candidate, I will run as well. The main lines of my platform will be: - More trust to the DDs, - Easier entrance and exit in the Project, - More information (spendings, SPI lawyers, …) - General ping, appointment and rotation of the delegates, - Proposition of (not so) new paradigms for our releases, - More fun, less insults. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Le Sun, Feb 07, 2010 at 02:08:29PM -0800, Thomas Bushnell BSG a écrit : > On Mon, 2010-02-08 at 00:35 +0900, Charles Plessy wrote: > > 3) Is there a benefit of allowing non-free files to be distributed together > > with the source of the Debian system ? > > Have you considered the harm? It means that users can no longer assume > that whatever is in the source packages can be distributed by them under > the DFSG. Especially since your proposal is all about making copyright > information harder to locate, you are making things far harder. Hello Thomas, Indeed, there are pros and cons for my proposal. I have mentionned in my first message that with our current practice, our users know that – human errors excepted – everything they get along with the sources of the Debian system is DFSG-free. http://lists.debian.org/msgid-search/20100124144741.gd13...@kunpuu.plessy.org However, even when all the files are DFSG-free, one can not blindly redistribute or modify them, because we distribute works with an advertising clause, or works that require to rename the programs in case of modification. Therefore, one has anyway to check the licensing details for any DFGS-free file redistributed. About the visibility of the non-DFSG-free files: I wrote my proposal to be broad, not as a patch to the Policy. If the GR is voted and accepted, nothing prevents the Policy to require that non-DFSG-free files are marked as such in debian/copyright. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Hello again everybody, I did not have much time recently, so here is a summary email that tries to answer in a single message all comments that I received in public or private. 1) About the exhaustive reproduction of all copyright notices. I have the feeling that there is a consensus that we do not need to do what laws and licenses are not commanding, but unless votes are counted with a GR, this is only my feeeling and nothing else. I think that a GR is the right instrument to check the consensus over big changes, and that the relaxation of our policy of documenting all copyright notices is a big change. A GR that is accepted by a large majority is not necessarly a waste of time, because it dissipates misunderstantings that can arise with tacite agreements. But yes, there are alternatives, like electing a DPL that supports this change in his platform. The proposition that I make is deliberatly not a Policy change. First of all, it would introduce diffcult debates whether it can be edited later without another GR. Second, I do not propose to replace the definition of debian/copyright. In particular, this GR says nothing about other contents of this file such as the URL to the sources. Rather, if accepted this GR would be the green light for a Policy change. 2) About the source of the Debian system. I would like to take the opportunity of this message to make a clarification on what I wrote about ignoring the DFSG (http://lists.debian.org/msgid-search/20100125010005.gf13...@kunpuu.plessy.org). The DFSG are guidelines, and it is our social contract that tells us when to follow them. We must not ignore them in these situations. What I am arguing is that some files that are in the orig.tar files distributed in the source packages of the Debian system are not part of the source of the system, and that for them the DFSG do not apply. This is what I meant when I answered yes to MJ Ray when he asked me if I proposed to ignore the DFSG. Similarly, I do not think that it violates the title of the point one of our social contract (“Debian will remain 100% free”). The Debian project maintains and distributes non-free packages, so I conclude that the title – concise by nature – is about the Debian system, and not about everything made by the Debian project. Maybe it is because I am a biologist, but for me ‘Debian system’ means something functional, something that one can run to operate a machine. Without its sources, that system is not free. But the collection files distributed in our source packages do not define what the Debian system is: some ‘convenience copies’ of software libraries are ignored and we do not provide support for them ; they are not part of the Debian system. Moreover the possession of only the sources is not is enough for making and using a free system: one can not do anything with an empty computer and the sources alone. For me, it is the combination of the binary programs and their source that make a free operating system and define its boundaries. If on the medium that contains the system's sources there are other files that have no function in the system, then it is my point of view that they are not part of it. 3) Is there a benefit of allowing non-free files to be distributed together with the source of the Debian system ? There are clear benefits. Firstly, would allow to use a bit-identical source material as distributyed upstream. In the future, it would allow to distribute source packages based on repository clones that contain freely redistributable non-DFSG-free material, without having to engage in complex extirpations over the entire repository's history (since we would still be distributing the files after deleting them from the head). There is also a time benefit. Repacing a package is less than one hour of work, but multiply it by many packages, and it becomes a significant amount of time. Lastly, it is not fun, and having fun is a very important motivation in volunteer work. Doing boring, repetitive and not fun work leads people to make errors, which waste other people's time even is they are as minor as forgetting to add a mangle rule to debian/watch in order to take the ~dfsg suffix of the Debian upstream version. Here is a revised version of the GR proposal (still unsigned to underline that it is still a draft), that I hope clarifies point 2) Have a nice day, -- Charles Plessy, Tsurumi, Kanagawa, Japan General resolution: Simplification of license and copyright requirements for the Debian packages. Motion A: The Debian binary packages contain an exhaustive summary of the licenses of the files it contains. This summary also contains a reproduction of the copyright notices when the license require it. Additional documentation is encouraged but not necessary. Motion B: The Debian binary packages contain an exhaustive summary of the licenses of the files it contains. This summary also contains a reproduction of the copyright notices w
[OT] Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Le Mon, Jan 25, 2010 at 08:28:01AM +0100, Luk Claes a écrit : > > And who in their right mind do you expect to vote for ignoring DFSG > non-freeness, people that want to leave the project? For the record, I will not answer in this thread to other posts that are insulting, question people's mental health, or suggest that people who disagree should leave. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Le Mon, Jan 25, 2010 at 12:42:07AM +, MJ Ray a écrit : > Charles Plessy H> > Le Sun, Jan 24, 2010 at 10:56:36PM +, MJ Ray a écrit : > > > Charles Plessy > > > > According to our social contract, “We promise that the Debian system > > > > and all > > > > its components will be free according to [the DFSG].” [...] > > > > > > Wow, that's a twist. So how do you get around the idea that the > > > program must include source? > > > > in my opinion, if a file contained in a Debian source package has no > > function > > in the Debian system, if its removal has actually no effect on the system at > > all, then it is reasonable to declare that it is not part of the Debian > > system. > > In other words, just blatently ignore the bit of the DFSG that says > that programs must include source. Well, that explains it :-/ Yes, exactly. In this draft GR I propose to ignore some DFSG-non-free files, which includes sourceless files. Our social contract only stipulates that the Debian sytstem must be DFSG-free. We already have a non-free section for the non-free works that we would like to distribute for the purpose of being used with the our operating system. I think that our social contract also allow us to distribute innert non-free files together with the source of the Debian system as long as they do not take part of it. Doing this on purpose would of course be a big hypocrisy. We could mention in the GR that it is not acceptable to repack an upstream tarball for adding a non-free file, nor to include some in the debian diff or tarball component of the source package, nor for Debian to distribute its own developments as source packages containing non-free files since we have to show the way (note that not all packages in native format are Debian developments). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Le Sun, Jan 24, 2010 at 10:56:36PM +, MJ Ray a écrit : > Charles Plessy > > > According to our social contract, “We promise that the Debian system and all > > its components will be free according to [the DFSG].” My understanding of > > this > > is that the Debian system, our binary packages, is free and therefore we > > distribute its sources, the source packages. If these source packages > > contain > > non-free files that have no impact on the binary packages, I think that it > > can > > be said that they are not part of the Debian system. [...] > > Wow, that's a twist. So how do you get around the idea that the > program must include source? Hi, in my opinion, if a file contained in a Debian source package has no function in the Debian system, if its removal has actually no effect on the system at all, then it is reasonable to declare that it is not part of the Debian system. I propose to leave the possibility to maintainers to ignore such files and leave them in the Debian source packages, even if its source is not available, since what matters to us is to provide the source of our operating system, not of files that have no function in it. For example, in one of my packages (samtools), there is a windows executable that is built against a free library whose source is not included in the package. By our current standards it is sourceless and must be removed. I propose to ignore such files. In other packages, I found PDFs that look like been made with LaTeX, but their source is not available. In a couple of cases I managed to get the upstream maintainers to add the sources, but it often takes monthes. I propose to let the maintainers exclude these PDFs from the binary packages as long as their sources are not recovered, but spare the time of implementing the whole tarball repackaging machinery, especially that if their effort of asking the source upstram, this machinery is only transiently necessary. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Draft GR: Simplification of license and copyright requirements for the Debian packages.
Dear all, a significant part of the time dedicated to make and update Debian packages is spent in making an exhaustive inventory of the copyright attributions of the distributed work, and to clean the upstream original sources from files that have no impact on the binary packages we distribute. After a couple of years spent as a Debian developer, my personal conclusion that this time could be better spent for other efforts. I therefore propose to make these practices optional. Since it is a major change in our traditions, I propose to make a GR to make sure that there is a consensus. 1) The copyright attributions. The inventory of copyright notices that we distribute together with our packages is checked at the first upload only. At this step already, some packages with incomplete lists are accepted. For other packages, new copyright notices added upstream during updates are missed and the Debian copyright file is not updated. As a result, for the purpose of having an exhaustive listing of all the copyright notices present in the Debian source packages, the debian/copyright files are not a reliable source of information. I do not think that we have the manpower, nor perhaps the will, to do this inventory with the same aim of perfection as we have for other matters like security or stability for instance. Since not all license require to reproduce the copyright notices in the documentation of our binary packages, I propose to give up this self-imposed requirement, and simply focus on respecting the licenses. I have considered whether doing so would increase the work load of our archive administrators. I have some experience of NEW package inspection (http://wiki.debian.org/CopyrightReview). In my experience, the debian/copyright file is not an aid to the reviewing task, since the very goal of this task is to check if nothing has been omitted or incorrectly copied. The license of the redistributed files have to be inspected anyway, and at this moment it is usually clear whether the license has some clauses about the reproduction of copyright notices. 2) The non-free files that we remove from the upstream sources. Some upstream archives contain files that are not free according to the DFSG, but that can be omitted without affecting the programs distributed in our binary packages. Typical examples include non-free RFCs, sourceless PDFs, GFDL documentation, copies of scientific articles licensed with a clause prohibiting commercial use, or builds of the program for MS-Windows. Repacking the upstream sources to remove such non-free files does not provide any additional freedom. Among the disadvantages of repacking, there is the work overhead for the packager, and the loss of transparency for our users as we do not distribute a bit-wise identical source archive as upstream anymore. Among the advantages, our users know that if they download our source packages, there is non-DFSG-free file in. I think that this advantage is not as big as we think. Since we allow licenses with an advertisement clause and licenses that forbid to reuse the same program name for derived works, our users have to check the license of our packages in any case and can not blindly redistribute modified versions without checking for the above two points. So the presence of legally redistributable files that do not satisfy the DFSG in our source package would not change our user experience, especially that the target is files that can be ignored. Most importantly, none of these files would be distributed in binary packages anyway. According to our social contract, “We promise that the Debian system and all its components will be free according to [the DFSG].” My understanding of this is that the Debian system, our binary packages, is free and therefore we distribute its sources, the source packages. If these source packages contain non-free files that have no impact on the binary packages, I think that it can be said that they are not part of the Debian system. Therefore, despite what I propose is a big change from our traditions, I do not think that it is a change that contradicts our foundation documents. Draft of the GR --- I propose three motions that can be seconded separately. The first implements the point 1), the second points 1) and 2). Given that point 2) is likely to be far more controversial than 1), I do not think that there is a need for a motion that addresses 2) but not 1). Lastly, remembering the bitter experience of the two GRs of 2008, I propose a third amendment to strongly reject the GR and blame for having submitted it, in case I strongly misunderstood the situation and harmed the project with this GR. Also, it allows the ‘further discussion’ default option to really mean that more discussion is needed. Have a nice day, -- Charles Plessy, Tsurumi, Kanagawa, Japan General resolution: Simplification of license and copyright requirements for the Debian packages. Motion A: The Debian
Supermajority first? (was: Re: Firmware)
Le Fri, May 01, 2009 at 01:58:43PM +0200, Stefano Zacchiroli a écrit : > > I'm very much in favor of having this vote early in the release cycle, Hi all, There were discussions started on the supermajority requirement, that unfortunately were unconclusive (20090302002303.gm29...@matthew.ath.cx), http://lists.debian.org/debian-vote/2009/03/msg3.html Nevertheless, wouldn't it be safer to first resolve this issue, while keeping as a goal to address the firmware question early in the release cycle? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Project Leader Election 2009 Results
Le Mon, Apr 13, 2009 at 01:43:36AM +0200, Kurt Roeckx a écrit : > It seems that devotee does not properly handle it. Hi all, at worse, there may be alternatives, like selectricity (.org), which was also made by a DD. Unfortunately, it is not packaged… Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm current requirements for GR sponsoring
Le Thu, Mar 26, 2009 at 02:12:17AM +0100, Frans Pop a écrit : > > Fun! Maybe we should just dispense with the voting and just let the highest > number of seconds win? That sounds like a good idea. Since it is a supermajority vote, I recommend to the proposer to drop the GR if he does not manage to get three times the numbers of seconds compared to the status quo amendment, that I hereby second. > PROPOSAL START > = > General Resolutions are an important framework within the Debian > Project. While over those years, some problems have arised during the > discussion and/or voting of some resolutions, there is no evidence that > changing the number of sponsors (seconds) for GR proposals or amendments > will help solve those problems. Instead, by making it harder to propose > general resolutions or amendments, it might make it harder to improve > imperfect resolutions, or to add valuable options to a ballot. > > Therefore the Debian project reaffirms the current requirements for the > sponsoring (seconding) of GR proposals or amendments, and for overruling > of delegates. > ===== > PROPOSAL END Have a nice day -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
Le Wed, Mar 25, 2009 at 07:26:30AM -0600, Gunnar Wolf a écrit : > > I do believe we have moved quite a bit from this problem, which was > way more real and bitter several years ago. Today, far more people are > willing to tone down their discussion patterns, and the discussion > quality is obviously thus improved. Hi Gunnar, Sven, and everybody else, actually in this GR we are seeing the other extreme, which is that the main supporters of the GR do not explain what problem it is trying to solve, aprart that the number K is "too low". So the Project is again going the confrontational way: faction against faction, with the vote for checking who is stronger, and no discussion between the parties. Although I apreciate that there are no insults nor personnal attacks, my opinion on the level of the discussion about this GR is that it is close to zero. I really like Sven's proposal because there what starts a GR is the agreement that a vote is needed, not the impresson that one faction has strenghened its position enough to win a confrontation. In that context, having a high treshold could make sense. I also like the idea that the success of the GR is the duty of the proposer. I made some propositions along these lines in the constitutional discussion led by Matthew. We could also explore other possibilities such as a DPL veto mechanism. Anyway, the current GR really comes too early. I am not sure it will make it to the supermajority. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Amendment: Enhance requirements for General resolutions
Le Sun, Mar 22, 2009 at 12:04:31AM +0900, Charles Plessy a écrit : > Le Sat, Mar 21, 2009 at 03:49:02PM +0100, Joerg Jaspert a écrit : > > b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], > > as well as resolutions against a shortening of discussion/voting > > period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) > > developers to sponsor the resolution. > > That makes an interesting race condition with Bill's overriding GR… Dear all, dear Joerg, I present my apologise and ask you to forgive me this post. There are many discussions going in all directions and I it frustrates me strongly, but I should have keept my head cold and my hands far from the keyboard. Have a nice week-end, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Amendment: Enhance requirements for General resolutions
Le Sat, Mar 21, 2009 at 03:49:02PM +0100, Joerg Jaspert a écrit : > b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], > as well as resolutions against a shortening of discussion/voting > period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) > developers to sponsor the resolution. That makes an interesting race condition with Bill's overriding GR… -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question for all candidates about http://wiki.debian.org/DiscussionsAfterLenny
Le Fri, Mar 20, 2009 at 11:04:59PM +, Steve McIntyre a écrit : > > I can also see that you have your own menu/desktop topic there too > that I expect you'll want to raise. What are your plans for that? > > [1] http://wiki.debian.org/DiscussionsAfterLenny Hi Steve, First I plan to produce a document that presents the proposal whith avoiding misunderstandings, and to present it when the issues on top of the list will have been solved. I will not jump the queue. Then the first issue is programmatic: the Debian Menu is managed by some software written in C, and I am not a C programmer. So the goal of the kick-off discussion will not only be to get a broad consensus that using the fd.o format is good, but also to convince somebody to write the code. I think that the main argument for the proposal is that after swithching to a widespread format, we can submit Upstream the fd.o menu entries that can be used as is (and I really think that it will be the majority), which would be a nice contribution from Debian to the communauty, and would also reduce the complexity of our packages and in the end reduce our workload (especially now that we have triggers). Then goes the hard work: bug reporting, acceptance of the switch by DDs, writing a Lintian check, submitting entries in Upstream BTSes, subitting patches in our BTS, commiting patches in some VCSes,… I hope that by the time all of this is started, the discussions on the quality of our archive will have beared fruits and that we will be less shy removing packages that are obviously unmaintained and that nowbody wants to adopt. Last year I reviewed the debtags of ~100 packages in one month and a half; this makes me confident that if I have a few monthes plus some help, I can fuel perseverance and get the transition done. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Question to Stefano, Steve and Luk about the organisation into packaging teams.
Dear Stefano, Steve and Luk, I like a lot Stefano's statement about collaborative maintainance: "Collaborative maintenance should not be mandatory (we do have several very efficient one-man-band developers), but should be our default". First of all, I would be interested to know if it is a point of divergence between the candidates. Then, if there is interest for such a discussion, I would like to encourage you to develop your ideas on this subject, especially on what you can do as a DPL or DPL assistant. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Constitutional issues in the wake of Lenny
Dear all, in my impression, the problem in the vote for the Lenny release is that at the end it became an aggreagation of things of which nobody was satisfied, and of which nobody was feeling responsible anymore. To avoid this, I propose three actions. First, establishing the impartiality of the Secretary by not letting him taking the initiative of issuing constitutional statements. It may seem paradoctical at first, but if there is a subject that is matter of interpretation, there must be more than one person that feels that it is necessary. If the Secretary himself can not be the one who ask for clarification, nobody can suspect him to use his charge to push his personal opinions. That is the way many constitutional courts work in western and westernized states. In the case of the Lenny GR, it means that somebody else would have taken the blame for the mess introduced by supermajority requests, which would have protected Manoj and our institutions. Second, not mixing simple GRs with formal modifications of our Constitution and foundation documents. It is a very stressful situation if in the context of an already difficult discussion the Project wakes up one morning with a clock ticking for a constitutional amendment in two weeks. I think that modifications to the constitution and the foundation documents should be announced in advance, planned and discussed with a clear goal, and I would support modifications of the constitution that clearly separate simple GRs with supermajority GRs, where all the options except "None of the above" would require supermajority. This means letting the DDs vote for unconstitutional statements in simple GRs, just like our parliaments do with our laws everyday. This said, there are multiple protections against this: we are benevols and nobody can force a DD to do some work if he does not agree, and there are the DPL, the Secretary and the Technical Comittee, who have the authority and in some cases the power to block the implementation of blatantly wrong decision. Third, giving more leadership to the GR proposer. I already proposed this last year, and read Ian's answers with interest. After being convinced by his arguments a few monthes, I reverted to my original opinion :) Each vote is an investment of time and effort, and I think that it is important that somebody feels responsible for its success, which means: takes the blame if the situation is worse after the vote than before. By letting the proposer of a GR refuse some amendments, we can make him feel responsible for the vote process he started. What if he refuses one that has the favor of many? Probably a "Further disucssion" result, followed by another GR, which means a personal failure. I have tried to keep things short, so it may look simplistic, but if there are people intersted in refining the proposition or parts of it, we can work together on a text that looks more like a patch. Lastly, if there is some constitutional amendment, we can do some minor clarifications by the way. For instance: - In A.2.1 there is "The proposer or a sponsor of a motion or an amendment may call for a vote", but nowhere defines what a "motion" is. - According to A.2.2, "The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments." But then, what kind of vote can be called by the proposers of amendments in A.2.1 ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Question for all candidates about http://wiki.debian.org/DiscussionsAfterLenny
Dear Steve, Luk and Stefano, thank you very much for the time and efforts you are proposing to dedicate to the Project ! Our Consitution suggests a stronger leadership of the DPL the discussions: 9. Lead discussions amongst Developers. The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. http://www.debian.org/devel/constitution.en.html#5 Given how heated discussions can become in Debian, it seems that many previous Leaders have chosen to have a cooling role rather than a conducting role. Nevertheless, how do you intend to act in the context of this 5.1.9 article if you are elected ? In particular, there is already a long list of subjects on the Wiki. Can you comment about it ? http://wiki.debian.org/DiscussionsAfterLenny Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-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
Le Fri, Dec 19, 2008 at 01:38:33PM -0600, Manoj Srivastava a écrit : > > [ ] The Social contract is a binding contract > [ ] The social contract is binding, but currently flawed > [ ] The social contract is binding but may be overridden by a simple GR > [ ] The social contract is a goal, not a binding contract > [ ] The social contract is a non-binding advisory document Dear all, I think that we all show signs of exhaustion, frustration and demotivation. For some it is because important issues are not settled, for others it is because we do not relase, and for others it is because our mailboxes explode (by the way, please stop cross-posting). I think that starting another GR now will do more harm than good. Maybe the best opportunity to test if the Project is in the mood for formal reforms is the next DPL election. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Why the gr_lenny ballot is the way it is
Le Wed, Dec 17, 2008 at 12:15:22PM -0600, Manoj Srivastava a écrit : > > So, while the power set of the options is not feasible, we could > have a slew of options combining the various proposed options, if > people wanted to vote on a compatible set of options. Hi Manoj, I am affraid I have not not understood much of your explanations. Furthermore, I have deleted all of today's thread on -vote: I just do not have time to read it. I hope that the most important things you wrote today were in this email anyway. I will vote further discussion because I think that this vote should not have been started, and then option 5 because it is the only way to release Lenny that you did not flag 3:1. I wish the vote has been diffrerent, and hope you will consider taking a break for next secretarial term, so that the Project can try to explore functionning with a non-interventionnist secretary. Best, -- Charles Plessy -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On the firmwares/Lenny vote
Le Sun, Dec 14, 2008 at 01:40:19PM +0100, Pierre Habouzit a écrit : > > The problem is, such a strategy works iff everyone votes the same Hi all, it there a place where we could dump a copy of our ballots so after a few iterations of re-voting many we eventually converge on the same combination, in order to convey the message that they are unsatisfied ? (And by the way, for the readers of Debian Planet, I think that Christian voted 7452136, as in "option 5 first, option four second, …, and option 1 last.") Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Final call for votes: GR: Project membership procedures
Le Fri, Dec 12, 2008 at 02:52:01PM +, Steve McIntyre a écrit : > On Fri, Dec 12, 2008 at 09:05:54PM +0900, Charles Plessy wrote: > >Le Fri, Dec 12, 2008 at 11:57:06AM +, Neil McGovern a écrit : > >> With approximately 60 hours remaining, 142 people have voted, out of a > >> potential 1018. This is somewhat of an record for low participation. > > > >Hi all, > > > >I have nothing against a voting period lasting the standard two weeks. > > That's all very well, but I'm afraid it has little relevance. No sarcasms please: you were asked in private to shorten the discussion period, where nothing happened for two weeks, and you did nothing. We all have our share of errors during this conflict on the membership rules. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Final call for votes: GR: Project membership procedures
Le Fri, Dec 12, 2008 at 11:57:06AM +, Neil McGovern a écrit : > With approximately 60 hours remaining, 142 people have voted, out of a > potential 1018. This is somewhat of an record for low participation. Hi all, I have nothing against a voting period lasting the standard two weeks. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Draft ballot for the Project membership procedures vote
Le Thu, Dec 04, 2008 at 12:05:39AM +, Neil McGovern a écrit : > > > Also, you removed "and all the contributors" in Choice2 of the ballot > > (Choice 1 > > of the GR), which in my opinion is crucial. But since after the vote of the > > GR, > > the wording of the choices has no role in iterpreting the GR, just go ahead > > if > > you disagree. > > > > I don't agree I'm afraid. I regret that you did not feedback when I made propositions for the ballot and that you do not explain why you disagree. I think that your wording is detrimental to the choice that is the least embarassing for Jörg (or second least, after "further discussion"), but I accept your decision and will not discuss further unless invited to do so. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for the Project membership procedures vote
Le Wed, Dec 03, 2008 at 05:21:16PM +, Neil McGovern a écrit : > Hi all, > > Here's the draft ballot for the GR. Please note the timescale and reply > ASAP. Hi Neil The vote page has three mutually exclusive texts, with headers named "Choice 1", "Choice 2" and "Choice 3" that respectively correspond to "Choice 2", "Choice 1" and "Choice 3" in the ballot. I am affraid it is misleading. Shall I commit a change to the webpage to reorder and / or renumber the choices? http://www.debian.org/vote/2008/vote_002 Also, you removed "and all the contributors" in Choice2 of the ballot (Choice 1 of the GR), which in my opinion is crucial. But since after the vote of the GR, the wording of the choices has no role in iterpreting the GR, just go ahead if you disagree. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [vote_002] Preparation of the ballot.
Dear all, Based on the changes suggested by Lucas, I hereby call for a vote on the GR and all its amendments as per the paragraphs A.2.1.1, .2 and .3 of the annex of our Constitution, with the following wording for the choices: [ ] Choice 1: Invite the DAM and all the contributors to further discuss their ideas. [ ] Choice 2: Ask the DAMs to postpone the changes until vote or consensus. [ ] Choice 3: Ask the DAMs to implement the changes. [ ] Choice 4: Further discussion. I suggest that the ballot contains the following text (pasted from http://www.debian.org/vote/2008/vote_002): Choice 1. 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. Choice 2. The Debian Project, by way of a general resolution of its developers, asks the Debian Account Managers to postpone the implementation of the changes described on the debian-devel-announce mailing list (Message-id: <[EMAIL PROTECTED]>) about "Developer Status", until there is consensus on a proposal, or a vote to define the proposal that should be implemented. Choice 3. The Debian Project, by way of a general resolution of its developers, asks the Debian Account Managers to start the implementation of the changes described on the debian-devel-announce mailing list (Message-id: <[EMAIL PROTECTED]>) about "Developer Status". If there is anything I can do to help to prepare the ballot, please let me know. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
[vote_002] Preparation of the ballot.
Le Mon, Nov 24, 2008 at 09:09:36AM +0900, Charles Plessy a écrit : > Le Mon, Nov 24, 2008 at 08:12:10AM +0900, Charles Plessy a écrit : > > Hello Neil, Manoj, and everybody. > > > > Thanks Neil for preparing the vote page. I think that there is no need for > > extra explanation. There is a small mistake however: I am the proposer of > > the > > GR. Can you correct the page ? > > Ah, and sorry for not noticing this earlier, but the original sponsors for the > GR are missing from the list of seconds. As they did not oppose when I > accepted > the amendment prepared by Peter and me, they are formal seconders as well. Hi all, this is corrected now. The discussion period ended, and as there was actually no discussion taking place, I think it would be appropriate to call for the vote soon. The ballot could list the proposal and its two amendments as on the web page, and offer the following choices: [ ] Choice 1: Invite the DAM and all the contributors to further develop their ideas. [ ] Choice 2: Ask the DAMs to postpone the changes. [ ] Choice 3: Ask the DAMs to implement the changes. [ ] Choice 4: Further discussion. I welcome any feedback, but would in particular like to read from Peter and Lucas before calling for a vote. Also, I do not know how the choices should be ordered (randomised?) and of course leave the decision to Neil. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote pages up
Le Mon, Nov 24, 2008 at 08:12:10AM +0900, Charles Plessy a écrit : > Hello Neil, Manoj, and everybody. > > Thanks Neil for preparing the vote page. I think that there is no need for > extra explanation. There is a small mistake however: I am the proposer of the > GR. Can you correct the page ? Ah, and sorry for not noticing this earlier, but the original sponsors for the GR are missing from the list of seconds. As they did not oppose when I accepted the amendment prepared by Peter and me, they are formal seconders as well. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote pages up
Hello Neil, Manoj, and everybody. Thanks Neil for preparing the vote page. I think that there is no need for extra explanation. There is a small mistake however: I am the proposer of the GR. Can you correct the page ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le Wed, Nov 19, 2008 at 06:36:12AM +0200, Lars Wirzenius a écrit : > ke, 2008-11-19 kello 07:58 +0900, Charles Plessy kirjoitti: > > Manoj, > > > > I completerly agree. > > > > How about allowing the Project to release Lenny without changing the DFSG? > > That is what Manoj proposed on 2008-11-10 in > http://lists.debian.org/debian-vote/2008/11/msg00060.html Hi Lars, Manoj and everybody. I apologise for the noise I caused by overlooking the proposal. It completely fits what I would like to vote for (after "Further discussion"). Have a nice day -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le Tue, Nov 18, 2008 at 12:12:18PM -0600, Manoj Srivastava a écrit : > > The DFSG has lasted us oer a decade. In another decade, I think > the distinction of "central" and "periphery" and "Cell" processors is > likely to erode; and our DFSG definition should be forward looking. Hi Manoj, I completerly agree. How about allowing the Project to release Lenny without changing the DFSG? Despite forward-looking as strong as I can, I do not see people using the microcontroller of their wireless cards for anything else than controlling their wireless cards. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
Le Mon, Nov 17, 2008 at 09:38:19AM -0600, Manoj Srivastava a écrit : > On Mon, Nov 17 2008, Charles Plessy wrote: > > > the problem is that we were told that voting for your amendment makes > > it necessary to organise a vote to change the DFSG or the SC… I really > > understand your position, but apparently it is not me or you who > > decides. > > > Can the Secretary clarify again what will hapen if Peter's option is voted ? > > That GR clearly refines the DFSG statement that all programs > need source code. This supersedes the current DFSG, which allows for no > such exception. So the we need to amend the FSG wiht the changes after > the 3:1 vote. (Aside, on a personal note, anything else, to me, smells > of deceptive and underhanded handling of our social contract). > > > - What if Peter does not think that a second vote is necessary, but the > >Secretary does ? > > We need to see if the constitution mandates a second 3:1 vote > after a first 3:1 vote to supersede some dictum of a foundation > document. Hi Manoj, What is the way of seeing if the constitution mandates a second vote? I think that it would be really be helpful if things could be explained in a more operational way. For instance : what does "we need to amend" means? That it would be better, but that we can continue without? That a vote with no "Further discussion" will be taken? That the GR will lose its effect if we do not amend the DFSG? Lastly, I read the mail of Lars with a great interest. Is it possible to vote a non-supermajority option stating that we will release Lenny even if it infringes the DFSG? That would nicely solve the problem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
Le Mon, Nov 17, 2008 at 02:05:40PM +0100, Peter Palfrader a écrit : > > If anybody wants to change the words of either the DFSG or the SC they > will need to propose an amendmend. > > As proposed this clarifies my and other people's view of what our > foundation documents mean. You are welcome to add a > note/comment/explanation to the SC, but this doesn't modify it. Hi Peter, the problem is that we were told that voting for your amendment makes it necessary to organise a vote to change the DFSG or the SC… I really understand your position, but apparently it is not me or you who decides. Can the Secretary clarify again what will hapen if Peter's option is voted ? - What if Peter does not think that a second vote is necessary, but the Secretary does ? - What if a second vote is organised, but not option gets a 3:1 majority ? - What if no second vote is organised ? - What if Peter's option is voted with less than a 3:1 majority ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Defining free, and the DFSG's terminological shortcomings
Le Mon, Nov 17, 2008 at 10:51:54AM +1100, Ben Finney a écrit : > > Is now a good time to propose such a GR? I really do not think so. As you see, it creates discordance in the Project, kills the fun, sinks energy, makes people asking for each other's heads and starts a process that has many dead ends, like not having a release tea, or not agreeing on voting an amendment on the SC after accepting a 3:1 option that lets Lenny release. The supermajority madness is preparing a situation where 100 % of the developers are dissatisfied. The whole anti-debate is a big disorganised pile of emails and many questions were left unanswered. I still do not understand why it was possible to release Etch without a supermajority if it is not the case for Lenny. Can each camp, in particular the "release later" camp and the "supermajority" camp prepare a synthethic document to help people vote ? Have a nice day, if that is possible after having this thread for breakfast, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Further discussion ? None of the above ?
Le Sun, Nov 16, 2008 at 01:13:25PM +0100, Robert Millan a écrit : > > Instead of having a long, useless discussion on what "Further discussion" > means, would it be possible to remove that option? > > Correct me if I am wrong, but I think for any interpretation of what "Further > Discussion" would mean in this vote, there's an explicit option in the ballot. Hi Robert, we probably agree that the dicussion about "Further discussion" must be as short as possible. I am completely uncomfortable with the idea of a GR having decisionnal consequences even if all options are rejected. If it can help to cut the story short, I can propose yet another option: "None of the above. The Project decides nothing. Interpretations of this result are personal opinions and are not binding to anyone." Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary a écrit : >i Do we require source for firmware in main: No > ii Do we allow the Release Team to ignore SC violation bugs: No > iii What do we do for Lenny: Release > iV Do we modify foundation documents: Yes >v Do we override foundation documentsNo Dear everybody, we all agree that the result of "Further discussion" is the following, don't we? i Do we require source for firmware in main: As usual ii Do we allow the Release Team to ignore SC violation bugs: As usual iii What do we do for Lenny: Release iV Do we modify foundation documents: No v Do we override foundation documents No -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware (was: on firmware (possible proposal))
Le Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader a écrit : > > I'm hereby proposing the following general resolution: > > | Firmware is data such as microcode or lookup tables that is loaded into > | hardware components in order to make the component function properly. > | It is not code that is run on the host CPU. > | > | Unfortunately such firmware often is distributed as so-called blobs, > | with no source or further documentation that lets us learn how it works > | or interacts with the hardware in question. By excluding such firmware > | from Debian we exclude users that require such devices from installing > | our operating system, or make it unnecessarily hard for them. > | > | Therefore the Debian project resolves that > | a) firmware in Debian does not have to come with source. While we do > | prefer firmware that comes with source and documentation we will not > | require it, > | b) we however do require all other freedoms that the DFSG mandate from > | components of our operating system, and > | c) such firmware can and should be part of our official installation media. Hi all, can the secretaries state whether it is a supermajority option or not? If yes, how will we deal with it after it is voted? The GR will not be a foundation document but will rule over one. It will be hidden between many other GRs, which is in my opinion messy, especially if it happens multiple times: it will raise the entry barrier for people who want to understand Debian's principles. If the goal is to make a permanent decision, I would recommend a clear permanent change of our foundation documents. Another concern is that while I feel that there is a strong majority who is keen on "releasing Lenny with the firmwares", I am not sure if we all agree on the other consequences of this GR. My understanding of it is that it allows source-less firmwares in main, but Peter mentioned an interpretation in which the consequence of the GR is the creation of a new section (whith a transitory period where the firmwares stay in main). ([EMAIL PROTECTED]). In terms of workload for some developpers, it makes a big difference. I would really prefer hearing their opinion before voting for a supermajority resolution that may not be applied if nobody wants to deal with the work overhead of having a new section outside main. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds - DAM decisions
Le Wed, Nov 12, 2008 at 08:58:40AM +0100, Raphael Hertzog a écrit : > On Sun, 02 Nov 2008, Lucas Nussbaum wrote: > > Hi, > > > > I hereby propose those two alternate options and am asking for seconds. > > > > | Option: Ask the DAM to postpone the changes > > | > > | The Debian Project, by way of a general resolution of its developers, asks > > | the Debian Account Managers to postpone the implementation of the changes > > | described on the debian-devel-announce mailing list (Message-id: > > | <[EMAIL PROTECTED]>) about "Developer Status", until there > > | is consensus on a proposal, or a vote to define the proposal that should > > | be implemented. > > > > and: > > > > | Option: Ask the DAM to implement the changes > > | > > | The Debian Project, by way of a general resolution of its developers, asks > > | the Debian Account Managers to start the implementation of the changes > > | described on the debian-devel-announce mailing list (Message-id: > > | <[EMAIL PROTECTED]>) about "Developer Status". > > I hereby second both options. The discussion period is extended of two weeks. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Debian membership" GR: intend to call for a vote soon.
Dear all, Lucas' amendment has only 4 sponsors, so technically I can start to call for a vote. My position about this amendment is that if it can not get enough sponsors, it does not has chances to win, and as I would prefer that this GR is not a poll, I will not include it by myself. I therefore invite the people who like it to sponsor it by the end of the week. Past this delay, and unless somebody has a strong opinion against, I will call for a vote so that we can put an end to the story, heal wounds and move on. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds - DAM decisions
Le Mon, Nov 03, 2008 at 10:04:05AM +0100, Stefano Zacchiroli a écrit : > On Mon, Nov 03, 2008 at 09:34:47AM +0900, Charles Plessy wrote: > > > > I do not think that the only interpretation of a rejected GR is the > > contrary of its option(s). For instance, people can vote "Further > > Disucssion" because the text suggests that Joerg has the power to > > make the decisions he posted, despite they think that he has not. > > Yes, but then you have a lot of "clashes" in the reasons why people > are voting Further Discussion. I don't see any particular problem with > adding clarifying ballots and I do see the benefit. On the other hand, each new option adds its own possibilities of misinterpretation (although the options proposed by Lucas are quite clear). By the way, if "Further discussion" is misinterpretable, how about "None of the above instead" ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds - DAM decisions
Le Sun, Nov 02, 2008 at 10:34:14PM +0100, Frans Pop a écrit : > > The main question is: does the project think DAM should be allowed to > start implementing the proposal posted to d-d-a, or should the project as > a whole decide on the future direction of the NM process and related > processes. IMO that issue is addressed adequately in the open GR. Le Mon, Nov 03, 2008 at 12:18:11AM +0100, Lucas Nussbaum a écrit : > > I'm fine with voting with only the current option on the ballot, but > that will probably translate in people abstaining because they don't > agree, neither with the only option, nor with FD (which is the de facto > "go ahead"). Hi all, I do not think that the only interpretation of a rejected GR is the contrary of its option(s). For instance, people can vote "Further Disucssion" because the text suggests that Joerg has the power to make the decisions he posted, despite they think that he has not. At the moment, only two persons asked for an option that clearly invites to Joerg to go ahead, and they did not get seconds. If this GR would be rejected, I dont't think that one can speak for the silent majority and interpret their votes in one or the other direction. This said, I still hope that Joerg could send a clarification that what he presented is not yet an official policy, and that he will follow consensus or propose changes through a GR. With this we could avoid the current vote. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
Le Sat, Nov 01, 2008 at 09:35:36AM +0100, Peter Palfrader a écrit : > > Also note that 2K seconds puts any decision by a delegate on hold. The > immediate vote then is held to see if it stays on hold until the real GR > is done. So the only person who'd be in his rights to complain is > Joerg and he publicly said that he didn't need this immediate vote. Hi all Actually, there are persons who are constitutionnaly in their right to complain: the seconders of my original resolution, who I did not consult before changing it. Would one of them disagree with my acceptance of the amendment on which we worked together, the original proposisiton would be conserved, the amendment would be kept as an amendment, and the immediate vote would be rescheduled (A1.3). There are two obvious ways to avoid the immediate suspension vote: - The best one is that Joerg withdraws his decisions. - The second best one is to cool down until the end of the discussion period, and vote this GR as it is. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds - DC concept (was: Possible amendment for Debian Contributors concept)
Le Wed, Oct 29, 2008 at 11:45:31PM +0100, Frans Pop a écrit : > I hereby second the proposal quoted below and have no objection to > Charles Plessy's earlier proposal being dropped (or retracted) Thanks Frans for the explanation, and thanks again to Peter who showed us a way to an exit of the crisis. I hereby accept the amendement (as per the paragraph A1.2 of our constitution). > | 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. Have a nice day, -- Charles signature.asc Description: Digital signature
Re: Possible amendment for Debian Contributors concept (was: Call for seconds: Suspension of the changes of the Project's membership procedures.)
Le Tue, Oct 28, 2008 at 09:21:57AM +0100, Peter Palfrader a écrit : > > I really dislike the negative tone of the original proposed resolution, > so I am thinking of proposing this as an alternative option. > > The text I'm thinking about is currently this: > > | 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. > | . > | We thank Joerg Jaspert for exploring ideas on how to involve > | contributors more closely with 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 to further develop his 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, > | at least two weeks prior to any planned implementation. Hello Peter, this is a very sensible proposition. I will propose at the end of this mail a compromise, but first let me underline what is the part where I think our opinions still strongly diverge. You wrote in your amended version: "We invite the DAM to further develop his 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." This completely ignores that now there are other proposals, like the ones of Lars and Raphaël, and suggest that the only path we want to explore it the one drafed by Joerg. Do you think we could merge our propositions on a text like the following, that keeps your structure and tone, but contains major changes in its sense? 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. We could then have add dichotomy on the supension or not of the changes announced by Joerg before the discussion called by the GR achieves a result, since it seems to be where we would still disagree. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
Le Tue, Oct 28, 2008 at 12:21:41AM +0100, Joerg Jaspert a écrit : > > As I already explained none of this is implemented yet. None of this > will be implemented within the next few weeks. Joerg, in your answer to Aurélien, you wrote that your announcment was "a new policy to get implemented". But some of this policy does not need technical work to take effect. Same that a DD who lost his GPG key is still a DD, some DME could be appointed despite not having all the technical possibilities mentionned in the new policy. If by "none of this is implemented yet" you mean that you do not yet intend to apply the new policy you decided, I think that we can indeed drop this vote to save some work. Nevertheless, it is not only the implementation that is to be suspended by this GR, but the "new policy" itself. For the moment you are standing alone with it: other delegates, the Project leader, or the Project secretary, whom you all mentionned having consulted, none of them have supported the new policy formally. On the other hand, there are many developers who either disagree with the method or the contents or both, and even some that think that you do not have the appropriate delegation for taking it. We all have the same goal, making Debian more open, but disagree ont the means. Let's discuss instead of just checking who has the right to impose his opinion on the others. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
Le Mon, Oct 27, 2008 at 10:42:08AM +0100, Lucas Nussbaum a écrit : > > I fear that this GR will look like "vote yes if you don't want change." > I'm personally fine with changes to the membership process. But I want > them to be decided after an healthy, public, discussion, and probably > also a vote (because we are not going to agree on which proposal is the > best one). > > Should we add something to the GR to address this problem? Or simply > explain the reasoning behind the GR by different means, during the vote? Hi Lucas, There are definitely much more constructive things happening on the debian-project list. Since they are completely ignored, I think that this GR is still useful to prevent escalation in the "fait accompli". For instance email address "@contributor.debian.net" could be attributed, increasing confusion about wether the different subclasses of members of the Project have been created or not. In that case, a couple of more seconds would suspend the decision. I would be more than happy if a discussion between the different poles of opinions would start, with focus on convergence. For the moment, there has always been this or that person to write things close enough to what I think that I did not feel like adding to the noise by sending "me too" messages. Also, it is very important for the conflict to cool down that we do not start to simply count who is behind each of the two main propositions. So to cut a long story short, I hope that this GR proposal will be a Rubicon that nobody is willing to cross, so I do not feel like tweaking it. I am fine with a status quo while progress is done on the debian-project list. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
Le Fri, Oct 24, 2008 at 08:27:40PM +0200, Frans Pop a écrit :
> Charles Plessy wrote:
> > In accordance to the paragraph 4.2.2 of the constition, this
> > suspension takes immediately effect until a procedural vote decides if
> > the supsension is lifted until the vote of this general resolution.
>
> Besides a few grammatical errors and typos, the main problem with this is
> that the second half of the sentence is very unclear. It is also IMO
> unnecessary as what will happen if this GR is supported by enough
> developers to activate the suspension is already described in the
> constitution. Duplicating that here in different words can only result in
> problems.
Hi all,
I have integrated the changes suggested by Frans, Robert, and aspell
(wdiff attached).
Here is the amended proposal:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- Following the announcement of the 22nd of October on the
debian-devel-announce
mailing list (Message-id: <[EMAIL PROTECTED]>) about "Developer
Status";
- Given the importance of defining how the Project accepts new members;
- Because of the strong opposition to the method used to prepare, discuss and
decide the announced changes, and without judging their validity;
- In accordance with the paragraphs 4.1(3) and 4.2(2.2) of the Constitution;
The Debian Project, by way of a general resolution of its developers, decides:
The changes announced the 22nd of October on the debian-devel-announce
mailing list (Message-id: <[EMAIL PROTECTED]>) are
suspended [§4.1(3)]. This suspension is effective immediately [§4.2(2.2)].
In addition, the developers make the following statement:
The delegates of the Project leader are asked to not take decisions that are
not consensual about the membership procedures of the Project, and to let
these procedures change by way of a general resolution if no consensus
can be reached.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkkCcEwACgkQdYl1krr+x/L2TgCfVY2egheKlwCdy/IrWKqDypGd
U70AoI46bi5mlzzq3rRdp1nb2T6hq0OO
=+pJ/
-END PGP SIGNATURE-
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
- Following the announcement of the 22nd of October on the
debian-devel-announce
mailing list (Message-id: <[EMAIL PROTECTED]>) about "Developer
Status";
- Given the importance of defining how the Project accepts new members;
- Because of the strong opposition to the method used to prepare, discuss and
decide the announced changes, and without judging [-on-] their validity;
{+- In accordance with the paragraphs 4.1(3) and 4.2(2.2) of the
Constitution;+}
The Debian Project, by [-the-] way of a general resolution of its
[-developpers,-] {+developers,+} decides:
The changes announced the 22nd of October on the debian-devel-announce
mailing list (Message-id: <[EMAIL PROTECTED]>) are [-suspended.
In accordance to the paragraph 4.2.2 of the constition, this-]
{+suspended [§4.1(3)]. This+} suspension
[-takes immediately effect until a procedural vote decides if the
supsension-] is [-lifted until the vote of this general resolution.-]
{+effective immediately [§4.2(2.2)].+}
In addition, the [-developpers-] {+developers+} make the following
[-statememt:-] {+statement:+}
The delegates of the Project leader are asked to not take decisions that are
not consensual about the membership procedures of the Project, and to let
these procedures change by [-the-] way of a general resolution if no consensus
can be reached.
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
Le Fri, Oct 24, 2008 at 02:36:22PM +0200, Bastian Blank a écrit : > On Fri, Oct 24, 2008 at 09:15:43PM +0900, Charles Plessy wrote: > > The Debian Project, by the way of a general resolution of its developpers, > > decides: > > > > - The changes announced the 22nd of October on the debian-devel-announce > >mailing list (Message-id: <[EMAIL PROTECTED]>) are suspended. > > It needs to say that the decision is put on hold according to §4.2.2 of > the constition. Also the outcome needs to be finite, you want to drop > this decision. Thanks for the feedback, I have updated the proposal accordingly. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Following the announcement of the 22nd of October on the debian-devel-announce mailing list (Message-id: <[EMAIL PROTECTED]>) about "Developer Status"; - Given the importance of defining how the Project accepts new members; - Because of the strong opposition to the method used to prepare, discuss and decide the announced changes, and without judging on their validity; The Debian Project, by the way of a general resolution of its developpers, decides: The changes announced the 22nd of October on the debian-devel-announce mailing list (Message-id: <[EMAIL PROTECTED]>) are suspended. In accordance to the paragraph 4.2.2 of the constition, this suspension takes immediately effect until a procedural vote decides if the supsension is lifted until the vote of this general resolution. In addition, the developpers make the following statememt: The delegates of the Project leader are asked to not take decisions that are not consensual about the membership procedures of the Project, and to let these procedures change by the way of a general resolution if no consensus can be reached. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkB30QACgkQdYl1krr+x/LxZACdHidbXtPS91rrvoxBHz34reDq dlIAn2yYZ3VjC4Jmqw3NNEMOP7+Qovqc =eyP2 -END PGP SIGNATURE- I have turned the second resolution into a statement that is not binding for the delegates, which solves the constitutional issues. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Call for seconds: Suspension of the changes of the Project's membership procedures.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, Joerg Jaspert answered to my questions and some others on his blog, but the informations that I think we need are still not provided. - It is not known whether the Secretary, the Project leader and his delegates for the system administration, the FTP archive, the maintainance of the keyring and the front desk endorse his proposal or not. - He wrote that things are not implemented and wont'be for "a bit more", but we still do not know if they are decided or not (this is not the same as implemented or not), nor how long is "a bit more". I regret this precipitation and confusion, and therefore propose the following general resolution and call for seconders. - --- - Following the announcement of the 22nd of October on the debian-devel-announce mailing list (Message-id: <[EMAIL PROTECTED]>) about "Developer Status"; - Given the importance of defining how the Project accepts new members; - Because of the strong opposition to the method used to prepare, discuss and decide the announced changes, and without judging on their validity; The Debian Project, by the way of a general resolution of its developpers, decides: - The changes announced the 22nd of October on the debian-devel-announce mailing list (Message-id: <[EMAIL PROTECTED]>) are suspended. - Evolution of the membership procedures of the Project will be prepared in a discussion that will be finished by consensus or a general resolution. - --- Actually, if the GR road is eventually taken, it can be done through amending this proposal. This will save time and energy. Have a nice day, - -- Charles Plessy Tsurumi, Kanagawa, Japan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkBu2MACgkQdYl1krr+x/LMFwCfUdcNFFXXGeC8RpJGwCW4HC84 lRAAnjmxE0x5wOXqRHDIZSx6+HM+GkVF =V5Az -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - defer changes to Debian membership procedures to after the release of Lenny.
Le Thu, Oct 23, 2008 at 07:06:53PM +0200, Robert Millan a écrit : > On Thu, Oct 23, 2008 at 07:03:21PM +0200, Robert Millan wrote: > > > > Since such GR would go through the usual procedure, I don't think asserting > > that there will be a second GR needs to be part of this GR. In fact, it may > > even have contradictory results (e.g. if after Lenny is released nobody is > > interested in proposing a new GR anymore). > > > > So I would suggest leaving #2 out of the proposal. > > Or maybe just s/will/may/ ? Le Thu, Oct 23, 2008 at 08:42:50PM +0200, Lucas Nussbaum a écrit : > > You should probably point to a specific mail (web archives and/or > message-id). > I'm not sure that it's the right way to solve this issue. What about > deciding that changing the procedures is out of the scope of the DAM > delegation? > > Also, there's the hipothetical problem that Joerg could just re-send his > mail to avoid your proposed GR. Good morning Robert, Lucas, and everybody. I am much opened to changes, but let's minimize traffic: just amend and I'll second :) I think it is important to freeze the decisions to that things can coool down. I would prefer that this GR is as neutral and as minimal as possible, but the most important is to unite and send the message that it is not the administration who take such important decisions. The current situation is: - We do not know clearly what is decided and what is open to negociation. - Within the teams that are said to have participated to the decisions announced by Joerg, we do not know who support them and who does not. - We have not been informed about until when we are can make comments, and to what extent they will not be dismissed without answer. Let's stop the precipitation so that we can ignore for a while the long thread on debian-project without fearing that we do not recognise the Debian project when we wake up next morning. I am sure that the Project can find a solution that will satify the account managers and the many persons hoping for a change, but this requires time, exchange, less pressure and an open discussion on which we can construct the instead of just hoping to amend. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal - defer changes to Debian membership procedures to after the release of Lenny.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, as others I am concerned that pushing for changes on the procedures for becoming a member of Debian, using a top-down approach and no time frame, will result in suboptimal rules that will dissatisfy many. I therefore propose the following resolution. - --- The developers decide: 1) The decisions announced by Joerg Jaspert the 22nd of October 2008 on the debian-devel-announce mailing list are suspended. 2) After the next stable release, a general resolution will be used to decide on the procedures for becoming a member of the Debian project. - --- By the article 4.2.2.2 of our constitution, if 2K developpers second this resolution, the decisions will be suspended immediately (but a vote about the vote will decide if the suspension stays effective until the results of the GR vote are published). Have a nice day, - -- Charles Plessy Tsurumi, Kanagawa, Japan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkApgwACgkQdYl1krr+x/IBVACfYHQ2OZ1ky6NNm/b24695c5CE 9QMAn0rNEZIAATKtR4ol4NdfoCy1ZG54 =NPw1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal - defer changes to Debian membership procedures to after the release of Lenny.
Dear all, as others I am concerned that pushing for changes on the procedures for becoming a member of Debian, using a top-down approach and no time frame, will result in suboptimal rules that will dissatisfy many. I therefore propose the following resolution. --- The developers decide: 1) The decisions announced by Joerg Jaspert the 22nd of October 2008 on the debian-devel-announce mailing list are suspended. 2) After the next stable release, a general resolution will be used to decide on the procedures for becoming a member of the Debian project. --- By the article 4.2.2.2 of our constitution, if 2K developpers second this resolution, the decisions will be suspended immediately (but a vote about the vote will decide if the suspension stays effective until the results of the GR vote are published). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed vote on issue of the day: trademarks and free software
Le Thu, Sep 18, 2008 at 10:17:18AM +0200, Wouter Verhelst a écrit : > For those of you who're not aware: the Mozilla Foundation is now forcing > people who want to use their firefox trademark to display an EULA Hi Wouter, haven't we read on planet.debian.org that they changed their minds? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
Le Wed, Apr 30, 2008 at 08:15:42PM +0200, Josip Rodin a écrit : > > > > * Infrastructure teams are encouraged to adapt their sizes to their > > workloads, > > to ensure that they don't block or slow down the work of other Debian > > contributors. Hi Josip and everybody, I understand that ad-hoc GRs can be suspected to be too much investment of time for a punctual result. This makes me conclude that if we want this GR to be the most useful, then indeed it is important that it defines what an infrastructure team is, and who decide which team matches the definition. Similar to the way constitution and simple laws are hierarchised in some countries, this GR may be most useful if written in a way that it can be a reference that is not a "foundation document", but still can be modified by further GRs in the future if needed. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for all candidates: inter-dependancy of works the growing Debian project.
Le Thu, Mar 13, 2008 at 10:07:30AM +0900, Charles Plessy a écrit : > Le Thu, Mar 13, 2008 at 09:50:27AM +0900, Paul Wise a écrit : > > On Thu, Mar 13, 2008 at 12:46 AM, Charles Plessy > > <[EMAIL PROTECTED]> wrote: > > > > > (building non-free on official autobuilders is not allowed). > > > > Untrue, you just need to get your package whitelisted since non-free > > packages may not be legal to autobuild. You need to contact aba IIRC. > > Not sure why you don't know about this, nor where the best place to > > store this information is, perhaps the NM templates should cover it. Le Thu, Mar 13, 2008 at 07:13:47AM +0100, Cyril Brulebois a écrit : > > FTR, d-d-a: <[EMAIL PROTECTED]>. Hi all, this d-d-a message, as well as the fact that buildd.net lists different names for the non-free buildds, and the fact that buildd.d.o does not display the name of the buildds nor the logs for the autobuilt non-free packages, strongly suggest that "building non-free on official autobuilders is not allowed" is not "Untrue". Friends, it is not the first time that threads start on such misunderstandings, and I think that we could dramatically raise the level of lists like as -devel by taking more time between reading an email and answering to it. (And since this thread is supposed to be questions for the DPL candidates, I will add one: some time ago, a DD was sending emails on -devel whenever the discussion was offtopic, to ask for it to be transferred or stopped: what do you think of this initiative ?). Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for all candidates: inter-dependancy of works the growing Debian project.
Hi Moritz, hi Marc. I started to wonder about modularity in the use of the Debian infrastructure in 2006, because of a problem with the clustalw package. As you can see on the graph, its popcon score started to decrease around july. (http://people.debian.org/~igloo/popcon-graphs/index.php?packages=clustalw) I found out that it correlated with a bug whose fix was kept in unstable because it was not built on some arches (clustalw is non-free). This was a frustrating experience: I had strong evidence that we were losing users and it took me many hours of efforts to get it built on the missing arches, on which I have never had heard of anybody using Clustal. The popcon scores restarted to increase shortly after a re-upload with version bump triggered the release.net autobuilders. There is something interestign in this example: it shows the case of alternative services offered to a package maintainer (although one is not official). Both have similar functions, but their requisites are not the same (building non-free on official autobuilders is not allowed). When I talk about componentisation, I simply mean that the fate of a package could be the result of multiple bilateral agreements between teams. If there is build team A and build team B, then the package maintainer could collaborate with one or the other. It is not necessary competition: Debian will in the future release team S, release team B, release team V, like Stable, Backports, Volatile. For security support, the Security team has very high standards that do not necessary fit all packages (see the wordpress controversy for instance). Having either alternative security teams or schemes like "upgrade" or "best efforts" would allow to better fit upstream's strategy for instance. I hope I made myself a bit clearer. Finally, "Opt-out" is a negative concept that does not describe so well what I wanted to say. If I could summarise in a few words, it would be "sharing the responsability between the package maitainer and the Debian infrastructure teams". Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Question for all candidates: inter-dependancy of works the growing Debian project.
Hi, Although I am not yet a DD, as it can happen anytime before or after the elections, I would like to ask a question to the candidates. 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. 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. For some of them, alternatives exist: for instance in some conditions, the preferred way to distribute a package will be through the debian volatile project rather than through the stable releases. Can we imagine a more componentised Debian distribution, in which it would be the common responsability of the packagers and the service managers to opt in or opt out the use of each services by Debian packages (or preferably groups of them)? If yes, how would you define the role of the DPL in implusing these changes? Have a nice day, and many thanks for your candidacy. -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On the "Debian Maintainers" GR
Le Thu, Jul 26, 2007 at 07:53:09PM -0700, Russ Allbery a écrit : > gregor herrmann <[EMAIL PROTECTED]> writes: > > > I was not thinking about those "pet packages" but about existing > > packages that are maintained by existing teams where now non-DDs already > > do part of the work but then always have to bother a DD when it comes to > > uploading. > > > Maybe I'm wrong but I guess some DDs in those teams might appreciate > > the lesser work. > > > Cheers, > > gregor, member of the pkg-perl team, non-DD > > The Perl group is kind of an odd duck in that a substantial part of the > work of the group is just doing package uploading, because there are so > few bugs, so many packages, and usually the only actions on packages are > minor tweaks and new upstream releases. I'm not sure there are many other > teams like that. The Debian-Med project is in a growing phase that requires the gathering of programs and utilities which are easy to package and maintain, and which we keep in a common SVN repository. Needless to say, I would be very happy to see this GR accepted. I really enjoy the NM process because it helps me to raise my level, but this requires time, and the bar for becoming DD is higher than the level at which I am working now, just because what has to be done now is not so technically challenging. On the other hand, I do not know if my sponsor is mega-interested in reviewing updates of packages when upstream's modifications are just a 20-lines patch. So if there is a consensus that a DD should have a broad knowledge which encompasses the contents of T&S 1 and 2, then the GR is in my opinion the way to go. If there is a consensus that people who do sound team work and do not touch things they do not understand should be accepted as DD, then "just doing it" would be the most direct way to fulfill this goal. But I do not think that rejecting the GR gives a clear message to the people in charge of this task, since many different reasons of voting no have been explored in this list... Have a nice day, -- Charles Plessy Debian-Med packaging team. Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Le Fri, Jun 22, 2007 at 05:52:49PM +0200, Thijs Kinkhorst a écrit : > > We've seen in the past that capable people can pass through NM very quickly, > where most of the waiting is for FD, DAM approval. If the need is really > high, people can and are already be fasttracked. Dear Thijs, dear DDs, NMs, curious readers, Here is my opinion from the NM queue: it all depends on what is expected from a DD to know. I do not think that it is a quality issue, I think that quality has to be acheived by only giving software privileges to people who are aware of their areas of expertise and ignorance and act in consequence. Laxism can plague easy work as well as difficult work, it is more a question of goals that knowledge. If Debian wants the NM queue to be a process - be it by mentoring or by filtering - to select pluridisciplinary DDs who have a broad range of competences, then definitely the DM concept is useful. It is by giving people the tools to take and manage the time to raise themseves to the DD level that the NM queue becomes useful. For the moment, staying too long in the queue is a bit detrimental. As time passes, the number of packages of the NM applicant grow and the sponsoring overhead starts to kill the fun. For instance I enjoy sending new packages to my sonsor and explaining how it fits my work plans in Debian-Med. But when it is only for removing a ";" due to a g++ transition, or fixing other trivialties, I have a growing feeling that I now know what I am doing, and I would be happy to do the upload by myself. Then the question is why not concentrating on the NM questions and trying to exit the queue faster ? The answer is in a critisism written earlier in this thread: paraphrasing. If the NM queue is to increase the skills of the applicants, then strategies for answering faster defeat this goal. Also, past school is is increasingly un-fun to do a lot of theory without practice. (actually, in school as well, but this is an off-topic debate ;) So in the end, I see the DM concept as an opportunity to strenghen the training and mentoring aspect of the NM process, if the general opinion is that DDs should have a really high level and broad knowledge. If not, then maybe what would do the job would simply be to refocus the NM process to check that the applicant has integrated himself in Debian, by interacting and working together with DDs, by sharing the spirit of the fondamental texts, and by never lowering his aims of quality (which does not mean never making mistakes, this is more a funciton of to the quantity of work done). Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question to the Debian community ...
Le Thu, May 10, 2007 at 11:06:04AM +0200, Holger Levsen a écrit : > today I (once again) read a reply by a user who believed Svens lies and > wondered whats wrong with Debian. Hi Holger, Are you talking about the fact that users sometimes read offers of hardware on port mailing lists, and are clueless monthes later about the reasons for which nothing happened ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
Le Mon, Apr 23, 2007 at 12:25:31PM +0200, Josip Rodin a écrit : > 'We promise that the Debian system and all its components will be free > according to these guidelines.'. Dear Josip, are you really sure that the licences are "components of the Debian system"? If one removes them, the system, on a functionnal point of view, still works as before... Nothing "Depends:" on the licences. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
Le Tue, Apr 17, 2007 at 03:59:08PM -0400, Nathanael Nerode a écrit : > > Alternate suggested GR text: > --- > The Debian Project notes that many license texts are copyrighted works, > licensed > only under meta-licenses which prohibit the creation of derivative license > texts. > > We consider this to be undesirable. License texts are functional works; > reusing > legal text from an earlier license makes a new license much easier to read > and > interpret, while brand new legal text is likely to have unexpected results. > This is true even of preambles, which can have an effect on the > interpretation of > the license. We encourage all authors of license texts to allow the creation > of > derivative license texts. While not being a DD, I would just like to make the following comment: the fact that some licences are not modifiable has probably a reason, and I think that it would be wiser to find, understand, and discuss it before voting on the sole fact that being modifible can have some advantages. My hypohtesis is that forbiding modifications prevents from bad things such as having a "GNU Genial Public Licence" with the same text as the GPL except that there is an added clause saying that you have to send a gold bar to the an animal liberation front each time you eat gnu meat. I am sure that that treacherous licences are forbidden by the law in many countries, but is it the case in all of them ? Having an unmodifiable licence addresses the question by not relying on laws enforcing fairness in contracts to avoid those situations. If it looks like the license, it is the verbatim or a fake. There is clearly an advantage to this. (Which has to be balanced with others such as restriction of freedom to modify of course). Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Question for Anthony Towns
Dear Anthony Towns, When I sent you a private mail complaining about the ad-hominem style of one of your posts on -devel, you published it on your blog. Will you do the same with the private mails sent you as a DPL, if you were elected ? Best regards, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
