Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
On 22/10/14 at 07:45 +0900, Charles Plessy wrote: > I propose the following replacement as per article A.1.5 of our Contitution. > > > > The Debian project asks its members to be considerate when proposing General > Resolutions, as the GR process may be disruptive regardless of the outcome of > the vote. > > Regarding the subject of this ballot, the Project affirms that the procedures > for decision making and conflict resolution are working adequately and thus > a General Resolution is not required. > > Thanks Charles. I believe this is an improvement over the previous wording. Seconded. - Lucas signature.asc Description: Digital signature
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Hi, Charles Plessy: > I propose the following replacement as per article A.1.5 of our Contitution. > > > > The Debian project asks its members to be considerate when proposing General > Resolutions, as the GR process may be disruptive regardless of the outcome of > the vote. > > Regarding the subject of this ballot, the Project affirms that the procedures > for decision making and conflict resolution are working adequately and thus > a General Resolution is not required. > > > Seconded. While I disagree with the statement that > not all questions have been answered. the above re-wording is less controversial, which is a Good Thing (in this case, at least). -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Tentative summary of the amendments
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. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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/8738agpzq9@vostro.rath.org
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
I propose the following replacement as per article A.1.5 of our Contitution. The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. Regarding the subject of this ballot, the Project affirms that the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. I'm not sure If a re-second is required. I do support this text and believe it is an improvement over the original. If it is meaningful/useful, count this message as a formal second. pgpqTifxMFVi7.pgp Description: PGP signature
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Hi Charles, On Mittwoch, 22. Oktober 2014, Charles Plessy wrote: > I propose the following replacement as per article A.1.5 of our > Contitution. > > > > The Debian project asks its members to be considerate when proposing > General Resolutions, as the GR process may be disruptive regardless of the > outcome of the vote. > > Regarding the subject of this ballot, the Project affirms that the > procedures for decision making and conflict resolution are working > adequately and thus a General Resolution is not required. > > > > I avoided terms like “premature” and “at this time”, since they leave a bit > of an impression that a GR will definitely be needed, but only later. > This is one of the main resons for my initial reluctance to accept > Antony's and Lucas' comments. I like this changed version indeed much more, thanks a lot for your work on this! Writing short texts well is almost an art ;-) (I don't think I need to formally second this, but if I do, I hereby am. Please tell me still, I have tiny doubts :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Maximum term for tech ctte members
Anthony Towns writes: > On Tue, Oct 21, 2014 at 08:34:28AM -0700, Don Armstrong wrote: >> I think rotation is a good idea. My main minor concern is that it >> doesn't allow reappointing members to the CTTE if there are no >> nominees whom the DPL and CTTE finds acceptable (or even if there are no >> nominees at all). > > In that event the ctte would have 6 people rather than 8 for 12 months, > at which point the two expirees could be reappointed. (Though another > 2 might expire then, keeping it at 6 members) While not fatal, that doesn't seem particularly desirable. > I don't think there's a shortage of potential candidates > in Debian, so on that score I don't think it's likely there won't be > sufficient acceptable nominees. I agree. Bdale pgpRf5MYblnHy.pgp Description: PGP signature
[Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Le Tue, Oct 21, 2014 at 08:13:52PM +0200, Holger Levsen a écrit : > > On Dienstag, 21. Oktober 2014, Sam Hartman wrote: > > my response is "so what? People are doing their jobs, let's not get in > > their way." > > I'd rather this amendment not push people away simply because they > > disagree over whether all the questions have been answered. > > I agree. I've also been thinking whether I find the distinction pointed out > by > Lucas to be so important as to offer another amendment if Charly doesnt want > to change his... I'd definitly prefer to have this statement once on the > ballot than twice. So, Charles? Indeed, you are right: by definition, not all questions have been answered. The existing wording of the amendement is therefore logically inconsistent. I propose the following replacement as per article A.1.5 of our Contitution. The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. Regarding the subject of this ballot, the Project affirms that the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. I avoided terms like “premature” and “at this time”, since they leave a bit of an impression that a GR will definitely be needed, but only later. This is one of the main resons for my initial reluctance to accept Antony's and Lucas' comments. If further changes are needed, please suggest a full replacement: I am reaching the limits of my writing skills in English (an again: a GR that requires near-native fluency in English because the consequence of the vote will strongly depend on how the text is interpreted is anti-democratic in Debian). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Hi debian-vote, The below poster redirected their response to my off-list mail back to the list. I explicitly mailed them off-list and with a reply-to of only myself set in order to avoid further list noise, and because they seemed like they were genuinely confused. I now see that they had an agenda and that there's nothing I can say to alter it, so I'll leave it there. I am sorry that this got back onto the list. Cheers, Andy On Tue, Oct 21, 2014 at 01:46:44PM -0700, ss-compo...@marks.org wrote: > Andy, > > Thank you for the email. > > << You can currently use Debian without systemd as long as no package you use > depends on systemd. >> > > That "depends on systemd" hook is a primary objection for those of us who > know better. Why should a non-init package depend on a particular init > system? etc. -- 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/20141021211606.gf27...@bitfolk.com
Re: Re-Proposal - preserve freedom of choice of init systems
Andy, Thank you for the email. << You can currently use Debian without systemd as long as no package you use depends on systemd. >> That "depends on systemd" hook is a primary objection for those of us who know better. Why should a non-init package depend on a particular init system? Only systemd initialization-related packages should depend on systemd. Non-systemd packages currently depend on systemd due to the direct efforts of systemd supporters. Lennart Poettering himself is pushing to get packages dependent on systemd: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html The reason why Mr. Pottering resorts to such tactics is because: 1. locking packages upstream FORCES the use of systemd by anyone wanting to use that package; 2. systemd would surely fall flat on its face, were it to attempt to advance on merit alone. Sorry, but such unscrupulous manipulation has to stop before things get out of hand. I want to install that unnecessarily systemd-dependent package on my non-systemd machine! << systemd is not Essential level of priority in Debian. >> Debian's major (and contentious) switch to systemd indicates otherwise. << There are no plans by Debian to change that fact. See http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html for example. >> Thank you for the link. I love this line from the page: ***"However, notice that there are some programs such as login managers (e.g. gdm3) which have an upstream dependency on systemd. gdm3 links against libsystemd0 and depends on libpam-systemd; and the latter depends on systemd-sysv | systemd-shim SO IT IS IN FACT A SOFTWARE SUCH AS GNOME THAT IS PULLING SYSTEMD ONTO YOUR COMPUTER."*** However, the above linked post from Lennart Poettering proves that it was he who initiated Gnome's dependency on systemd. So, on the one hand, the systemd apologists are implying that it is not systemd's fault that upstream software depends on it, while, on the other hand, the systemd supporters are pushing for such upstream dependencies on systemd. That's a slimy, two-faced approach. Those of us not who are not sold on systemd can only assume that the amount of effort that the systemd camp puts into such connivances is inversely related to the amount of effort that they put into proper coding. Also, given the prevalence of such deception above, how can we trust anything that comes from the systemd supporters (including systemd itself)? In regards to steps that your linked page suggests, anything can be hacked (except, perhaps, a non-systemd package's dependency on systemd/pid 1). I can run Debian packages on Slackware, Gentoo, Arch, etc. However, I and many, many others don't want to bother with such rigmarole. I'll tell you what -- why don't we go back SysV init as the Debian default, and then, the systemd users can take steps such as those proposed on your linked site. Don't like that proposal, do you? You be the one to have to do extra work to set-up and maintain your init system. Furthermore, you would probably lose those precious upstream dependencies on systemd, as the upstream developers would have to remove them, given that the major players (Red Hat/Arch, Debian, Slackware, etc.) are using various init systems. And again, if I were to follow the instructions on your linked page, how do I run that systemd-dependent package on my non-systemd machine? Regards, -DM > Hello, > > On Mon, Oct 20, 2014 at 06:55:42AM -0700, ss-compo...@marks.org wrote: > > In fleeing systemd, I have left Debian and am currently running Slackware. > > I won't use Debian again, unless I can do so without systemd. > > You can currently use Debian without systemd as long as no package > you use depends on systemd. systemd is not Essential level of > priority in Debian. There are no plans by Debian to change that fact. > > See > http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html > for example. > > Spreading the idea that Debian is forcing you to use systemd is > spreading falsehoods. > > Cheers, > Andy > > -- > http://bitfolk.com/ -- No-nonsense VPS hosting -- 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/20141021134644.036e3...@darkstar.example.net
Re: [Call for seconds] The ???no GR, please??? amendement.
Hi, On Dienstag, 21. Oktober 2014, Sam Hartman wrote: > my response is "so what? People are doing their jobs, let's not get in > their way." > I'd rather this amendment not push people away simply because they > disagree over whether all the questions have been answered. I agree. I've also been thinking whether I find the distinction pointed out by Lucas to be so important as to offer another amendment if Charly doesnt want to change his... I'd definitly prefer to have this statement once on the ballot than twice. So, Charles? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Maximum term for tech ctte members
On Tue, Oct 21, 2014 at 08:34:28AM -0700, Don Armstrong wrote:
> I think rotation is a good idea. My main minor concern is that it
> doesn't allow reappointing members to the CTTE if there are no
> nominees whom the DPL and CTTE finds acceptable (or even if there are no
> nominees at all).
In that event the ctte would have 6 people rather than 8 for 12 months,
at which point the two expirees could be reappointed. (Though another
2 might expire then, keeping it at 6 members)
> Not allowing people to be reappointed if there are nominees and they're
> just not acceptable may be a design goal, but not allowing reappointment
> if there are no nominees does not.
I could easily see "acceptability" being defined so that automatic
reappointment is a matter of course ("they're the most experienced
candidates!", "we know them and trust them!"). Avoiding reappointmnet
as a matter of course is a design goal.
For more generous definitions of acceptability ("really smart", "knows
lots about Debian", "willing to work in a team", "can deal well with
disagreements"), I don't think there's a shortage of potential candidates
in Debian, so on that score I don't think it's likely there won't be
sufficient acceptable nominees. YMMV, of course. (And maybe "willing
to put up with the conflict and BS that makes its way to the tech ctte"
would narrow the field more).
Cheers,
aj
--
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/20141021175436.gb18...@master.debian.org
Re: [Call for seconds] The ???no GR, please??? amendement.
> "Charles" == Charles Plessy writes: Charles> Thanks Anthony and Lucas for your suggestions. Even if it Charles> can be improved, I am reluctant to change the wording of Charles> the amendement, given that the whole point is a) to say Charles> that a GR is unwelcome, and b) to reduce as much as Charles> possible the “attack surface” on the voted text in case Charles> some people want to use it to continue arguing after the Charles> vote. I've already seconded this and will vote for it. I do think I'd feel slightly more comfortable with a statement that the existing processing were working adequately than a statement that the question has already been answered. See, I'm not actually sure that all the questions surrounding init systems have been answered. I think people are busy doing the work to answer them though and nothing needs project-level intervention. Lucas's analysis is correct; there are questions that would be answered by this GR that seem to be answered no where else formally yet. my response is "so what? People are doing their jobs, let's not get in their way." I'd rather this amendment not push people away simply because they disagree over whether all the questions have been answered. -- 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/014933c4b6eb-dafbeaaf-d917-447f-9a2d-dd68ba85fa95-000...@email.amazonses.com
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, 2014-10-16 at 16:05 +0100, Ian Jackson wrote: > I wish to propose the following general resolution, and hereby call > for seconds. This GR resolution proposal is identical to that > proposed by Matthew Vernon in March: > https://lists.debian.org/debian-vote/2014/03/msg0.html > and the substantive text is that which was drafted for the purposes of > the technical committee's vote (where they decided not to pass a > resolution on the subject). > > IMO developments since March show that the concerns put forward then > were well-founded. Following discussions elsewhere including -devel I > have received enough offers of seconds by private email. > > As Matthew said, I don't think further lengthy discussion of the > issues is likely to be productive, and therefore hope we can bring > this swiftly to a vote. This is particularly true given the impact on > the jessie release. > > Thanks, > Ian. > > ** 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 ** > -- > > Seconded. signature.asc Description: This is a digitally signed message part
Re: Maximum term for tech ctte members
On Tue, Oct 21, 2014 at 05:21:04PM +0200, Stefano Zacchiroli wrote: > FWIW, I found the original wording about this part from > https://lists.debian.org/debian-project/2014/06/msg00026.html > much easier to follow, but it might be a non-native speaker failure on > my part. Hmm, aren't a majority of Debian devs non-native English speakers anyway? I was worried that the "two or more .. members have either X or Y" phrasing might be ambiguous if there was one member who matched X and a different member who matched Y. > > +When the Committee is fully populated, it is expected this > > +will result in a turnover of 1 or 2 members each year, whether by > > +resignation or term expiry, while allowing senior members to stay > > +on if a junior member resigns. > Does this really belong to the constitutional text? "Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt." -- from appendix B in the constitution. > It is good to > document the underlying principle/expectation of this change, but having > it in the GR text (but still not in the constitution itself) would be > good enough IMO. Given the convoluted wording, I think it makes sense to have a bit of an explanation in the text itself, and not just in the GR. On Tue, Oct 21, 2014 at 05:43:47PM +0200, Stefano Zacchiroli wrote: > On Wed, Oct 22, 2014 at 12:08:33AM +1000, Anthony Towns wrote: > > +At this time, any member of the > > +Technical Committee who was most recently appointed 54 or more months > > +prior will ordinarily have their term automatically expire. > About this, I wonder if the text should specify in which order expiries > are to be processed, e.g., most recently appointed members last. Take the current members, Ian, Bdale, Steve, Andi, Russ and Don are all over five years and are in roughly that order of seniority iirc. On Jan 1st 2015, assuming no resignations, then: - Andi: 2x current, longer serving members (Bdale and Ian) - Bdale: 1x current, longer serving member (Ian) --> expired - Colin: under 4.5 years - Don: 4x current, longer serving members (Bdale, Ian, Steve, Andi) - Ian: no longer serving members --> expired - Russ: same as Don - Steve: same as Andi ie, I guess I was thinking that were all considered simultaneously so ordering wasn't relevant. There could be a minor cascade effect though I guess. If, say, Colin resigns, you might get something like: - 2014-10-23: Colin resigns to found forkubuntu.org - 2015-01-01: Ian's term expires - 2016-01-01: Bdale, Steve, Andi's terms expire - 2017-01-01: Russ and Don's terms expire - 2018-01-01: no one expires! - 2019-01-01: Keith's term expires because while there'd be three people's terms expiring in 2016, both Andi and Steve would only have Bdale as more senior, since they were appointed at the same time. Oh, hey, since there's already math in the constitution, maybe it would work to say something like: Membership of the Technical Committee is automatically reviewed on the 1st of January of each year. At this time, the terms of the N most senior members automatically expire provided they were appointed at least 4.5 years ago. N is defined as 2-R (if R < 2) 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 twelve months. A member of the Technical Committee is said to be more senior than another if they were appointed earlier, or were appointed at the same time and have been a member of the Debian project longer. In the event that a member has been appointed more than once, only the most recent appointment is relevant. ? It's getting closer to source code than English at that point, but... (I'm not sure the second paragraph there is actually needed; could probably just rely on the secretary or the ctte itself to interpret "seniority" and disambiguate "appointment" sensibly.) (I believe the above would declare Steve senior to Andi, and Don senior to Russ) Cheers, aj -- 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/20141021174128.ga18...@master.debian.org
Re: [Call for seconds] The “no GR, please“ amendement.
On Sun, Oct 19, 2014 at 11:29:21PM +0900, Charles Plessy wrote: > --- > > The Debian project asks its members to be considerate when proposing General > Resolutions, as the GR process may be disruptive regardless of the outcome of > the vote. > > Regarding the subject of this ballot, the Project affirms that the question > has already been resolved and thus does not require a General Resolution. > > --- Seconded. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
-- L.S.C.A. Francisco González Flores Redes y Comunicaciones CDE PRI Chihuahua
Re: Maximum term for tech ctte members
On Wed, Oct 22, 2014 at 12:08:33AM +1000, Anthony Towns wrote: > +At this time, any member of the > +Technical Committee who was most recently appointed 54 or more months > +prior will ordinarily have their term automatically expire. About this, I wonder if the text should specify in which order expiries are to be processed, e.g., most recently appointed members last. It seems to me that without a pre-defined ordering you might have scenarios in which, in the absence of consensus about who should step down, more members than desired will automatically expire. (Although that might be by design.) And yes, this might be seen as procedural paranoia, but the Constitution is precisely the place where one wants to be paranoid. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
I think rotation is a good idea. My main minor concern is that it doesn't allow reappointing members to the CTTE if there are no nominees whom the DPL and CTTE finds acceptable (or even if there are no nominees at all). Not allowing people to be reappointed if there are nominees and they're just not acceptable may be a design goal, but not allowing reappointment if there are no nominees does not. On Wed, 22 Oct 2014, Anthony Towns wrote: > + > +A Developer is not eligible to be appointed to the Technical Committee > +if they have been a member within the previous 12 months. > + > + [...] > + > + > +Membership of the Technical Committee is automatically reviewed > +on the 1st of January of each year. At this time, any member of the > +Technical Committee who was most recently appointed 54 or more months > +prior will ordinarily have their term automatically expire. However, > +a member's term may be extended until the next review provided Probably should be "will be extended" instead of "may be extended". > +there are at least two other members, each of whom who either (a) > +are a current, longer serving member of Technical Committee, or (b) > +resigned from the Technical Committee, or were removed or replaced > +since the previous review. > + > +When the Committee is fully populated, it is expected this > +will result in a turnover of 1 or 2 members each year, whether by > +resignation or term expiry, while allowing senior members to stay > +on if a junior member resigns. > + > There was also some discussion of this during the CTTE meeting too: http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-07-31-16.58.log.html Thanks for drafting this. -- Don Armstrong http://www.donarmstrong.com Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 -- 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/20141021153428.gm28...@teltox.donarmstrong.com
Re: Maximum term for tech ctte members
On Wed, Oct 22, 2014 at 12:08:33AM +1000, Anthony Towns wrote: > Moving from -project. Reference: > https://lists.debian.org/debian-project/2014/05/threads.html#00054 > > Like I said, I'd rather provide a second than make a proposal, but at > debconf Stefano [0] said he'd appreciate some sample wording, so > here's what I came up with, based on where I was thinking when the > thread on -project sputtered out. > > [0] I'm pretty sure it was Stefano, my memory of that night's possibly > kinda blurry... Yeah, that was me. Thanks a lot for this draft! In general, it looks good to me and I'd be happy to second something along these lines. A few comments: > + > +Membership of the Technical Committee is automatically reviewed > +on the 1st of January of each year. At this time, any member of the > +Technical Committee who was most recently appointed 54 or more months > +prior will ordinarily have their term automatically expire. However, > +a member's term may be extended until the next review provided > +there are at least two other members, each of whom who either (a) > +are a current, longer serving member of Technical Committee, or (b) > +resigned from the Technical Committee, or were removed or replaced > +since the previous review. FWIW, I found the original wording about this part from https://lists.debian.org/debian-project/2014/06/msg00026.html much easier to follow, but it might be a non-native speaker failure on my part. Still, I hereby AOL your call for simpler phrasing here :) > +When the Committee is fully populated, it is expected this > +will result in a turnover of 1 or 2 members each year, whether by > +resignation or term expiry, while allowing senior members to stay > +on if a junior member resigns. Does this really belong to the constitutional text? It is good to document the underlying principle/expectation of this change, but having it in the GR text (but still not in the constitution itself) would be good enough IMO. > I know there's been some talk that maybe this is something the ctte > should just handle themselves; my view is that it's better to have > something that just takes care of it in a "good enough" way without > having to take specific actions (which can be missed or > procrastinated) or having the people involved having to think about it > in detail (whether that means bikeshedding the process or weight it > against "oh, but I have a couple more things I just have to do while > on the ctte"). Very much agreed. Nonetheless, before formally calling for seconds, it would be nice to solicit comments from current tech-ctte members on the latest and greatest draft of the GR text. Thanks again, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
I support this proposal, and if that was intented as a formal proposal I'd probably second. I'd also support: * making this something the TC decides for themselves with your wording as an initial condition I do think rotation in bodies like the TC is really good both for the members' personal development and for the project as a whole. I have experience with this in a number of volunteer and standards organizations and I think it works out well to have this sort of rotation. --Sam -- 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/0149331d4496-2ab6c505-1661-47c3-979e-2a430b3f3352-000...@email.amazonses.com
Re: [Call for seconds] The ???no GR, please??? amendement.
Thanks Anthony and Lucas for your suggestions. Even if it can be improved, I am reluctant to change the wording of the amendement, given that the whole point is a) to say that a GR is unwelcome, and b) to reduce as much as possible the “attack surface” on the voted text in case some people want to use it to continue arguing after the vote. The discussion in this GR falls short of concrete examples of a) what is wrong in Jessie, b) how it should be corrected and c), why would a GR be needed. The burden of the proof is on the side that asks for a GR, not the reverse. If there is not concrete problem to solve, there should be no vote. I consider this GR strongly anti-democratic and anti-doocratic. The different amendements require digging in long, noisy threads to assess what is the common understanding of them (and thanks Lucas for your summary, but it did not help me to have a clear picture of what would be the most likely concrete consequence (that is, not “what the rules are”, but “how the system runs“) of voting each amendement). This makes the GR anti-democratic since the safest choice becomes to vote by the names of who proposed and seconded an amendement rather than by the contents of the amendement itself. And it is anti-doocratic since it lays general principles for the Jessie + 1 release without even giving a chance for the people who will do the work to prepare this release in a brilliant way that does not require the project to constrain their choices. [I can not beleive I spent an hour writing this short text; I hope it is my last email related to this GR.] Cheers, -- 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 Archive: https://lists.debian.org/20141021143145.ga21...@falafel.plessy.net
Maximum term for tech ctte members
Hey, Moving from -project. Reference: https://lists.debian.org/debian-project/2014/05/threads.html#00054 Like I said, I'd rather provide a second than make a proposal, but at debconf Stefano [0] said he'd appreciate some sample wording, so here's what I came up with, based on where I was thinking when the thread on -project sputtered out. https://lists.debian.org/debian-project/2014/06/msg00026.html --- constitution.cur.wml +++ constitution.wml @@ -507,11 +507,33 @@ appointment. + +A Developer is not eligible to be appointed to the Technical Committee +if they have been a member within the previous 12 months. + + If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. + + +Membership of the Technical Committee is automatically reviewed +on the 1st of January of each year. At this time, any member of the +Technical Committee who was most recently appointed 54 or more months +prior will ordinarily have their term automatically expire. However, +a member's term may be extended until the next review provided +there are at least two other members, each of whom who either (a) +are a current, longer serving member of Technical Committee, or (b) +resigned from the Technical Committee, or were removed or replaced +since the previous review. + +When the Committee is fully populated, it is expected this +will result in a turnover of 1 or 2 members each year, whether by +resignation or term expiry, while allowing senior members to stay +on if a junior member resigns. + 6.3. Procedure Debian's birthday came and went, so Jan 1st seems the next most obvious flag day. 54 months is 4.5 years; if you get appointed to the ctte in January after someone else resigns or expires, you term won't expire until January 4 years and 11 months away, whether the limit is 48 months or 59 months, so using the midpoint means expiries happen in the range of 4.5-5.5 years which I think works out okay. The above's as simple as I could make the phrasing. If someone else can do better, please do :) I know there's been some talk that maybe this is something the ctte should just handle themselves; my view is that it's better to have something that just takes care of it in a "good enough" way without having to take specific actions (which can be missed or procrastinated) or having the people involved having to think about it in detail (whether that means bikeshedding the process or weight it against "oh, but I have a couple more things I just have to do while on the ctte"). Cheers, aj [0] I'm pretty sure it was Stefano, my memory of that night's possibly kinda blurry... -- Anthony Towns -- 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/cajs_lcwberpe_tgh4uqcetpmf9wkn4mism9ao-5iqipbvyk...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, On 16.10.2014 17:05, Ian Jackson wrote: > I wish to propose the following general resolution, and hereby call > for seconds. [...] > ** 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 ** > Seconded. I say no to systemd dependency. I want to be able to choose myself what init system to use in my Debian setup. Regads, Sergey -- 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/cabtsbtp+bxpxwf8o23r1hxdftbsu_kvhhah5m2_rkdznquq...@mail.gmail.com
Tentative summary of the amendments
Hi, I updated my previous mail breaking down the various proposals in questions, and published it online [1]. [1] http://www.lucas-nussbaum.net/blog/?p=845 I'm copying it below. I tried to make an accurate and objective summary; if I'm wrong, please correct me. I'll update the blog post accordingly. Lucas >8 This is an update of [1]my previous attempt at summarizing this discussion. As I proposed one of the amendments, you should not blindly trust me, of course. :-) First, let’s address two FAQ: What is the impact on jessie? = On the technical level, none. The current state of jessie already matches what is expected by all proposals. It’s a different story on the social level. Why are we voting now, then? Ian Jackson, who submitted the original proposal, explained his motivation in [2]this mail. We now have four different proposals: (summaries are mine) * [iwj] Original proposal (Ian Jackson): Packages may not (in general) require one specific init system ([3]Choice 1 one this page) * [lucas] Amendment A (Lucas Nussbaum): support for alternative init systems is desirable but not mandatory ([4]Choice 2 one this page) * [dktrkranz] Amendment B, probably (Luca Falavigna): Packages may require a specific init system ([5]Choice 3 one this page) * [plessy] Amendment C, probably (Charles Plessy): No GR, please; already resolved ([6]Choice 4 one this page) [plessy] is the simplest, and does not discuss the questions that the other proposals are answering, given it considers that they already have been resolved ([7]even though I disagree with this analysis). In order to understand the three other proposals, it’s useful to break them down into several questions. Q1: support for the default init system on Linux A1.1: packages MUST work with the default init system on Linux as PID 1. (That is the case in both [iwj] and [lucas]) A1.2: packages SHOULD work with the default init system on Linux as PID 1. With [dktrkranz], it would no longer be required to support the default init system, as maintainers could choose to require another init system that the default, if they consider this a prerequisite for its proper operation; and no patches or other derived works exist in order to support other init systems. That would not be a policy violation. (see [8]this mail and [9]its reply for details). Theoretically, it could also create fragmentation among Debian packages requiring different init systems: you would not be able to run pkgA and pkgB at the same time, because they would require different init systems. 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) To the user, that brings the freedom to switch init systems (assuming that the package will not just support two init systems with specific interfaces, but rather a generic interface common to many init systems). However, it might require the maintainer to do the required work to support additional init systems, possibly without upstream cooperation. Lack of support is a policy violation (severity >= serious, RC). Bugs about degraded operation on some init systems follow the normal bug severity rules. A2.2: packages SHOULD work with alternative init systems as PID 1. (in [lucas]) This is a recommendation. Lack of support is not a policy violation (bug severity < serious, not RC). A2.3: nothing is said about alternative init systems (in [dktrkranz]). Lack of support would likely be a wishlist bug. Q3: special rule for sysvinit to ease wheezy->jessie upgrades = (this question is implicitly dealt with in [iwj], assuming that one of the supported init systems is sysvinit) A3.1: continue support for sysvinit (in [lucas]) For the jessie release, all software available in Debian ‘wheezy’ that supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. A3.2: no requirement to support sysvinit (in [dktrkranz]) Theoretically, this could require two-step upgrades: first reboot with systemd, then upgrade other packages Q4: non-binding recommendation to maintainers = A4.1: recommend that maintainers accept patches that add or improve support for alternative init systems. (in both [iwj] and [lucas], with a different wording) A4.2: say nothing (in [dktrkranz]) Q5: support for init systems with are the default on non-Linux ports A5.1: non-binding recommendation to add/improve
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On 21/10/14 at 08:21 +, Anthony Towns wrote: > On Mon, Oct 20, 2014 at 11:55:30PM +0200, Lucas Nussbaum wrote: > > On 20/10/14 at 22:26 +0200, Arno T?ll wrote: > > > That's - I think - a good default and affirms Debian's point of view > > > that the respective maintainers can judge best what's a good requirement > > > for their packages. Finally I encourage everyone to focus on the > > > connotation in Luca's amendment. It allows maintainers to tie their > > > software to a particular init system only as a last resort when > > > absolutely necessary - not by pure choice, or by laziness. > > > > I disagree with this interpretation. > > We have processes in place in Debian to deal with such last resort > > situations: > > - someone opens an RC bug against the package, stating why it is > > unsuitable for release > > - the release team reviews the bug, and might (or not) mark it with the > > jessie-ignore tag > > This seems mistaken to me -- issues shouldn't have to be release critical > to be reviewed, or go through the release team. I would have said the > process should be: > > - discussion happens on -policy or -devel about what the best approach >on some issue is > - someone opens a bug against the package that takes a less effective > approach > - the maintainer reviews the bug and takes whatever action they consider >appropriate > - further discussion happens on the bug, -policy or -devel or similar > - as a last resort, the matter is escalated to the tech ctte for review > > I don't think there's a need for that process to involve blocking a > package from release, or any necessity to distract the release team from > coordination issues to participate in resolving technical conflicts. I understand this GR amendment as: - the policy is that packages must support the default init system - but as a last resort option, the maintainer can decide to drop this support This is a situation where everybody agrees that the package does not meet our policy and that an RC bug is appropriate, but where there's no real technical solution. That is quite different from situations where there's disagreement that something is actually a problem, that the problem is severe, or on the proper course of action (where the process you describe is appropriate). Currently, in this situation, the maintainer can ask the release team to decide whether: (1) the package should be removed from testing due to this problem (that's the default choice) (2) the package can stay despite this problem, using a work (e.g. require another init system) My point is that this proposal transfers this decision from the release team to the maintainer, for the specific case of the support for the default init system. Lucas signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
On 20/10/14 at 08:06 +0900, Charles Plessy wrote: > Le Sun, Oct 19, 2014 at 05:01:02PM +0200, Lucas Nussbaum a écrit : > > > > > > --- > > > > > > The Debian project asks its members to be considerate when proposing > > > General > > > Resolutions, as the GR process may be disruptive regardless of the > > > outcome of > > > the vote. > > > > > > Regarding the subject of this ballot, the Project affirms that the > > > question > > > has already been resolved and thus does not require a General Resolution. > > > > > > --- > > > > I think that it would be very helpful to describe how "the question has > > already been resolved". My understanding is that the various proposals > > add policy on something that isn't currently covered by the Debian Policy > > or by TC decisions. > > > > Alternatively, your resolution could state that the current de-facto > > policy of supporting both systemd and sysvinit (sometimes through > > systemd-shim) should be kept for Debian jessie, and that deciding > > on policy beyond jessie is premature at this point. > > Hi Lucas, > > being more precise would somehow defeat the point of stating that no GR is > needed, because the way the solution would be expressed, with its > imperfections, would then become binding. > > This said, let me clarify my understanding of the current situation. > > - Pepole running GNOME and desktops needing features not found in >other init systems will be migrated to systemd during update. I don't think that's correct. What to do during upgrades is still being discussed by the TC in #765803, and none of the amendments in the current GR discuss this. Also, thanks to the work on systemd-shim, it should be possible to upgrade from wheezy+GNOME with sysvinit to jessie+GNOME with sysvinit and systemd-shim. (I just tried, and the dist-upgrade currently fails to upgrade gnome, but it seems unrelated to init systems issues) > - Whether other people will be migrated or invited to migrate is in >the hands of the release team, who decides which packages are >part of Jessie or not. Well, it's true that the release team can control which packages are fit for integration into testing. But I don't think that the release team wants to use (abuse?) that to define our technical policy on init systems... > The techincal commttee has already given the general direction: we change the > default init system. In my opinion, this general direction is how the > “question” is resolved. Current decisions on which package depend on what, > etc, stem from that decision. As of today I do not think that we need the > technical comittee, the Policy or a GR to further constrain the work of the > release team. Replacing the init system is a major change, and obviously some > people who used expert skills to set up their system may need their expertise > to upgrade it. This, also, is a logical consequence of the TC's decision, and > I trust the various package maintainers that they are doing their best to make > the transition as easy as possible. TTBOMK, the various TC decisions related to this matter are: #727708 - https://lists.debian.org/debian-devel-announce/2014/02/msg5.html default init system on Linux is systemd https://lists.debian.org/878usv4ruj@rover.gag.com no decision on whether software may require specific init systems https://lists.debian.org/debian-devel-announce/2014/08/msg1.html (which I understand as technical advice, and Russ said the same thing in <87fvei8t2z@hope.eyrie.org>) For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. I don't think that this fully covers all the questions raised in the various amendments to this GR. I would very much prefer if your proposal said something such as: Regarding the subject of this ballot, the Project affirms that most of the questions have already been resolved. Resolving the remaining questions via a General Resolution is premature at this time. (I would vote the above first -- I'm unsure about your proposal) Lucas signature.asc Description: Digital signature
Re: GR option text on ballots
Hi, First, two points about this subthread: - it started as a private discussion (From Neil, to Ian and myself). Ian "leaked" it to debian-vote@. Ian, I hope that this is just a mistake, and that he will make sure to refrain from leaking private discussions to a public list without authorization. I don't particularly mind in that case, but I don't think that it's a practice that should be considered acceptable. - I originally honestly thought that Ian's proposal was about supporting all alternative init systems. That's why I suggested this summary for his proposal. I apologize for misunderstanding his proposal at the time. On 21/10/14 at 09:33 +0100, Neil McGovern wrote: > On Tue, Oct 21, 2014 at 08:14:44AM +0200, Didier 'OdyX' Raboud wrote: > > Le lundi, 20 octobre 2014, 12.17:14 Neil McGovern a écrit : > > > > > Ian's: make each package support all alternative init systems > > > > > > > > This is actively misleading in a least four ways: > > > Yup, I wouldn't count that as neutral either. How about: > > > > Your two proposals don't seem to match "Ian's" to which you're > > responding: > > > > > Packages should continue to run under sysvinit unless technically > > > unfeasible > > > > Ian's doesn't mention sysvinit at all; this would be highly misleading. > > > > > Packages may require a specific init system if technically required > > > > That's not at all the core of "Ian's" proposal in my reading. > > > > That's because they're descriptions for Lucas' amendment. Not according to the quoting in <20141020111714.ga18...@halon.org.uk> ? Anyway, I stand by what I wrote in <20141017202805.ga10...@xanadu.blop.info> (before Ian moved the discussion to -vote@): I consider that an appropriate summary for my proposal is: support for alternative init systems is desirable but not mandatory I trust that Kurt and Neil will find something better if they feel it's needed to ensure that the various summaries have homogeneous style in terms of wording. Lucas signature.asc Description: Digital signature
Re: GR option text on ballots
Neil McGovern writes ("Re: GR option text on ballots"):
> On Sun, Oct 19, 2014 at 03:18:52PM +0100, Ian Jackson wrote:
> > I would be very displeased if the Secretary chooses to use a text for
> > my proposal which was suggested by my opponent, and which I think
> > contains coded criticisms of my proposal.
>
> I'm not sure why you would assume that this is a possibility to be
> honest.
Yes. I'm sorry to have overreacted. The very unpleasant atmosphere
is getting to me - and me reacting to it like that isn't helping. So
my apologies.
Ian.
--
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/21574.15749.415661.73...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Joey Hess writes ("Re: Re-Proposal - preserve freedom of choice of init
systems"):
> Ian Jackson wrote:
> > 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.
>
> What, then was #746715?
It was non-binding advice asking maintainers to accept reasonable
patches. IMO it does not answer the question addressed by my GR.
> > 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.
>
> How can you use 4.1.5, which is "Issue, supersede and withdraw
> **nontechnical** policy documents and statements" (emphasis mine)
> for a technical decision like this? Why does this not come under 4.1.4,
> and so require a 2:1 majority?
I think that this coupling question is actually mostly a political
rather than a technical problem. The TC explicitly decided to allow
their init system decision to be amended or supplemented by a 1:1 GR
and it would be wrong to subvert that.
Ian.
--
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/21574.15584.843492.552...@chiark.greenend.org.uk
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Matthias Urlichs writes ("Re: Alternative proposal: reaffirm maintainers
technical competence over the software they maintain"):
> Really? To me, "For the record, the TC expects" does not introduce
> a ruling.
Precisely.
> It seems to be, rather, a strongly-worded but informal declaration how the
> TC is likely to rule, should a maintainer fail to meet this particular
> expectation.
Indeed.
Ian.
--
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/21574.15224.347405.22...@chiark.greenend.org.uk
Re: [Call for seconds] The ???no GR, please??? amendement.
On Mon, Oct 20, 2014 at 08:06:28AM +0900, Charles Plessy wrote: > Le Sun, Oct 19, 2014 at 05:01:02PM +0200, Lucas Nussbaum a ??crit : > > I think that it would be very helpful to describe how "the question has > > already been resolved". My understanding is that the various proposals > > add policy on something that isn't currently covered by the Debian Policy > > or by TC decisions. > being more precise would somehow defeat the point of stating that no GR is > needed, because the way the solution would be expressed, with its > imperfections, would then become binding. Maybe instead of: } Regarding the subject of this ballot, the Project affirms that the } question has already been resolved and thus does not require a General } Resolution. you could say something like: } Policy on how packages should integrate into the init system is set } by the policy team, though disputes may be escalated to the technical } committee as usual. As these procedures have not been exhausted, } this issue does not require a GR at this time. } } At the time of this GR, current policy on init system integration can } be found in Debian Policy, section 9.3, 9.4, and 9.11, and development } guidelines can be found at: }https://wiki.debian.org/systemd/Packaging (Those are all the references I could find with a quick search. Honestly, it seems remarkably inadequate... People spending too much time organising votes to actually document how secondary init systems should work?) FWIW, I think being non-specific about what the deal with systemd vs sysvinit vs runit vs upstart vs whatever is a bug (both here and in -policy too). I think that's stopping me from adding a (redundant) "seconded!", though I think this is still my preferred option. Cheers, aj -- 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/20141021084759.gb11...@master.debian.org
Re: GR option text on ballots
On Tue, Oct 21, 2014 at 08:14:44AM +0200, Didier 'OdyX' Raboud wrote: > Le lundi, 20 octobre 2014, 12.17:14 Neil McGovern a écrit : > > > > Ian's: make each package support all alternative init systems > > > > > > This is actively misleading in a least four ways: > > Yup, I wouldn't count that as neutral either. How about: > > Your two proposals don't seem to match "Ian's" to which you're > responding: > > > Packages should continue to run under sysvinit unless technically > > unfeasible > > Ian's doesn't mention sysvinit at all; this would be highly misleading. > > > Packages may require a specific init system if technically required > > That's not at all the core of "Ian's" proposal in my reading. > That's because they're descriptions for Lucas' amendment. Neil -- signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Mon, Oct 20, 2014 at 11:55:30PM +0200, Lucas Nussbaum wrote: > On 20/10/14 at 22:26 +0200, Arno T?ll wrote: > > That's - I think - a good default and affirms Debian's point of view > > that the respective maintainers can judge best what's a good requirement > > for their packages. Finally I encourage everyone to focus on the > > connotation in Luca's amendment. It allows maintainers to tie their > > software to a particular init system only as a last resort when > > absolutely necessary - not by pure choice, or by laziness. > > I disagree with this interpretation. > We have processes in place in Debian to deal with such last resort situations: > - someone opens an RC bug against the package, stating why it is > unsuitable for release > - the release team reviews the bug, and might (or not) mark it with the > jessie-ignore tag This seems mistaken to me -- issues shouldn't have to be release critical to be reviewed, or go through the release team. I would have said the process should be: - discussion happens on -policy or -devel about what the best approach on some issue is - someone opens a bug against the package that takes a less effective approach - the maintainer reviews the bug and takes whatever action they consider appropriate - further discussion happens on the bug, -policy or -devel or similar - as a last resort, the matter is escalated to the tech ctte for review I don't think there's a need for that process to involve blocking a package from release, or any necessity to distract the release team from coordination issues to participate in resolving technical conflicts. > I think that this would be a significant step backward in the way we > promote consistent technical practices in all Debian packages. Promoting consistent technical practices is policy's purpose, not the release team's, surely? >From what I can see, policy currently (version 3.9.6.0) covers init.d scripts and upstart, but doesn't mention systemd or unit files. That seems suboptimal to me...? Cheers, aj -- 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/20141021082155.ga11...@master.debian.org
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Quoting Nikolaus Rath (2014-10-21 02:41:12)
> Ian Jackson writes:
>> Nikolaus Rath writes ("Re: Alternative proposal: support for alternative
>> init systems is desirable but not mandatory"):
>>> I just don't understand why you consider uselessd a "trick" that I came
>>> up with (leaving alone the fact that David brought it up here, and that
>>> yet another guy started the project).
>>
>> When I read someone mention uselessd before, I thought it was a
>> hypothetical fork of systemd which was nearly identical to systemd.
>>
>> I think uselessd, if it is successful, deals squarely with many of the
>> actual reasons why people don't like systemd: systemd's tendency to
>> try to be everything. That is the real coupling threat - not the lack
>> of ability to continue to use init scripts.
>>
>> So I think in practice there aren't going to be many packages that
>> would want to couple specifically to systemd _or_ uselessd, but where
>> support for other init systems is hard to provide.
>
> So just to be clear: A package requiring either uselessd or systemd
> would be acceptable in Debian if your GR proposal passes?
Yes.
This GR is not anti-systemd, it is pro-choice-if-init-system.
In case you also lack an executive summary of that: The last GR was not
which-init-system, but which-system-by-default.
This GR is not anti-last-GR but refining -what-else-than-default with
-and-more-than-default-must-be-supported.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
