Re: Constitutional amendment: reduce the length of DPL election process
Hello,
On Tue, Jul 31, 2007 at 05:48:06PM +1000, Anthony Towns wrote:
> I propose we change section 5.2 of the constitution concerning appointment
> of the Project Leader to reduce the nomination period to a week, and the
> voting period to two weeks. In wdiff format:
>
> =
> 5.2. Appointment
>
> 1. The Project Leader is elected by the Developers.
> 2. The election begins [-nine-] {+six+} weeks before the leadership
>post becomes vacant, or (if it is too late already) immediately.
> 3. For the [-following three weeks-] {+first week+} any Developer
>may nominate themselves as a candidate Project [-Leader.-]
>{+Leader, and summarise their plans for their term.+}
> 4. For three weeks after that no more candidates may be nominated;
>candidates should use this time for campaigning [-(to make their
>identities-] and [-positions known).-] {+discussion.+} If there
>are no candidates at the end of the nomination period then the
>nomination period is extended for [-three further weeks,-] {+an
>additional week,+} repeatedly if necessary.
> 5. The next [-three-] {+two+} weeks are the polling period during
>which Developers may cast their votes. Votes in leadership
>elections are kept secret, even after the election is finished.
> 6. The options on the ballot will be those candidates who have
>nominated themselves and have not yet withdrawn, plus None Of The
>Above. If None Of The Above wins the election then the election
>procedure is repeated, many times if necessary.
> 7. The decision will be made using the method specified in section
>A.6 of the Standard Resolution Procedure. The quorum is the same
>as for a General Resolution (4.2) and the default option is "None
>Of The Above".
> 8. The Project Leader serves for one year from their election.
> =
Seconded.
Best regards
Frederik Schüler
--
ENOSIG
signature.asc
Description: Digital signature
Re: seconds searched for override of resolution 007 needed. (Was: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.)
Hello, I second the following proposal: On Sun, Oct 15, 2006 at 10:07:02AM +0200, Sven Luther wrote: > === START OF PROPOSAL === > Definition: For the purpose of this resolution, the "firmware" mentioned below > designates binary data included in some of the linux kernel drivers, usually > as > hex-encoded variables and whose purpose is to be loaded into a given piece of > hardware, and be run outside the main memory space of the main processor(s). > > 0. This resolution overrides the resolution just voted > (http://www.debian.org/vote/2006/vote_007). > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue, both upstream and in the debian packaging; however, it is not > yet finally sorted out. > > 3. We give priority to the timely release of Etch over sorting every bit > out; > for this reason, we will treat removal of problematic firmware as a > best-effort process, and in no case add additional problematic material > to the upstream released kernel tarball. > > 4. We allow inclusion of such firmware into Debian Etch, even if their > license > does not normally allow modification, as long as we are legally allowed > to > distribute them. > 5. We further note that some of these firmware do not have individual > license, > and thus implicitly fall under the generic linux kernel GPL license. > We will include these firmware in Debian Etch and review them after the > release. Vendors of such firmware may wish to investigate the licensing > terms, and make sure the GPL distribution conditions are respected, > especially with regards to source availability. > > 6. We will include those firmware into the debian linux kernel package as > well > as the installer components (.udebs) used by the debian-installer. > END OF PROPOSAL Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
Hello, sorry for being late on this, I took a couple of days off from "everything firmware" and this got inbetween. The Proposal worked out by Sven covers the consensual position of the kernel team, as discussed on the last kernel team meeting. I think this GR should be voted upon, as it considers all aspects of the issue. I hope we can vote on this despite the already running GRs, thus I second the following proposal: > === START OF PROPOSAL === > Definition: For the purpose of this resolution, the "firmware" mentioned below > designates binary data included in some of the linux kernel drivers, usually > as > hex-encoded variables and whose purpose is to be loaded into a given piece of > hardware, and be run outside the main memory space of the main processor(s). > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue, both upstream and in the debian packaging; however, it is not > yet finally sorted out. > > 3. We give priority to the timely release of Etch over sorting every bit > out; > for this reason, we will treat removal of problematic firmware as a > best-effort process, and in no case add additional problematic material > to the upstream released kernel tarball. > > 4. We allow inclusion of such firmware into Debian Etch, even if their > license > does not normally allow modification, as long as we are legally allowed > to > distribute them. > > 5. We further note that some of these firmware do not have individual > license, > and thus implicitly fall under the generic linux kernel GPL license. > We will include these firmware in Debian Etch and review them after the > release. Vendors of such firmware may wish to investigate the licensing > terms, and make sure the GPL distribution conditions are respected, > especially with regards to source availability. > > 6. We will include those firmware into the debian linux kernel package as > well > as the installer components (.udebs) used by the debian-installer. > END OF PROPOSAL Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [PROPOSAL] Postpone the etch release until all firmware issues are solved.
Hello, for the sake of completeness in the ballot, and having 4 options from "release with all firmwares" to "delay the release", I hereby second this proosal. > === START OF PROPOSAL === > The debian project resolves that : > > 1) We recognizes that there are many uncleared issues with the > current binary firmware files in linux kernel. > > 2) We will not ship a kernel package with such problematic licensing issues > as part of a stable release. > > 3) We will delay the debian/etch release until all these issues are sorted, > and we can ship a linux kernel package without any problematic licensing > issues > === END OF PROPOSAL === Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [PROPOSAL] Let's ship all firmwares included inthe pristine upstream kernel tarball in debian/etch.
I second the following proposal: On Thu, Oct 05, 2006 at 09:04:06PM +0200, Sven Luther wrote: > === START OF PROPOSAL === > Given the difficulty of finding a common ground about the non-free firmware > issue, the Debian Project does resolve that : > > 1) We allow inclusion in Debian Etch of all firmwares currently shipped in > the upstream linux kernel tarball. > === END OF PROPOSAL === Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Another proposal
On Sun, Oct 01, 2006 at 12:17:42AM +0200, Josselin Mouette wrote: > == Reaffirm support for Anthony Towns as the Project Leader == > > The Debian project reaffirms support to Anthony Towns as the Debian > Project Leader. However, it doesn't endorse nor support any projects Mr > Towns may lead or participate in outside Debian. seconded. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Hello, I thought accepting the amendment would imply a second, but if this is not the case: On Wed, Sep 27, 2006 at 12:36:56PM -0500, Manoj Srivastava wrote: > , > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); > | 2. We acknowledge that there is a lot of progress in the kernel > | firmware issue; however, it is not yet finally sorted out; > | 3. We assure the community that there will be no regressions in > | the progress made for freedom in the kernel distributed by > | Debian relative to the Sarge release in Etch > | 4. We give priority to the timely release of Etch over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware in udebs as > | long as it is necessary for installation (like all udebs), and > | firmware included in the kernel itself as part of Debian Etch, > | as long as we are legally allowed to do so, and the firmware is > | distributed upstream under a license that complies with the DFSG. > ` I accept this amendment and second it. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Hello, On Thu, Sep 28, 2006 at 11:45:54AM +0200, Sven Luther wrote: > fs, this is contrary to what we where trying to achieve, i would like to know > why you seconded this. What we want to archive, is release etch in time, being installable on all hardware supported upstream. From the discussion about this amendment, I understood this is being covered here, so I think this is a good compromise. Indeed this is a compromise, and everyone needs to make a step towards the others: those of us concerned about usability and the needs of our users will have to give up firmware blobs which are obviously not distributable - even upstream before the release can happen, while those of us concerned about the freeness of the software will have to give up a bit of freeness in the linux-2.6 package for the sake of a release on December, 4th. The alternative is simple: We patch all drivers and fix d-i to include udebs from non-free, and delay the release indefinitely until this is done. I obviously prefer the compromise, I am strictly against breaking 50+ drivers before having discussed every single one with the corresponding vendor and upstream maintainer, seeking a global solution. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Call for votes (Was: kernel firmwares: GR proposal)
Hi, On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote: > > 2. We acknowledge that there is a lot of progress in the kernel firmware > > issue; however, it is not yet finally sorted out; > > So, what progress has been made? For example: - the firmware_class infrastructure has been added in more than 100 drivers (as of 2.6.17) - the qla2xxx firmware has been dropped from the kernel sources, and is now shiped on ftp.qlogic.com - new drivers for devices requiring a firmware to be uploaded during initialization are included without embedded firmware (for example the ipw3945 driver, or aic94xx which has just been added in 2.6.19-rc) Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Hello, On Wed, Sep 27, 2006 at 12:36:56PM -0500, Manoj Srivastava wrote: > , > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); > | 2. We acknowledge that there is a lot of progress in the kernel > | firmware issue; however, it is not yet finally sorted out; > | 3. We assure the community that there will be no regressions in > | the progress made for freedom in the kernel distributed by > | Debian relative to the Sarge release in Etch > | 4. We give priority to the timely release of Etch over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware in udebs as > | long as it is necessary for installation (like all udebs), and > | firmware included in the kernel itself as part of Debian Etch, > | as long as we are legally allowed to do so, and the firmware is > | distributed upstream under a license that complies with the DFSG. > ` I accept the amendment. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Call for votes (Was: kernel firmwares: GR proposal)
Hello, On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote: > As I mentioned previously, I don't think point 3. here is the compromise I > would like to see. "Without further conditions" is so broad that it seems > to even *require* us to include firmware in main that lacks any sort of > proper distribution license. The intention is indeed to release the kernel as-is for Etch, postponing the work which needs to be done in contacting vendors and upstream to get relicensings and source disclosures until after the release. > And indeed, the upload of a completely > unpruned 2.6.18 package to unstable suggests that this is not an accident of > wording, but the actual view of the present kernel team. It is at least my actual view, the others should speak for themself. We will discuss this issue on the kernel-team meeting next Saturday, how we should handle the re-added firmwares, and seek a workable compromise. Dropping for example the apparently useless dgrs driver could be an option, or drop the drivers not needed for installation, which means basically one driver (acenic) from the originally pruned ones would be the non-free regression in comparison with the sarge kernels. But this should be decided by the whole kernel team. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Call for votes
Hello, On Tue, Sep 26, 2006 at 10:19:40PM -0500, Manoj Srivastava wrote: > , > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); > | 2. We acknowledge that there is a lot of progress in the kernel > | firmware issue; however, it is not yet finally sorted out; > | 3. We give priority to the timely release of Etch over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware in udebs as > | long as it is necessary for installation (like all udebs), and > | firmware included in the kernel itself as part of Debian Etch, > | as long as we are legally allowed to do so, and the formware is > | distributed under a DFSG free license. > ` I oppose such a change. this means we actually have to review all licenses before the release, and completely contradicts the original intention of this GR. If such a resolution was passed, the kernel team would either be forced to remove all badly licensed firmwares, even those required for installation, or we had to delay Etch until an appropriate infrastructure is implemented in all the installer, the kernel package and the non-free firmware package. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
Hi, On Sun, Sep 24, 2006 at 01:08:10PM -0400, Nathanael Nerode wrote: > Today I sent an email asking upstream to remove dgrs based on its > uselessness; we'll see what happens. Thanks. We should consider removing it, too then. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Let's vote ...
Hi, On Fri, Sep 22, 2006 at 10:45:34AM -0500, Manoj Srivastava wrote: > come to an agreement about what exactly in that email > constitutes the actual general resolution? This: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, without further conditions. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Third and final call for votes for the assets handling constitutional amendment GR
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > b7af2494-93e2-490e-9312-85647b0928b3 > [ 1 ] Choice 1: Amend the constitution [needs 3:1] > [ 2 ] Choice 2: Further discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- ENOSIG signature.asc Description: Digital signature
Re: Proposal - Defer discussion about SC and firmware until after the Etchrelease
Hello, On Mon, Sep 11, 2006 at 08:59:59PM -0700, [EMAIL PROTECTED] wrote: > is to drop support (in whole or in part) for > Broadcom NX2, Sun Cassini(+), Intel PRO/100 (although some of those > chips are also supported by the unaffected eepro100 driver), eepro100 is scheduled for removal upstream, not an option. > and (maybe) five more members of the > QL2xxx family. The firmware blobs are deprecated in 2.6.17 and have been removed in 2.6.18-rc. You already need the non-free package containing the firmwares to run these controllers with 2.6.17 and later, no need to remove the drivers. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
Hello, On Sun, Sep 10, 2006 at 02:16:26AM -0700, Steve Langasek wrote: > I asked you this question before privately and haven't seen an answer. You > say below "So we propose this GR:"; does that mean that everything up to > that is rationale, and not part of the text that developers will be voting > on? I am fine with it either way. The initial intention was to draw the complete picture before getting to the GR proposal per se, but IMHO this is not necessary anymore now, as everyone should be well informed about the status quo and the implications every choice bears. > This is very unclear to me; if the intent is to vote on the whole document, > I think some wording tweaks are needed. If the intent is to vote only on > the part beginning with "1. We affirm [...]", then I think it's much shorter > than it should be. hm, what is missing? > So if we are going to make an exception, I think we should take care to make > the smallest exception necessary. If we don't *need* to grant exceptions > for firmware based on their license, only on whether or not they include > source, I don't think we should include such firmware in the exception. > This prevents anyone from trying to add such firmware to etch that isn't > already included, which would be a regression vis-à-vis freeness. I would like to include ALL firmware shipped upstream in the Etch release, even those which where removed by Herbert Xu a couple of years ago when this issue faced up the first time (acenic, smctr, keypsan etc). Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
kernel firmwares: GR proposal
Overview: The Linux kernel source contains device drivers that ship with firmware files provided by the hardware manufacturer. They are uploaded during the driver initialization to the corresponding hardware device. Some of these binary image files are provided as a hexdump of register bank settings, others consist in fact of compiled binary code which is executed on the hardware device. Any device driver in the Linux kernel is freely available in source format and licensed under the GPL2. For many device drivers with attached firmware, the firmware image is freely distributable along with the corresponding driver. The most common source format for firmwares is the hexdump char array. It is almost impossible to distinguish between register dumps and binary code without asking the device manufacturer who provided the firmware. Removing every firmware which is distributed as hexdump only will cripple the kernel to an extent where it becomes unusable for most of our users, because popular network and scsi devices are among the drivers in question. Without these drivers, the user's system might not be installable at all. The current situation: We achieved a lot of progress compared with the situation in 2.6.8 (the kernel that shipped with sarge). We were able to convince upstream that a firmware loader is a good thing, and that firmware and kernel code should be separated. This firmware loader was added in 2.6.13, and meanwhile, more than 40 drivers have been converted to the new infrastructure. However, this is not yet finished, and some important drivers still use the old method. There will be a day where we can drop the remaining legacy, but we are not there yet. Also, though the firmware loader allows us to put the firmware where it belongs to (main or non-free, depending on the case), the installer can as of now only take udebs from main. Fixing this is not too hard, but it is doubtful whether we can fix this in time for etch, and we do not want to depend on that (and even then, we still would have non-free firmware, see above). But since there is lots of hardware which needs firmware for correct operation, the installer would not work for mainstream hardware otherwise. There are two ways how to deal with it: 1. Accept these issues as transitional issues for now; or 2. Delay etch for some serious time. In our social contract, we promised that the users and the free software community are our priorities. We firmly believe that our users profit very much from releasing etch in time, and that this is important enough that we can accept the transitional status with having a few firmware images left in main that should belong somewhere else. Of course, everyone who wants to make the number of such firmware images as small as possible is welcome to help converting old firmware loaders to the new standard, and working on the Debian installer. We are happy if this issues become smaller or even vanishes, but we do not want this to be a release blocker. So, we propose this GR: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, without further conditions. We want to emphasize that the success of this GR is considered as necessary by the kernel and release team for successfully delivering etch in time (and to allow us a successful planning of that). on behalf of the kernel- and release team Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: -= PROPOSAL =- Release sarge with amd64
Hi, On Thu, Jul 15, 2004 at 04:36:30PM -0400, Raul Miller wrote: > > It does support a number of commercial binaries though already, for > > those that need them. Many of us don't. > > I don't know what you mean here. Is "It" amd64 or cedega? I'm guessing > amd64. Are the commercial binaries i386 or amd64? I'm guessing amd64. Sorry for being pedantic, but according to www.transgaming.com cedega is emulating WIN32, you know. Cedega is not emulating windos64 nor the "windows on windows" layer M$ named their biarch setup. And there is no amd64 release of cedega from upstream. Bug them, not the debian amd64 port, please. Cedega does not support 64bit mode, but it will for sure run without a problem in a i386 chroot setup according to the amd64 howto found on alioth. If you setup the chroot and nvidia drivers correctly, you will for sure be able to run doom3 as it is inteded to run as soon as it hits stores. We'll see next month =) > Unless the debian amd64 port supports 32 bit binaries (the 32 bit binaries > I'm using on an amd64 system are available for free, though they're not > dfsg free) I think you're missing my point. The debian port DOES support 32bit binaries. You can run them without a problem, if you install them correctly. Just check the howto on alioth. Only non-free stuff needing a 32bit kernel will not work until vendors reconsider: ATI proprietary drivers, vmware. > I'm saying that Debian's current amd64 port isn't positioned to be useful > in as providing extensions to a 32 bit environment. Feel free to help in multiarch development, and consider the actual port a transitional stage. Do you prefer running i386 binaries and kernel on your amd64 system, wasting the additional registers, sse2 support and the improved memory management? Apparently not, considering: > I use Debian. On amd64. For now, I'm using it (the i386 flavor) in a > chroot jail on a gentoo base, or by rebooting into it. My condolences. Wheren't you able to install debian-amd64 or why do you use gentoo, looking at your DD status? very, very strange. Why did I never read anything from you on debian-amd64 and never saw you in #debian-amd64 on opn? Greetings Frederik Schueler PS: don't get me wrong, gentoo has some really good and friendly developpers, I just wonder a debian developper uses it considering the dispute between the two distros. -- ENOSIG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
