Re: Changing how we handle non-free firmware
On Tue, 23 Aug 2022 10:39:57 +0200, Simon Josefsson said: > As far as I can tell, both Steve's and Gunnar's proposal would make > Debian less of a free software operating system than it is today. > That makes me sad. My preference for an outcome would be along the > following lines. > == > We continue to stand by the spirit of the Debian Social Contract §1 > which says: >Debian will remain 100% free >We provide the guidelines that we use to determine if a work is > "free" in the document entitled "The Debian Free Software > Guidelines". We promise that the Debian system and all its components > will be free according to these guidelines. We will support people who > create or use both free and non-free works on Debian. We will never > make the system require the use of a non-free component. > Therefor we will not include any non-free software in Debian, nor in s/Therefor/Therefore/ > the main archive or installer/live/cloud or other official images, and > will not enable anything from non-free or contrib by default. > We also continue to stand by the spirit of the Debian Social Contract > §5 which says: >Works that do not meet our free software standards >We acknowledge that some of our users require the use of works that > do not conform to the Debian Free Software Guidelines. We have created > "contrib" and "non-free" areas in our archive for these works. The > packages in these areas are not part of the Debian system, although > they have been configured for use with Debian. We encourage CD > manufacturers to read the licenses of the packages in these areas and > determine if they can distribute the packages on their CDs. Thus, > although non-free works are not a part of Debian, we support their use > and provide infrastructure for non-free packages (such as our bug > tracking system and mailing lists). > Thereby re-inforcing the interpretation that any installer or image > with non-free software on it is not part of the Debian system, but > that we support their use and welcome others to distribute such work. > == > /Simon I believe this should be on the ballot. Seconded. -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Re: Changing how we handle non-free firmware
My original mail doesn't seem to have come through, so I'm re-sending. Apologies if this comes through twice. On Tue, 23 Aug 2022 10:39:57 +0200, Simon Josefsson said: > As far as I can tell, both Steve's and Gunnar's proposal would make > Debian less of a free software operating system than it is today. > That makes me sad. My preference for an outcome would be along the > following lines. > == > We continue to stand by the spirit of the Debian Social Contract §1 > which says: >Debian will remain 100% free >We provide the guidelines that we use to determine if a work is > "free" in the document entitled "The Debian Free Software > Guidelines". We promise that the Debian system and all its components > will be free according to these guidelines. We will support people who > create or use both free and non-free works on Debian. We will never > make the system require the use of a non-free component. > Therefor we will not include any non-free software in Debian, nor in s/Therefor/Therefore > the main archive or installer/live/cloud or other official images, and > will not enable anything from non-free or contrib by default. > We also continue to stand by the spirit of the Debian Social Contract > §5 which says: >Works that do not meet our free software standards >We acknowledge that some of our users require the use of works that > do not conform to the Debian Free Software Guidelines. We have created > "contrib" and "non-free" areas in our archive for these works. The > packages in these areas are not part of the Debian system, although > they have been configured for use with Debian. We encourage CD > manufacturers to read the licenses of the packages in these areas and > determine if they can distribute the packages on their CDs. Thus, > although non-free works are not a part of Debian, we support their use > and provide infrastructure for non-free packages (such as our bug > tracking system and mailing lists). > Thereby re-inforcing the interpretation that any installer or image > with non-free software on it is not part of the Debian system, but > that we support their use and welcome others to distribute such work. > == > /Simon I believe that this should be on the ballot so: seconded. -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368 signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Mon, 22 Aug 2022 12:32:54 -0500, Gunnar Wolf said: > I hereby propose the following alternative text to Steve's original > proposal. > I'm only suggesting to modify the third paragraph, offering to produce > two sets of images (fully-free and with-non-free-firmware), being the > later more prominent. > = > We will include non-free firmware packages from the > "non-free-firmware" section of the Debian archive on our official > media (installer images and live images). The included firmware > binaries will *normally* be enabled by default where the system > determines that they are required, but where possible we will include > ways for users to disable this at boot (boot menu option, kernel > command line etc.). > When the installer/live system is running we will provide information > to the user about what firmware has been loaded (both free and > non-free), and we will also store that information on the target > system such that users will be able to find it later. The target > system will *also* be configured to use the non-free-firmware > component by default in the apt sources.list file. Our users should > receive security updates and important fixes to firmware binaries just > like any other installed software. > While we will publish these images as official Debian media, they will > *not* replace the current media sets that do not include non-free > firmware packages, but offered alongside. Images that do include > non-free firmware will be presented more prominently, so that > newcomers will find them more easily; fully-free images will not be > hidden away; they will be linked from the same project pages, but with > less visual priority. > = Seconded. -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368 signature.asc Description: PGP signature
Re: Draft proposal for resolution process changes
On Mon, 27 Sep 2021 18:51:05 -0700, Russ Allbery said: > A.3. Calling for a vote ... > 3. Minor changes to ballot options under point A.1.5 may be made up > until 24 hours before the call for a vote is issued. However, if they > are made after or within 24 hours of the end of the discussion period, > the Project Secretary must agree the change does not alter the meaning > of the ballot option... The "must" makes it sound like the Project Secretary is obligated to agree that any such proposed change doesn't alter the meaning, which I suspect is not what was intended. Perhaps instead, However, if they are made after or within 24 hours of the end of the discussion period, and Project Secretary agrees that the change does not alter the meaning of the ballot option, the Project Secretary will allow 24 hours for objections before issuing the call for a vote. Hubert
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, 7 Jul 2016 16:54:23 +0100, MJ Ray said: [...] > I feel an attempt should be made to reform that process to something > we might stand a chance of implementing, rather than abolish it > entirely, but I'm currently unable to second Don's excellent > amendments. I beg other DDs to consider them favourably. Given that, IIRC, one of the main reasons for wanting to declassify -private was that people wanted to be able to refer to previous discussions on -private that were historically significant, I'm wondering if a more sane approach would be to just say something along the lines of "anything on -private older than 3 years (and excluding the items excluded in the original GR) may be quoted publicly". Doing something like this means for content that people care about, the declassification work gets done by the people who care about it, and nobody has to worry about content that nobody cares about. Alternatively, the "declassification team" could just be a team that receives declassification requests, determines whether the requested posts may be declassified, and if so, plops the posts into a public archive somewhere. This would give more control over the declassification process and make sure that it is done by people who understand the rules. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 4096R/113A1368 https://www.uhoreg.ca/ Fingerprint: F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
On Mon, 01 Dec 2014 11:50:27 -0500, Scott Kitterman said: >> --- >> >> As a transitional measure, if this GR is passed after January 1st, >> 2015, then the provision of section §6.2.7.1 is taken to have >> occurred on January 1st, 2015. >> === >> >> I'd like to thank Anthony Towns for introducing the term limit idea >> several months ago [3] and for his help in polishing it through >> several rounds of feedback on the -vote mailing list. >> >> [3]: >> https://lists.debian.org/debian-project/2014/05/threads.html#00054 >> >> Cheers. > We discussed, and I thought there was consensus around, the idea that > due to the recent ctte churn, the transitional measure was no longer > needed. Due to that way things are worded, the transitional measure for this proposal would cause TC memberships to start expiring December 31, *2015* (i.e. next year), because the review period at the beginning of the year causes expiries to happen at the end of that year, as opposed to happening immediately. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhmrjn39@desiato.home.uhoreg.ca
Re: [SUMMARY] Maximum term for tech ctte members
On Sat, 22 Nov 2014 12:35:28 +0100, Stefano Zacchiroli said: [...] > For reference, I'm attaching the current version of the 2-S GR text. > I'm still waiting to see if people object to that idea, but the only > remaining change I'd like to apply to that proposal is to remove the > transitional measure, on the basis of the fact that we've already had > quite a bit of churn in the CTTE due to recent events. For the record, I added the transitional measure for easier comparison with the other methods, but other than that, due to the amount churn that we've already had, I have no opinion as to whether it should be there or not, as I mentioned in another email. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87h9xrmkhc@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members
On Fri, 21 Nov 2014 12:12:13 +, Sam Hartman said: [...] > 3) 2-s I think would expire 1 person, because Ian was in s, right? > 4) Anthony's new proposal would schedule the two most senior folks to > expire at end of 2015, right? So you'd have up to 5 experienced folks > through most of 2015. As the person who suggested 2-S, I think that Anthony's proposal has the same practical effect after the upcoming year, and preferred Anthony's wording. So I think of them as being essentially the same, and I wouldn't want both on the ballot. Of course for the purposes of your comparison, they are different, but we can treat them the same if we pretend that Anthony's proposal has a transitional measure clause that said that the two most senior members of the TC as of 2014-01-01 had their memberships set to expire on 2014-12-31. (I don't have an opinion on whether we should have such a transitional measure clause.) There's also the 2-R' proposal, and for the record, I would prefer not to have both 2-R' and 2-S on the ballot, because I consider them similar enough that I think that having an extra option on the ballot would do more harm than good. On the other hand, I would not oppose having both on the ballot. It's just that if someone formally proposes 2-R' for voting on, I personally would not propose 2-S. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4r4myuh@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members
On Thu, 20 Nov 2014 21:17:11 +, Anthony Towns said: > On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote: >> Lucas Nussbaum writes: > - only resignations from >> people who would have been expired count in S FWIW I think either of >> those deals with the concerns I raised, as it's going to be way too >> much effort to game that, and I cannot see why anyone would want to >> bother to do so. > I think: > On Jan 1st of each year the term of any Committee member who has > served more than 42 months (3.5 years) and who is one of the two most > senior members is set to expire on Dec 31st of that year. > would work as a description of that approach. Seems like a pretty good > compromise between '2' and '2-R'. > Also, it makes the arbitrarily chosen constant 42, which is always a > good thing. Yes, due to the use of the constant 42, this wording is clearly preferable to the wording I proposed in another email. (I think it's a clearer wording too.) -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhn5imlr@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members - 2-R model
On Thu, 20 Nov 2014 21:46:06 +0100, Stefano Zacchiroli said: > +++ constitution.2-R.txt 2014-11-20 21:37:17.030425658 +0100 ... > +or 0 (if R >= 2). R is the number of former members of the > +Technical Committee who have resigned, or been removed or > +replaced within the previous 12 months. FWIW, for the proposals where only the senior members are counted towards reducing the expiries, this could be changed to something like: ... R is the number of former members of the Technical Committee who have resigned, or been removed or replaced within the previous 12 months, and who were last appointed to the Technical Committee at least four and a half years (54 months) ago. or ... R is the number of former members of the Technical Committee who have resigned, or been removed or replaced within the previous 12 months, and who were among the two most senior members of the Technical Committee. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppchio16@desiato.home.uhoreg.ca
Re: Alternative proposal: focus on term limits rather than turnover
On Thu, 20 Nov 2014 21:45:11 +0200, Andrei POPESCU said: > On Jo, 20 nov 14, 21:43:03, Andrei POPESCU wrote: >> [private reply on purpose, since I'm not a DD] > Which I did not, sorry... I think you'll find that constructive messages (as yours was) are generally welcome on this list, whether it comes from a DD or a non-DD. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx1tiqce@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members
On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli said: > On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote: >> While I do think that 4-5 years is a good term length, I do think a >> lot of churn can be bad, and 2-r makes a lot of sense to me for the >> reason you give above. > Not sure if you've read it Sam, but just in case: I find Phil's > example in <871toz16nz@hands.com> to be most convincing against > the 2-R model in general. ... I think someone had already mentioned this option, but one way to avoid the effects of that issue, for those who want to avoid always expiring 2 members, is to expire 2-S members, where S is the number of members who have resigned since the last review period, and who would have been expired at the current review period if they had not resigned. So the resignation of a junior member would not affect the expiry process, but the resignation of a senior member would mean that we would have one less expiry. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mttkatj@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members
On Tue, 18 Nov 2014 14:15:25 +0100, Stefano Zacchiroli said: >7. Term limit: > 1. Membership of the Technical Committee is automatically >reviewed on the 1st of January of each year. At this time, the >terms of the 2 most senior members automatically expire >provided they were appointed at least four and a half years >(54 months) ago. One possible reading of that is that both members must have been appointed at least 54 months ago in order for either of them to be expired, which is probably not what was meant. I'm not entirely sure what a better wording would be. Maybe adding an extra sentence saying: "If only one member was appointed at least four and a half years (54 months) ago, that member's term expires." But I'm not too happy with they way that flows, and maybe someone can come up with something better. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tp0mteu@desiato.home.uhoreg.ca
Re: Tentative summary of the amendments
On Fri, 24 Oct 2014 10:21:01 +0200, Holger Levsen said: > Hi Uoti, thanks for your summmary of the situation. > On Donnerstag, 23. Oktober 2014, Uoti Urpala wrote: >> In another mail, Ian said that his interpretation is that the init >> system would not only have to be packaged in Debian, but in testing >> and not RC buggy. > yeah, I found this interpration also "interesting"... (eg. that there > is room for interpretaion... I thought "in Debian" ment sid and could > be buggy. Now I learn that buggy packages in sid seem to not always be > part of Debian... at least not in the context of this amendment.) - > interesting and a bit scary. Apologies to Ian for opening yet another can of worms. I thought that my request for clarification was for a fairly straightforward issue... Without wanting to put any words into Ian's mouth, I believe the intent is that any package can be installed with at least two init systems that are supported by Debian. In particular, a user should not have to go outside of the repository that they installed the package from. So if a package foo in stable depends on init1 | init2 | ..., then at least two of init1, init2, ... should be in stable. How do packages get in stable? They must be in testing first, so Ian saying that the alternative init system must be in testing seems reasonable from the viewpoint of releasing stable. And if the init system has an rc bug (that is not labelled *-ignore), then it won't make it into stable either. So if an init system fails the conditions that Ian gave, then it will not be in the next stable release. I believe that what Ian is trying to avoid is the situation where package foo depends on init1 | init2 | ... but only init1 is in testing, and init2, ... are all in unstable and in no condition to be part of the next release, and then we eventually release stable with only foo and init1, but not init2 | ... Basically, you shouldn't be allowed to get around the requirements of Ian's proposal by using some broken, non-release-quality init system as your alternative; the alternative init system must be something that users can actually use. The wording that Ian used isn't what I would have used -- I would have said that the alternative init system must be available from the same (repository|distribution|Debian version) as the package the user wants to install -- but I think the intent and the effect is pretty much the same as what Ian said, especially when seen from the point of view of stable. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq7pbmfu@desiato.home.uhoreg.ca
Re: Tentative summary of the amendments
On Tue, 21 Oct 2014 20:09:18 -0700, Nikolaus Rath said: > Lucas Nussbaum writes: >> Q2: support for alternative init systems as PID 1 >> = A2.1: packages MUST >> work with one alternative init system (in [iwj]) (if you are confused >> with “one” here, it’s basically fine to read it as “sysvinit” >> instead. See [10]this subthread for a discussion about this) > I believe Ian's intended reading is that a package that depends on > uselessd | systemd (but does not work with sysvinit) would be allowed > by his proposal. I would hope that this would not be allowed by Ian's proposal until uselessd is also in Debian. In particular, "work with one alternative init system", I think, *should* imply that the alternative init system is in Debian. Ian, as I understand your previous message, you were only addressing the issue of a non-sysvinit alternative init system, and not a not-in-Debian alternative init system, so can you clarify your intent regarding how your proposal would treat init systems that are not in Debian? -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnp2debu@desiato.home.uhoreg.ca
Re: Call for seconds: DFSG violations in Lenny
I have previously seconded these proposals, but this is to confirm that I still second these, with the modifications. > Option 1 (reaffirm the Social Contract) > ~~~ >1. We affirm that our Priorities are our users and the free > software community (Social Contract #4); >2. We acknowledge that we promised to deliver a 100% free operating > system (Social Contract #1); >3. Given that we have known for two previous releases that we have > non-free bits in various parts of Debian, and a lot of progress has > been made, and we are almost to the point where we can provide a free > version of the Debian operating system, we will delay the release of > Lenny until such point that the work to free the operating system is > complete (to the best of our knowledge as of 1 November 2008). > Option 2 (allow Lenny to release with proprietary firmware) > ~~~ >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; most of the issues that were outstanding at the time > of the last stable release have been sorted out. However, new issues > in the kernel sources have cropped up fairly recently, and these new > issues have not yet been addressed; >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 Etch release in Lenny (to the best of our knowledge as of 1 > November 2008); >4. We give priority to the timely release of Lenny over sorting > every bit out; for this reason, we will treat removal of sourceless > firmware as a best-effort process, and deliver firmware as part of > Debian Lenny as long as we are legally allowed to do so. > (Since this option overrides the SC, I believe it would require 3:1 > majority) > Option 3 (allow Lenny to release with DFSG violations) > ~~ >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 on DFSG > compliance issues; however, they are not yet finally sorted out; >3. We assure the community that there will be no regressions in the > progress made for freedom in the packages distributed by Debian > relative to the Etch release in Lenny (to the best of our knowledge as > of 1 November 2008); >4. We give priority to the timely release of Lenny over sorting > every bit out; for this reason, we will treat fixing of DFSG > violations as a best-effort process. > (Since this option overrides the SC, I believe it would require 3:1 > majority) pgp2BnHx2n6RY.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
I second the following proposals, as I believe that they should be voted on: (Robert Millan's unammended Option 1:) > Option 1 (reaffirm the Social Contract) > ~~~ >1. We affirm that our Priorities are our users and the free > software community (Social Contract #4); >2. Given that we have known for two previous releases that we have > non-free bits in various parts of Debian, and a lot of progress has > been made, and we are almost to the point where we can provide a free > version of the Debian operating system, we will delay the release of > Lenny until such point that the work to free the operating system is > complete. (Robert Millan's option 2, with expanded point 2 and shortened point 4:) > Option 2 (allow Lenny to release with propietary firmware) > ~~ >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; most of the issues that were outstanding at the >time of the last stable release have been sorted out. However, new >issues in the kernel sources have cropped up fairly recently, and >these new issues have not yet been addressed. >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 Etch release in Lenny >4. We give priority to the timely release of Lenny 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 Lenny, as >long as we are legally allowed to do so. > (Since this option overrides the SC, I believe it would require 3:1 > majority) (Robert Millan's unammended option 3:) > Option 3 (allow Lenny to release with any DFSG violations) > ~~ >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 on DFSG > compliance issues; however, they are not yet finally sorted out; >3. We assure the community that there will be no regressions in the > progress made for freedom in the packages distributed by Debian > relative to the Etch release in Lenny >4. We give priority to the timely release of Lenny over sorting > every bit out; for this reason, we will treat fixing of DFSG > violations as a best-effort process. > (Since this option overrides the SC, I believe it would require 3:1 > majority) I would also suggest adding the clause "to the best of our knowledge" to point 3 in options 2 and 3. I would, naturally, also second such an amended proposal. -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA pgpkhWJXfoU4H.pgp Description: PGP signature
Re: Technical committee resolution
On Tue, 11 Mar 2008 18:54:50 +, Ian Jackson <[EMAIL PROTECTED]> said: [...] > Or to put it another way, the problem isn't lack of new blood, it is > lack of involvement. We should be removing TC members who are > inactive or often wrong. ^^^ OK, the rest of your mail sounds somewhat reasonable, to an outsider who has no experience whatsoever with TC, but ... given that the TC often deals with contentious issues, and there is no obvious "right" or "wrong", how would you measure how often a TC member is "wrong"? Who determines if they're wrong? Or am I missing something? -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, 10 Mar 2008 22:53:25 +0100, Andreas Barth <[EMAIL PROTECTED]> said: > * Florian Weimer ([EMAIL PROTECTED]) [080310 22:27]: >> * Andreas Barth: >> >>> So, I would replace your 2. with the current text, and your >>> 3. with: >>> 3. During any DPL term, the DPL might appoint up to two >>> new members unilaterally. He might replace an existing member, or >>> add them as additional members at his choice, provided the maximum >>> number of eight members is not exceeded. >> >> This is ambiguous. Can the DPL replace two members or just one? > I thought of two - do you have a better text available. "[The DPL] might replace existing members ..."? You're already using plural when you say "...add them..." >> (And, BTW, does the Constitution make gender assumptions WRT to the >> DPL in other places? 8-) > s/He/The DPL/ -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
