Re: Questions for DPL candidates: Support channels
On Thu, 2017-04-06 at 23:15 +0530, Ritesh Raj Sarraf wrote: > > Would this count as a HCL for your $work? > > > > https://wiki.debian.org/InstallingDebianOn > > I don't think any data, fed in good faith, could be termed as an HCL input. > We should eye for certification tools similar to what Red Hat, SUSE, Canonical > and Oracle may be using. A process similar to this is what would be useful to our project, in my opinion. Picked from Red Hat's HCL Documentation [1] * The partner establishes a certification relationship with Red Hat. * The partner creates a request for the certification of a specific system or hardware component on Red Hat's internal certification website (https://hardware .redhat.com). Red Hat's certification review team creates an official test plan inside the certification request to track the testing of all relevant components. * The partner runs the tests specified in the official test plan and submits results packages to Red Hat for analysis. * The review team analyzes the test results and marks them as completed when they receive passing results. Any failures require retesting. * The partner provides Red Hat with a representative hardware sample that covers the items that are being certified. * The system or component is marked as certified when all tests have passing results, and the entry is made visible to the public on the external Red Hat Hardware Certification website at https://access.redhat.com/certifications if the partner requested a published certification. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_Hardware_Certification/1/html/Test_Suite_User_Guide/sect-User_Guide-Certification_Process_Overview-Summaries.html -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part
Re: Questions for DPL candidates: Support channels
On Fri, 2017-04-07 at 00:10 +0800, Paul Wise wrote: > On Thu, Apr 6, 2017 at 11:07 PM, Thomas Goirand wrote: > > > Even more, from my experience, the availability of an HCL (ie: Hardware > > Compatibility List) is mandatory for some vendors to choose Debian. At > > $work, I've been told that Debian wouldn't an option for it. > > Would this count as a HCL for your $work? > > https://wiki.debian.org/InstallingDebianOn I don't think any data, fed in good faith, could be termed as an HCL input. We should eye for certification tools similar to what Red Hat, SUSE, Canonical and Oracle may be using. In quick search, I came across: http://www.oracle.com/webfolder/technetwork/hcl/hcts/index.html which looks similar to what I've wished for Debian. Unexplored results showed the following at the very first result. https://linux-test-project.github.io/ This one emphasized on Linux and if it serves the purpose, it could be a great start for Debian, because Linux is our prime release target. But eventually, we'd want to have something which could also cover parts of BSD and Hurd too. Maybe if nothing suits, we could leverage GSoC and come up with something tailored to the projects scope. But, the biggest question is if we all (as project members) see, in unison, the need for such a certification list. I think this question and the subject fits in in the broader topic of "universality". -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part
Re: Questions for DPL candidates: Support channels
hello Chris, Thank you for your response. Please see below some follow-ups. On Thu, 2017-03-30 at 15:56 +0100, Chris Lamb wrote: > Hello Ritesh, > > > Debian as a project is different than others. Most other similar projects, > > have > > a commercial backing and interest. This puts the onus on them (other Linux > > distributions) to ensure their support infrastructure is simple, intuitive > > and > > supportable. > > You raise some interesting points especially regarding fragmentation of > support. To be fair to Debian, even projects with "commercial backing" have > this issue. :) > > I think we should judge ourselves on our results and not whether X or Y > exists. In other words, it doesn't matter whether the support is operated by > paid operatives or by the community, the key question is whether our users > are acutally getting the support they need. > > However, it is very difficult to get concrete answers here. Anecdotes are > not data, but if we hear enough times that "Yeah, I tried using Debian but > my wifi/video/keyboard/smartcard didn't work, but it worked under Z…" then > we might start to question whether we are serving our users best. I admin "Support" is a much wider topic. So I'll take examples to phrase my questions. Most major hardware and software vendors have a handful of Linux distributions marked as supported, even though there's a high possibility that other distributions would work equally well. I understand marking an item "Supported" has other challenges, which is what leaves out most of the non-commercial distributions. I myself, with one of my previous employer, had challenges mentioning support. Back then, we rather chose to cook up a "Community Support Model" for Debian and similar non-commercial* GNU/Linux distributions. ISVs have improved over time. Today, 2 of the tools that I use (Crossover and Skype), do offer a Debian .deb package. On the IHV front, I am not sure if things are the same: * We have a very small list of IHVs [1] mentioning support for Debian. * We have a Debian Enterprise Mailing List [2]. But I don't see much traffic there Do you think a HW Certification Process should be available for Debian ? I see all other Enterprise Distributions (including Debian Derivatives) have a certification process in place. Should we have a Certification Test Suite (Both Hardware and Software) that our vendors could run and provide us with the results ? Such results could be validated by our Enterprise Team, and accordingly a HCL could be set up for Debian. [1] https://wiki.debian.org/Hardware/ShippingWithDebian [2] https://lists.debian.org/debian-enterprise/ * Non Commercial as in not backed by a profit making organization -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Questions for DPL candidates: Support channels
Hello DPL Candidates, Thank you for standing for the DPL position. Debian as a project is different than others. Most other similar projects, have a commercial backing and interest. This puts the onus on them (other Linux distributions) to ensure their support infrastructure is simple, intuitive and supportable. Debian, on the other hand, is limited by community support. Community Support being, "Best Effort from the Community". Also, many of the Debian Community Support channels are fragmented (IRC, ML, Ask, Forum, Web) Do you think the current support model/system in place, is good enough ? Do we need (or have room for) a different approach ? Thanks, Ritesh -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Re: Iain Lane's proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2016-09-21 at 21:17 -0500, Steve M. Robbins wrote: > I second the proposal made in https://lists.debian.org/debian-vote/2016/09/ > msg00092.html and quoted below. > I second this proposal. > > > Title: debian-private shall remain private > > The text of the GR is replaced with the following. > > 1. The 2005 General Resolution titled "Declassification of > debian-private list archives" is repealed. > 2. There shall be no declassification of any portion of the > debian-private archives, except in the following circumstances. > 2a. Participants may declassify their own material. > 2b. Participants may declassify the material of others where > consent has explicitly been given by the authors of all of the > material being declassified. > 3. Participants are reminded to use -private only when necessary. > > ============ > > Thanks, > -Steve > > - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX45QPAAoJEKY6WKPy4XVpHgQP/jzO4BeXuFewI8uQyfA3abI5 MaVctAXadV/ibXo/P6yVA2yvUvuB9ARQ1KfnR6v4kqMgEoGIraOSZMaGfiuEPmKq pnz0wLoebsW5d8QBS5upUhtHulzEKEA+WzhO6rCipYiL2eP8CM+ADPyrR0CFDyvE cyYceCWkefNdedsRjRMQhO5VNJqR17AlP+rMGttXHKSAkqWBLNaCfSiQecnt5ib9 Hir9wwxRViXMCn1gBl7pBPF8I9qNmJu87cWivZ8wD2ta7csHD8w/pkQkcu+z+5K1 jXSXZKYxup3OY6fXS638KffnjOy6AAAvqt8K2oUhyyjwxcmPBiGn1q/BBru06YEL wGplDC8FQRDOWI6f+guMVwXYANyyL81D5M5/Q5kbAG/VEwzfXqNdQTJYBBUEnIw2 n+ExUrD9Co8ZdhJU4WFAjtX6zJs2PGPmb7pODx3ntauuAorsFDRFzFP0Jb/FiFgG +DePHW5KEaABfBw1OfjzGCJrV8umTozmFCIDukWd+yxHCN5JQ9/Z9D2MQYGLrH+T WzZdxQtTStsQQ2UeneiHEIvI9r9fpP59An00GHEnvelAV1707TcWdi1KauvcLUBa cp34JHXagjTXQaWZjRMe4jQKJFrJ/mIz/0ROG2ABPbHyHEgzbsVGRIHcYU1m4Ygf mDGj+IR8UXT57b7b7hom =bOEg -END PGP SIGNATURE-
Re: Debian Project Leader Elections 2015: Correct ballot
GINaSMhiHa1HTLTFIa > nr+T5vbni14bMMAhuzL/nNiROqGm3DpBqu+MqXFMl7KpoBuY/fHmBSSiQ0pVMnhN > sazg8XZunPHrIW2TBvdozYjTHioZPPYL1PtG7Q6X9hdid8u5z0Gtt8OwrF1RpwSF > 0H69trBL7BlltgcAF4oW5IqikQ3OEwu66aMdcu/WbL9sQvTjrsSc8qHh/QARAQAB > tCpEUEwgdm90ZSAyMDE1IDxsZWFkZXIyMDE1QHZvdGUuZGViaWFuLm9yZz6JAj4E > EwECACgFAlUbIAkCGwMFCQAXuwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ > EMqaX6zYUX5vszIP/3VMgSI72JGaLKmDJ1XPdP51mXcAW3VtJc0d6L65Vah08DYk > KnLd2eRyR3NXZlAoTMeIWI5ani3BwfT6cUH99hYbxLjiecW3TPZUfN9fer+etKWm > 9jPqOjqJf6Sx7XCGqCBrLUUhfjvHO6HpSr11H+jJ77STo4p8ihiURLD7EUs6dqHj > YRp7HkCi83Ol7MvwEPqG6B7ZqMfD8k6QmK8Az/Va4JC2bKj/kHCVMoXZiLulVxsC > xgqlau52duXbF6Qbz1evpoAlvfMraqspq2YoLBugh9dNlVMUAzNU+TWynon9puIe > ExfLEDGQ9REnO37L4DB+ymEtrKeQsopvSfgb9WmVbenSv+3K7PNnfJLbSHLhg5hu > LTOgz4cbd3FIfg7W9td7nXhQ68CPVpRg80Soa1ZLwxeCLdG3DOoB1+khc3Gx5PgJ > vSk+3FjT6e+teRmPu2ZKTTAskxkV3eUGV5kfDuVhfMQD6HG3e7HB37ZcFAbX9JUt > dViHQj7X/jeQpGhnZ7FmodDJjObxUcgqtmY0K0b3B+jEwPudoXeKCmF7lKdVQOeI > kvXlVlx0J6u7d0+Qty96hRxASomGGR8kR/zsDRfEV2TyzjpXfhrTikVyIrj+lp27 > fOwHZCDzpTdy6ENYH3s0ZrljtyFCTjfnmISo/k1A9a7Ikir2Sp1U8U7EaCwjiQIc > BBABCgAGBQJVGyBVAAoJECBkxTZBwl5d6R4QAIDks9M91QjjMMisWAYmmDbQUIt0 > xT6wGDyNw0/nBQdBhuAWoV+/pFFirdlV+xuLPSSptg9pGkI2hWEM8+OQJzj4HGqx > CDUYiK1Q8cA0OgMrl0oFAfBq9UinNSg28NHIHbJputDEVVbLDfqBPmfwg5ylKXJj > i/E7EWrwtZSnfG1sXjfUV/zvPXbz63+3Dw+iUHhK/beNH2mqducnC1Oo4m7TshRM > kTzOQ2uoLxAhXqdj+YZuJn2bJwwtdh9kV95CeX6ysnuqJzjfvTf93BepgjfrF84p > QumiOWP3k0JC9jXccR+1IdN08Rd9o8QetPAYJmtTlgB+U9dVNK3owrJr9ibaF+CB > PpkOKktMpAD12PxgBlZI4//dj7T0grEJeeWmxinE2pABJLB/WCJGpD1IvLEGj3OM > jKgh20xyCj7gkgJFJs8gNgxamh4azJV6Bdw3rb8CXPVZbcpzZHuT4p8SvnNL0DHh > KxpT+q3XPx8MAwRUZ2OS+A0+XRtWfd9jJJR9HNtUh4mYJH/a8ieqA6dx8MjIjzn/ > CXecvPRFOH7UHQuBO9AANo3cfooGNh9m/bfY6VJFmaEslgcorOXQMcj4NGUpWl02 > +VhTlIG/Xd7CDtUT4RjVC8d0s5SyjNRbiM5kmXilhu6mGd0jVK78oEbkUEAe+cCx > S2iguLt4g3FUCky1uQINBFUbIAkBEADDzsnNgkId12AsWdGl4wOD6ab/HpoC6RC4 > tYKWOGECz74f2M381vbgzTdmLXES7dQ7KuBGBkSBaz4D00I1NKNhtmOiO2CfOy0O > soARu0QPR2oHfhSP+KAL4lZXcZlM3Xy4tgYzMOuda6US9FLF4DvAymaLrSdl8ETj > uw2FifA/OoLLedIs24hZrFnUA3S4m1wJKidO2dNLHlMgfC0dNVBW9BJThX/RzxGB > 8gV43sqZfZWtWqEYJ6PnfmYnryN7HARtWxKHt9XEolG77f6F+004wmlUlhL++RF2 > 1CC87wEV86kdjr56Rbl596ghAnXPc7g8V7C7ApxW1SXoc8Vb+YknpRkcoe25UKnD > BrKEMfZDNx48tmPfqjPf0joZI3bGzGxUkD9amsvqAI38ac2tDJRM3EshMWJ2lHo+ > zCUSovT6ZB8zX3h49mbeijDasz/vjBRirnW0iOqMdklrWuwOqlgviSjxsFk8m1Ao > aCW9ixjeaJYl5jyJY5VMokPBFcd8emWVs67FrysaeFLrXyM/ssBST5fsMX6gRwcU > vWDouG4w/S0c+N8KKp2he9N2Jyr40os7FMbJHORamXQRlXx91rNzMoWPy71ITY1+ > nPtrkwDdp5UQ9C68FcqLC/cpvx247jQBYHSaBDNWgIywD5c0dl7lanLihO9IEG0a > jYIxFvlbCwARAQABiQIlBBgBAgAPBQJVGyAJAhsMBQkAF7sAAAoJEMqaX6zYUX5v > udAQAKa78Ff+1qPQC2BL4ien4DFJor3qZTP5T4wsuVq3yw1Vib/hiRAUj8/rlLs+ > f0+Ik5PH6e7/mcfsiI/kYemmys4VfYMr8j9RnqZa3STkH2oU1N+ZlCjcyh9YpAdm > MnZo25v/iWQQLNkg5xndiuSBr3D7jGrVNUukIwwAgx+KACspYNo6/RjmH+3VYJ/k > s5wHdkV/rZrszpLe60QyleQJyRekeIRKFtKWvikNAbmto5Ya27QpLXqJ2pd50FcK > k6OsBAUG5jsyiG+fkTUf822H/aVhnrlzUpIwPIgh3FItjrCe6BAj69CLtK1fWNAD > 1uXY3MDM4pYlZ0cWYb/lM+geeBtMLgKbdWE+uqnYwyx34c7iXl5GH9995ryg1eUB > RLMfgvTkK43XasvLZjcvrrRpp+Ti6cTcF9U4Og/OT7I6SlOHyTPyQlXl63ay/W6G > 917KTZDp23hMDytejJZUl0Fp56Ea5+acYMNrZT5H4Cr9xvVu1ZiM77jUQqkWONZW > oePNMUjsILDtW0rgOamlANWrgY7zCsBzURYsVakC+G4bQMYIGPQpLNDIXiaEKvYk > 132qYsyIomiGOxL4/j7LcRyEFCDGKlCXMBFxgFgeUhixLIYR2MDQSgeDX5ICidkp > 8XmoXft0//xb4zgVWnjvDaA36ZrOxZKpPdETUGGphm+eXMR5 > =BNHi > -END PGP PUBLIC KEY BLOCK- > -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Re: Tentative summary of the amendments
In the entire systemd conversation, there's hardly been any discussion about non-desktop stuff. Or has there ? I may have missed. I've mentioned this previously in some of the bug reports, maybe do here too. How are other packagers taking care of it ? There are a lot of server daemons that need some sort of housekeeping. What I can recall immediate are: mysql, open-iscsi, DM multipath etc.. Last feedback (IIRC _not_ from the systemd maintainers) I had on it was to write a shell script, and call it from the systemd unit. I just checked my mysql server package, and it is not shipping any systemd service file. Is it just a matter of time that they will start shipping ? Are we reaching out to all affected parties ? An init system touches a lot of other components in an OS, not just the desktop interface to sleep/hibernate/reboot/shutdown. On Fri, Oct 24, 2014 at 6:32 PM, Aigars Mahinovs wrote: > On 24 October 2014 15:33, Olav Vitters wrote: > > On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote: > >> No, but we set up requirements that their work must meet before it can > >> enter archive or may end up in a release. That is what the whole of > >> Debian Policy is about. > > > > That is things within the package itself. This is about doing extra > > work. In case you rely on functionality which is only provided by one > > init system, ensure the functionality is also available on other init > > systems. > > That is not what is actually required. It is sufficient to handle the > situation when such functionality is not available. That is inside the > package and it has many different uses (different init, no init, > restricted chroot, system in some weird state, API changed, ...). You > can even hide that code behind a command-line option or a > wrapper-script (so you don't have to detect availability of feature > and instead rely on being called with a special option or name when > extra functionality does not exist). No one is forcing you to > implement features into another init system, so that is a strawman. > -- > Best regards, > Aigars Mahinovsmailto:aigar...@debian.org > #--# > | .''`.Debian GNU/Linux (http://www.debian.org)| > | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | > | `. `'Linux Administration and Free Software Consulting | > | `- (http://www.aiteki.com) | > #--# > > > -- > 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/CABpYwDWTeyfD2PixwTSOy5VW4sXhkq=36rmpfxhjaizd7mq...@mail.gmail.com > > -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."
Re: Re-Proposal - preserve freedom of choice of init systems
On Thursday 23 October 2014 06:08 PM, Olav Vitters wrote: > On Thu, Oct 23, 2014 at 11:55:34AM +0200, Svante Signell wrote: >> > The same applies to many upstream developers, they develop software >> > mainly for themselves, not the users, see for example the latest >> > development of Gnome. The only way to change this is by creating a large >> > enough user group taking side by refusing to use software that is going >> > in the wrong direction and promote alternatives. > This is not a "I don't like the GNOME developers" mailing list. "Going > in the wrong direction": opinion, not fact. Obviously you can use > something other than GNOME, I'd appreciate not generalizing the hundreds > people who contribute to GNOME. > > Similarly, turning not being able to vote into "Debian doesn't care for > it's users": You're free to make your case. Convince others. > That'll probably be appreciated way more than negativity. What was wrong with Svante's post ? He was just giving an example, quoting Gnome. I'd give a similar example for KDE. We believe Debian is more than just a Desktop. And for Desktop too, more than just Gnome _or_ KDE. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 06:27 PM, Aigars Mahinovs wrote: > On 17 October 2014 15:53, Ritesh Raj Sarraf wrote: >> > Why is SysV Init so unacceptable ? It is a neutral init that serves well >> > for all our sub-projects. Let that be the default choice. > Please do not conflate two very different issues. The default choice > has been decided and is not in question at this point. This is about > ensuring that SysV init (among others) is and continues to be a > *possible* choice for a user. It would be nice to know what "possible" is defined as. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 05:10 PM, Olav Vitters wrote:
>> > The world isn't just GNOME.
> The issue is bigger than just GNOME. Think of e.g. UPower. There is
> various other software which is affected by this. Requiring people to do
> your bidding is against the Debian social contract. While this is pretty
> much what the GR is about. Seems unrealistic, plus seems you're voting
> on something without knowing any specific ("just GNOME"). If you expect
> upstream/Debian packager teams to take people who cannot bother to
> inform themselves on their topic serious, then geez... good luck but
> you're heading towards a wall.
Not just UPower. UDisks, PolicyKit and many more. And if we don't take a
sensible stand, soon hostname, cron, dns, network, power etc.
In Debian, until the decision in Feb, everything worked with sysvinit.
And then eventually it broke. As we speak today, Udisk + Upower + PolKit
(experimental) does work again.
Buy my point is, things used to work neutrally. Why can't we strive to
do that?
Have the systemd support. I don't think anyone is opposing that. But
don't bring that at the cost of an alternate neutral option.
Why is SysV Init so unacceptable ? It is a neutral init that serves well
for all our sub-projects. Let that be the default choice.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 12:43 AM, Ansgar Burchardt wrote: > Aigars Mahinovs writes: >> > We have all kinds of policies about what is fine in a package and what >> > is a Release Critical bug. That is a big part of what makes a >> > distribution. This simply adds - "must be able to work with any init >> > system running at PID 1" to those requirements. > No, it does not mean packages have to work with *any* init system. It's > specifically aimed against a specific init replacement, see [1]. And for the Debian project, that *specific* init system shouldn't be systemd, in my opinion, given the breadth of sub projects we have. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 12:30 AM, Aigars Mahinovs wrote: >> If you don't like upstreams choices, *you* should write patches. Not GRs >> > telling other people to do so. > We have all kinds of policies about what is fine in a package and what > is a Release Critical bug. That is a big part of what makes a > distribution. This simply adds - "must be able to work with any init > system running at PID 1" to those requirements. Seconded. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 12:11 AM, Holger Levsen wrote: > And for what exactly? Gnome right now is installable with systemd-shim + > sysvinit, why can't this GR wait until after release when the dust has > settled? The world isn't just GNOME. > > This is a GR based on rumors, which is very sad. Now for me. systemd may be a good linux-only tool. But for Debian, as a project, for something as fundamental as an init, sticking to it is not a wise choice. If the project wants to do that, knock off all the non-Linux efforts first. As a base foundation, our choices should be things which are wide enough to embrace all our sub projects. Why didn't we do the same with network-manager ? -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thursday 16 October 2014 11:58 PM, Adam D. Barratt wrote: > Speaking for no-one other than myself, I _am_ very unhappy that given > how long the discussion has been rumbling on for, and how much > opportunity there has been, that anyone thought that two weeks before > the freeze (which has had a fixed date for nearly a year now) was the > right time to raise this. It was not intentional. Ian asked, and I expressed my opinion. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thursday 16 October 2014 11:56 PM, Ansgar Burchardt wrote: > Anyone around for the alternative choice of just one init system? In the > same spirit of just one libc? (Yeah, choice of course does not include > the C library or the kernel if it's just anti-evil-Red-Hat...) I guess we have one libc because it also serves our other ports. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
> ** Begin Proposal ** > > 0. Rationale > > Debian has decided (via the technical committee) to change its > default init system for the next release. The technical committee > decided not to decide about the question of "coupling" i.e. whether > other packages in Debian may depend on a particular init system. > > This GR seeks to preserve the freedom of our users now to select an > init system of their choice, and the project's freedom to select a > different init system in the future. It will avoid Debian becoming > accidentally locked in to a particular init system (for example, > because so much unrelated software has ended up depending on a > particular init system that the burden of effort required to change > init system becomes too great). A number of init systems exist, and > it is clear that there is not yet broad consensus as to what the > best init system might look like. > > This GR does not make any comment on the relative merits of > different init systems; the technical committee has decided upon the > default init system for Linux for jessie. > > 1. Exercise of the TC's power to set policy > > For jessie and later releases, the TC's power to set technical > policy (Constitution 6.1.1) is exercised as follows: > > 2. Loose coupling of init systems > > In general, software may not require a specific init system to be > pid 1. The exceptions to this are as follows: > >* alternative init system implementations >* special-use packages such as managers for init systems >* cooperating groups of packages intended for use with specific init > systems > > provided that these are not themselves required by other software > whose main purpose is not the operation of a specific init system. > > Degraded operation with some init systems is tolerable, so long as > the degradation is no worse than what the Debian project would > consider a tolerable (non-RC) bug even if it were affecting all > users. So the lack of support for a particular init system does not > excuse a bug nor reduce its severity; but conversely, nor is a bug > more serious simply because it is an incompatibility of some software > with some init system(s). > > Maintainers are encouraged to accept technically sound patches > to enable improved interoperation with various init systems. > > 3. Notes and rubric > > This resolution is a Position Statement about Issues of the Day > (Constitution 4.1.5), triggering the General Resolution override > clause in the TC's resolution of the 11th of February. > > The TC's decision on the default init system for Linux in jessie > stands undisturbed. > > However, the TC resolution is altered to add the additional text > in sections (1) and (2) above. > > ** End Proposal ** I second this proposal. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Re: GR: Declassification of debian-private, First call for votes (with reply to)
On Sunday December 18 2005 07:46, Debian Project Secretary wrote:
> Votinge period starts 00:00:01 UTC on December 18th, 2005.
> Votes must be received by 23:59:59 UTC on December 31st, 2005.
>
> The following ballot is for voting on a General Resolution to address
> procedures to publish posts from the debian-private mailing list.
> The vote is being conducted in accordance with the policy delineated
> in Section A, Standard Resolution Procedure, of the Debian
> Constitution.
>
> The details of the general resolution can be found at:
> http://www.debian.org/vote/2005/vote_002
>
> You may see the constitution at http://www.debian.org/devel/constitution.
> For voting questions contact [EMAIL PROTECTED]
>
> HOW TO VOTE
>
> Do not erase anything between the lines below and do not change the
> choice names.
>
> In the brackets next to your preferred choice, place a 1. Place a 2 in
> the brackets next to your next choice. Continue till you reach your
> last choice. Do not enter a number smaller than 1 or larger than 3.
> You may skip numbers. You may rank options equally (as long as all
> choices X you make fall in the range 1<= X <= 3).
>
> To vote "no, no matter what" rank "Further discussion" as more
> desirable than the unacceptable choices, or You may rank the
> "Further discussion" choice, and leave choices you consider unacceptable
> blank. Unranked choices are considered equally the least desired
> choices, and ranked below all ranked choices. (Note: if the None Of
> The Above choice is unranked, then it is equal to all other unranked
> choices, if any -- no special consideration is given to the Further
> discussion choice by the voting software).
>
> Then mail the ballot to: [EMAIL PROTECTED]
> Don't worry about spacing of the columns or any quote characters
> (">") that your reply inserts. NOTE: The vote must be GPG signed
> (or PGP signed) with your key that is in the Debian keyring.
>
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> f378e990-87f2-4670-8dd0-b227e4f4ef5c
> [ 1 ] Choice 1: Establish declassification procedure for posts to
> debian-private [ 3 ] Choice 2: Establish declassification procedure for
> future posts only [ 2 ] Choice 3: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
>
> --
>
> The responses to a valid vote shall be signed by the vote key created
> for this vote. The public key for the vote, signed by the Project
> secretary, is appended below.
>
>
> -BEGIN PGP PUBLIC KEY BLOCK-
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> mQGiBEOgLrYRBACjAM0gHv9zm9gPzhyz7tGKeN0hR67jEBOpjXIy5GMj+QnEaGWA
> 8GZMtkfZIPWyJFNfUJIpxZjJoKXUiaepby6yb1uE31rO0OwwhuCBTpsnwj8IQ3tA
> T64LagZlKqmTnl56z0w6s3PfjuIbjaEglzSP5S6wJs7Qflp+RMwz3OwyKwCgk6+I
> 5+HCsA/MqIMfqiF0FBJNq/sEAJNsjhHjYIhiqfWNk1hC3ccAYHn23l1XRe6f+eKa
> vOyN/ed5W9QlkA9iVCK+bIJpZG4vZvDMp80y3ykIz2GJ9mCMZIeIsqgoxj1tNtIV
> ZoR95WdZeF66W4kMutMnpgkv176bOEYt8Or0PCIaqZC+vlxFo0NK5qh8mF51MzK1
> whX0A/wKIWm4WcCwQuEieLvea9k0NnDl1kIKSAKWeI007BKuphUw+WGgswdeVuWk
> VuxMj7247PlObljhIoZ8wrHvo/bK9FAma2WquRWQl+f8ueciN9udsHsza8Z9NC0/
> +81npeaoIwZ87qwopuIY8QHrmVht7YymYYGPnYQxnXhIS66HTLRLRGVjbGFzc2lm
> aWNhdGlvbiBWb3RlIChFcGhlbWVyYWwgS2V5KSA8Z3JfZGVjbGFzc2lmaWNhdGlv
> bkB2b3RlLmRlYmlhbi5vcmc+iGYEExECACYFAkOgLrYCGwMFCQAqMAAGCwkIBwMC
> BBUCCAMEFgIDAQIeAQIXgAAKCRBALF9IO07gYbj4AJsG7vMpFjiZY1T5CBZC0cZo
> nR/F0ACcDdCsR4oHl9SWvwM1tYAn6T8FCbOIRgQQEQIABgUCQ6AvyQAKCRAhutq7
> vyRCTFkSAJ0Tt9LvlblXzP84w9B1hBrogB/x4wCgihQ6IlY/LtpAR6ZPP8leFIxi
> AGS5Ag0EQ6AuvRAIAKa383b33/nNe4oBD+8Lgf9kw8ByAHqgn5X0JLCmUUTaBt9d
> GOHWNKVzaBabcKEOlCqRaduL8RReqzbeHCfbk1CwrOWgkxhCcEZUuRK6tRJadETU
> E3TIBG4YKDjfvlYMmKAyYnyZ89TYcXe5GhxmXWQ50iWKphAHTbSjIvepb7MJkZBY
> FmG9LXia0CojjMFCWR74/Itjndh4XVxMpch65sJRF6196ynsNN5GCNQavZRAjt2P
> xtbhEtiI8khBxMTUBP7dDkzDjIfMRWlcLqAB2rwHLXq92KT+Qc8JZ3YsX79az15E
> 9kJ+Pi4zjxDtzIA3MIN07UAh2jWkwhRKpHXqoyMAAwUH/227wdRfPEsYtGqjaSEE
> yVyHZTgMGy0FKqkGEfXa8xAeF3ZZok46Es+Z35YlGQ2q+KjvE/Ho/jZn59ryc636
> nAB3M3gcacN64GO94h3Rziq3GOnb2kiqwIbryCbdwQ0Skw71Q0nXsm8HR0rHR58m
> dMPkoduTLuHU3c28uSdGL6CncpEzHW+ZJUnMpO0zRAlGPj4iLBbPa6Jn65knqn9C
> v2coS6HOlDVn1BmZpyd1f1i4fyZ/1TPZnZUJHQGOxlTVB8UQreSSywAP5GhPA+eB
> HH77ex2bN36oM8SZbk5p6Tp4C9ddWq/xqUXgAvVbw/IFRZM9YzPtD6vGh6srj7uZ
> tx+ITwQYEQIADwUCQ6AuvQIbDAUJACowAAAKCRBALF9IO07gYQf3AJ0f71K/UL9/
> bY5wDgfehFJzZ+8KowCdHTS3BUcGhJ3UNpd3ucdhlSphojg=
> =xSWE
> -END PGP PUBLIC KEY BLOCK-
--
Ritesh Raj Sarraf
RESEARCHUT -- http://www.researchut.com
"Stealing logics from one person is plagiarism, stealing from many is
research."
"Necessity is the mother of invention."
pgp2LmP2rO2no.pgp
Description: PGP signature
