Re: kFreeBSD is fantastic
On Wed, 2007-03-07 at 00:34:44 -0600, Drew Scott Daniels wrote: I feel the real concerns for kfreebsd porters are in getting patches accepted, and having some additional resources. For now this may be accomplished outside the Debian resources, but official recognition might make things more easy, both in Debian, and upstream. It may even encourage more developers. http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;[EMAIL PROTECTED] regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting patches applied. emulated buildd's are good (was: kFreeBSD is fantastic)
On Thu, 2007-03-08 at 20:41:43 -0600, Drew Scott Daniels wrote: 68k seems to have elected to skip official etch, but also seems to have met the requirements. Some of the non-dd porters still want an official etch release. (They met the requirements after the architecture freeze, and only using emulated buildds, which needs some more discussion before being suitable for release.) This should be discussed then. The consensus I've been reading on debian-68k is that emulated buildds produce better code than real hardware. Can you help lead or find someone to lead this discussion? Perhaps a poll or irc meeting might help. The Maemo platform is enterely cross-compiled for armel under scratchbox (there might be still few exceptions that are natively built, due to problems with qemu and/or scratchbox, thought), and those are the binaries that went/go into the N770 and N800 devices. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GR: Selecting the default init system for Debian
[ M-F-T set to debian-vote@l.d.o, not seeking sponsors yet see below. ] Hi! I think that forcing a decision through the TC at this time was very premature and inappropriate, because I don't think enough effort had been made to reach consensus (failing §6.3(6)), because the TC seems to have been trying to do design work (failing §6.3(5)), and because even if they do have the power to decide on this (likely requiring a 3:1 majority in any case if they need to override the sysvinit maintainers, per §6.1(4)), I feel it's inappropriate for a small group of individuals to forcibly decide the global direction for the entire project. Such decisions, on issues that are as much technical as strategic, political or of a subjective design nature, can have huge implications for what contributors or other Debian-based projects might have to work on, or stop working on. I feel that such decisions must belong to the project at large. Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. If they had done so, Debian could follow its usual organic and decentralized process, allowing the best solution for the project as a whole to emerge naturally through the consensus formed from the experience of these deployments. Instead, we have seen giant flamewars seemingly based largely on speculation, which have only made the situation worse by increasing acrimony within the project, with further polarization and antagonization between the different factions. IMO, forcing this issue via a small committee will not improve this in any way. In general, I've been quite unhappy with the excessive invocation of the TC recently, with developers seeming to view this as a first, rather than absolute last, resort. I think it's pernicious for the project to instill a regime of threats and force, that will almost always alienate at least one side of a dispute. It clearly denotes a dysfunctional project. It has even crossed my mind many times now, to propose a GR for each issue concerning project direction (if not all) escalated to the TC, or even propose a constitutional change to remove the TC's powers of coercion; restricting its rulings to be strictly advisory and non-binding, though I'm not sure this option would get wide traction amongst developers, if at all. I've been sitting back and trying to see the extent to which other developers support the view that the TC should not be deciding on issues of project direction; unfortunately, canvassing support from mailing lists is difficult, and handling a GR is quite a large undertaking, requiring a lot of time and energy, that others might not want or be able to invest, but would gladly get behind. So, with much reluctance and disappointment, I've finally caved and am considering proposing the following GR draft. Unfortunately nothing has changed up to this point; the TC is not backing off. I think the draft text should cover most of the options people seem to have expressed support for up to now. Note that it's not entirely clear how a _pending_ resolution by the TC would interact with a GR on the same, so I'd like input from the secretary before seeking support from sponsors, although to be honest I don't expect any problems here. ,--- DRAFT GR TEXT --- A General Resolution to select the default init system for Debian. Option A * Reinforce sysvinit and sysv-rc as the default init system. - the level of support for other init systems would remain unchanged; as with non-release architectures, they would be supported to the extent that their backers would be willing to expend their energy. Option B * Changing the default init system is ultimately desirable, but premature at this point in time. - supporters of other init systems should continue their efforts towards full adoption by Debian through guidance in the policy manual, natural formation of consensus, and wider support through Debian packages by persuading maintainers to accept patches to add support. - if a broad consensus cannot be reached before jessie+1, another GR could be held to determine the default init system. - the level of support for other init systems would remain unchanged; as with non-release architectures, they would be supported to the extent that their backers would be willing to expend their energy. Option C * Switch to sysvinit + OpenRC wherever available. - architectures where OpenRC is not currently available will switch whenever OpenRC has been ported, retaining their current default in the meantime. - a reimplementation of OpenRC, providing the same interfaces to the wider system, would satisfy the criteria above. - the level of support for each init system would depend on the release status of the architecture: lack of
Re: GR: Selecting the default init system for Debian
Hi Steve! On Sat, 2014-01-18 at 19:16:44 -0800, Steve Langasek wrote: On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote: Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. […] can I ask how you arrived at the conclusion that not much energy has been expended on upstart in Debian? I've actually spent quite a lot of time and energy on getting upstart, and other base system packages, into a state that users should be able to switch from sysvinit to upstart without regressions. That means getting the ifupdown integration in place, making sure lvm and network filesystems work at boot, ensuring transparent handling of startpar dependencies on scripts that are shadowed by native upstart jobs, etc. Sorry, that wording was probably unclear. I *do* know you have done lots of work on upstart in Debian, that's why I also included the point about the policy update. But here I didn't mention, on purpose, work done on specific init systems themselves, helpers and immediate surroundings, but on wide deployment. I didn't mean to devalue the work you and other upstart supporters have done (or other init system alternative supporters for that matter), I'm sorry that might have been your impression. It does *not* mean doing very much work on pushing native upstart jobs to maintainers of leaf packages; that should be secondary to getting a complete and correct base into Debian. But we certainly are at the point today where such jobs can be implemented more widely in packages. If you have a different standard for seeking wide deployment, I'm interested to know what it is. Well, for example, only just very recently it got to a point where upstart could be installed w/o scary essential removal prompts and similar (again, work that you did). And yes, when I mentioned seeking wide deployment, I meant archive wide support. Let me try to give an analogy to clarify what I mean. Say, the GNU/kFooBar porters might have invested lots of effort into their kernel, toolchain and kFooBar-specific utilities, which in addition might be in excellent shape; but if the architecture only has 10% packages built for that port, and they stop there, then it cannot get exposure of its possible features, advantages or different ways to do things, and people interested in particular packages might not see the point in even giving it a try. Expecting the project at large to do the other 90% of the porting seems unrelalistic, even if the system has a very solid foundation, because at this point it might not show much advantage to the current ones. Instead I think the work that many porters have done, by sending patches to port packages to their systems, have in many cases triggered curiosity to the point of people possibly experimenting with those ports, or at least seeing value in supporting these even by themselves. There's probably many other similar examples, like having excellent cross-building support in the toolchain but having no actual cross-buildable package in the archive, etc. In the upstart case, most of the work could have been reused from Ubuntu, w/o interfering with the current init system default. I seem to understand reluctance to push native upstart jobs into Debian was partially out of respect towards the project. I just think that respect was misplaced for something that was optional, and it actually backfired. Hope that clarifies. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119163246.ga4...@gaara.hadrons.org
Re: GR: Selecting the default init system for Debian
Hi Ian! On Sun, 2014-01-19 at 12:04:17 +, Ian Jackson wrote: Guillem Jover writes (GR: Selecting the default init system for Debian): I think that forcing a decision through the TC at this time was very premature and inappropriate, [...] Perhaps surprisingly, I am not entirely opposed to the idea of a GR for this question. My reasons are quite different to yours: to summarise, it seems to me that the init system decision involves political questions as well as technical ones. Actually, no, part of my reasons include several of the ones you list, as I tried to imply when writting “Such decisions, on issues that are as much technical as strategic, political or of a subjective design nature,”. I should probably have been more explicit (seems to be a common fault of mine :/ ), but didn't want to go into specific details for those, I guess that was a mistake. :) For example with strategic, I was thinking about things like: * Does the project want to align itself with an existing ecosystem or distribution? - Due to similarities and existing relationships with other projects. - Or due to perceived number of supporting distributions. - Or due to perceived global userbase. * Maybe even to try to tip the scale one way or another; either to counterweight what might be perceived as having more support by the rest of the community so that diversity is preserved, or to try to standardize on a global one so that the others can wane off, eventually? For political, several of the ones you've listed, and of a subjective design nature things like: * Being more or less portable, allowing to use the full extent of a system, or providing a common baseline for many systems creating uniformity. * Being more user extensible, or having no knobs and trying to have only good defaults. * Being tightly coupled or allowing for parts to be easily replaced. * Shifting the complexity from system to the users (users here would be daemons), or the other way around (implementation and interfaces wise). * Incremental evolution of existing systems or revolutionary new systems. * etc. which in the end are all possible valid design philosophies, with different tradeoffs, depending on the context, usage, expectations, etc. Where reasonable people can have opposite opinions or preferences. A really good characterization of what I mean could be the New Jersey vs MIT schools of thought, as represented in the well known The Rise of Worse is Better writup. http://dreamsongs.com/RiseOfWorseIsBetter.html I do think that the proper process is for the TC to make a decision at this stage. The way I read the constitution and the context is that it is the TC's job. Evidently you disagree. But there are certainly things that some TC members are suggesting which would lead me myself to want to propose or sponsor a GR to overturn it. If the TC was to continue making the decision, I'd want to run the GR regardless of the outcome, even if I'd agree with it; althought as I've mentioned before I find the 2:1 majority unfair. If we are going to have a GR, we need of course to have all of the sensible options on the ballot. I think your division of the key possibilities is sensible. Thanks. However, I think your option (B) needs further reconsideration. I doubt the project will have the appetite for two GRs on this topic. Well, I'd rather not be spending time in the current GR either, I'd prefer to be doing something else instead, to be honest. But regarding option B, I'd also very strongly prefer if no other GR would appear, but I know that some people are eager to get a decision made and be done with it (even if it would get postponed now), and will not want to wait either, so that was more of a compromise than anything else. Most people are heartily sick of the subject already, probably. (Indeed I'm somewhat worried that people might want to punish the proposers and sponsors of a GR for prolonging such a tiresome dispute.) (In a way I guess I accepted that burden when I offered myself as a sacrificial token.) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119193601.gb4...@gaara.hadrons.org
Re: GR: Selecting the default init system for Debian
Hi Enrico! On Sun, 2014-01-19 at 14:56:27 +0100, Enrico Zini wrote: On Sun, Jan 19, 2014 at 12:04:17PM +, Ian Jackson wrote: My reasons are quite different to yours: to summarise, it seems to me that the init system decision involves political questions as well as technical ones. I would gladly vote an option that says: technically, we trust what the TC says; politically, we are concerned about some of our upstreams' choices. A technical endorsement need not also be a political one. I don't agree these can be detangled, many reasons for such decision do have basis on non-technical questions (see my reply to Ian). So the other questions will keep being implicitly there even if it's supposedly just a “technical endorsement”. I would like to keep the technical and political issues as distinct as possible, though. I am not interested in spending time evaluating each option to form a technical opinion on what the best choice would be, and I'm extremely happy that the TC are doing that for me. I do have personal opinions on some of the upstreams' choices, but I believe that they should not get in the way of a technical decision. To be frank, something I'd actually be very satisfied with, would be if the TC would have been requested or would decide to issue a set of non-binding informative documents, or a single or a set of non-binding recommendations for a default init system, to be used by people to decide, or to be added as additional explicit option(s) in the GR deferring to those recommendations. In fact, I think having a group of individuals (self-elected or not) on a workgroup doing focused research on difficult issues concerning project wide direction and presenting their findings and conclusions for consideration before the project in a non-binding form, would be excellent; and could help those who are undecided, don't have the time or energy to expend getting informed, or would like to defer completely their decision to that workgroup, for example. But as it stands I think I'm a bit conflicted here, on one hand the whole point of the GR is because I don't agree the TC should be _deciding_ on this, the project should, but on the other I acknowledge there's people that for whatever reason want to defer to the TC. So, because that's obviously the will of a part of the project, and because an amendment to the GR would be proposed most probably anyway, I guess I should just add an option deferring to the TC. Although ideally I think the scenario presented above would satisfy everyone, if the GR is going to be held anyway. A constructive thing that we may do as a project to address the political side of the matter, is to add to our technical decision a list of things that we wish our upstreams would do to make all our lives easier in the future. Honestly, I don't see how that would get us anywhere. We already have https://wiki.debian.org/UpstreamGuide. Adding something like this to a binding ruling affecting Debian, targeted at upstreams, seems a bit arrogant to me, because upstreams that have a strong opinion that might diverge from our ruling will unlikely change their mind. I think this is best left to the one-to-one relationships our maintainers already have with upstream, at their discretion. We always have the option of forking, or not packaging upstream software if we so strongly disagree. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120040409.ga13...@gaara.hadrons.org
Re: GR: Selecting the default init system for Debian
[ Given the tone in this mail, I'd usually not bother replying, but I guess it's my duty given the proposed changes to the draft. ] Hi, On Sun, 2014-01-19 at 16:53:12 +0100, Holger Levsen wrote: I think you are missing the following options and have only listed options which you consider sensible or which you loath: I'd have guessed it'd be obvious why I might not include options I consider inappropriate or insane? People can always propose amendments for those. Of course, that does not mean I might have missed other good options people might favour. h.) support them all equally: systemd, upstart, sysv and openrc and keep sysv as the default i.) support them all equally: systemd, upstart, sysv and openrc and make $foo1 the default j) support them all equally: systemd, upstart, sysv and openrc and make $foo2 the default k.) support them all equally: systemd, upstart, sysv and openrc and make $foo3 the default I'd actually love if the project could support all init systems equally, and not even these, all the ones that have not been proposed like runit, minit, etc. I'm actually an idealist, but in a voluntary project like Debian, there's a point where ones ideals must not take precedence, when confronted with ideas that might imply making others to do things they don't want which I find totally inappropriate; this is a maxim I've tried to follow when drafting the GR. For example I think it would be totally uncalled for, to force the systemd maintainers to carry portability patches (if those ever happen) when their upstream and themselves have stated that would make them very unhappy, when other people could instead fork systemd or reimplement their interfaces (and this is talking as a porter). Unfortunately I think supporting all these equally is very much unfeasible, and would put a huge burden on maintainers. One thing is for a maintainer preferring init system X, while the default is Y, to support both natively, the other is requiring them to test and run all these different init systems on each upload, either through VMs, dedicated hosts, or init system package switches. We do not require of maintainers that they support themselves all our architectures, and we don't even consider it a serious bug if a package has never been built for one (be it Linux-based or not, mind you), the same should apply to init systems IMO. So in these cases I consider they are already covered in spirit by the non-exclusive options in the draft. l.) accept the TC decision, whatever that will be m.) wait for the TC decision and then revote on this GR n.) wait for the TC decision and then start a new GR on this topic See my reply to Enrico. And, frankly, I'm disappointed by your *lousy* research on the topic (see both Tollefs and Steves reply), while at the same time I think you have given an *excellent* (bad) example, why voting is or can be bad: uninformed people vote on matters they dont fully understand. Given your lousy research I do assume you havent read the tech-ctte bug in question. If you had, I'm don't think you would think the same about the topic. (But then, most peoples minds aren't or cannot be changed by new information.) I do think this bug contains among of the best research of this topic. If you as a GR proposer cannot be bothered to inform yourself in the best possible way about it, I fear for a rather totally uninformed decision of other voters. cheers, Holger, who has come to the conclusion that this init system discussion is way more a bikeshed than what I would have assumed half a year ago. Indeed 99% of our users don't care and the majority of those who do care want their bikeshed their way or the highway... I'm actually flabbergasted at how you've reached that conclusion, given that I've tried very hard to not imprint any judgment on any given init sytem, on purpose, so to avoid having the GR proposal itself turn into a monster rehash of the same. Personally, I do actually trust my fellow project members to get properly informed themselves by the time of a vote, seeking help/advice/inspiration from others, not voting if they don't care at all what the project decides, etc. On one hand I don't think I should be dignifying this with a reply, on the other not clarifying might possibly cloud the impression or lack thereof of due process when drafting the GR itself. I'd also rather not be talking about my credentials, or lack thereof, TBH, I'd have happily replied in private if asked nicely. I'd rather talk just about the merits or lack thereof of the options in the GR draft itself. In any case, given the character assassination above, here's my involvement in this issue, trying to keep any possible judgment for any particular init system out of it, because my preference, really, would be for the project at large to reach consensus on the issue: * While at Nokia, was involved in the
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
Hi! On Sat, 2014-01-25 at 17:06:45 +0100, Wouter Verhelst wrote: On Sat, Jan 25, 2014 at 08:20:35PM +0900, Charles Plessy wrote: What I am saying is: Let's allow the Debian system to evolve freely: the result will not be breakage, but systemd as a de facto default. This argument has been brought up before (indeed, even by me), and has been debunked by several people. I very much disagree this argument has been debunked, I do accept other people have a different opinion on it though, but there's no point in discussin this here. I am personally convinced that we *do* need a better init system. I don't actually care _which_ init system that is, and am contend to leave that decision to the people who do. But we should not retain the status quo. We should have made a decision on this subject years ago. The debate is reducing the quality of our mailing lists, is holding the entire project hostage, and we're *still* no closer to an answer. Even the TC seems to be having difficulties reaching a decision. I was letting at least one week pass, to possibly get input from other people, or from the secretary, and I was/am planning on looking for sponsors on a revised GR draft tomorrow (including the defer to TC option and reworded Option B). If there's any conflict with the running TC resolution, the secretary can point it out before the vote, if enough people sponsor the GR, of course. So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice. If the dice comes at rest with 1 or 2 facing up, systemd will become the default init system for Debian. If the dice comes at rest with 3 or 4 facing up, upstart will become the default init system for Debian. If the dice comes at rest with 5 or 6 facing up, openrc will become the default init system for Debian. - I am looking for seconds. And no, that's not a joke; at this stage the debate is essentially deadlocked, and I am doubtful that the debate will *ever* reach a conclusion which will be the best on a technical and/or political level. All available options feature some things that the others don't, all have downsides, and none of the available options will ever be a perfect solution. We could discuss this ad infinitum and end up with a non-solution, or we could just bite the bullet and make a decision. At this point, I think any decision is better than no decision, even if that decision is the throw of a dice. Ok, given what you mentioned above, your preference is not easily represented with the current GR draft, and I don't think this amendment makes much sense (at least to me). You want a change, but don't care which; in which case I think it would be more appropriate to let the people who care decide, as you pointed out. I could see a decision by dice, being questioned as non-transparent, etc. But could see an option that essentially says (with better wording and all that): * Switch the init system to something else than sysvinit + sysv-rc. - a decision for a new init system needs to be made now, letting this undecided will keep causing frustration and project tension. - the init system chosen will be the one the project at large has a preference on, by selecting the winning option among options C-G. If something along those lines satisfies you, I'm happy to include a polished version in the GR draft. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125165047.ga27...@gaara.hadrons.org
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, 2014-01-25 at 18:15:46 +0100, Wouter Verhelst wrote: On Sat, Jan 25, 2014 at 05:50:47PM +0100, Guillem Jover wrote: Ok, given what you mentioned above, your preference is not easily represented with the current GR draft, and I don't think this amendment makes much sense (at least to me). Well, that's of course your prerogative, but the fact that you came up with a long list of options doesn't negate my right to attempt to add another option, even if you think it doesn't belong there. Oh, absolutely, it just seemed a bit at odds with what you had just mentioned before. And in any case, I was trying to find an option or a vote solution that might satisfy your preference (which I've also seen elsewhere), and to avoid ending up with a monster ballot, with many options with very small variations over mostly the same. You want a change, but don't care which; in which case I think it would be more appropriate to let the people who care decide, as you pointed out. That would of course be the best option, and I would be happy if we were to reach that. I could see a decision by dice, being questioned as non-transparent, etc. Hence the bit about two other DDs need to be present. I suppose we could possibly require a video recording. Alternatively, we could choose some factoid about the vote itself; like number of votes received modulo 3 decides the winner, or (all timestamps on all mails sent and received by devotee during the course of this vote represented in unix epoch, added together), modulo 3 decides the winner, or some other variation on that theme. The point is to essentially pull a decision out of thin air if all other attempts to make a decision failed. Yes also considered the video, but still, what about the dices themselves, etc; the other options you mention are a bit better. But in any case I don't think it's a good idea, really, it would probably piss off anyone who cares about a specific choice, and people would keep challenging the vote, becuse it was random. Obviously if you still think it is a good idea and others agree, then it will end up being included. We need a decision. I don't care what that decision is, but we need one. Since a few months, this endless debate has reached the point where every thread on every mailinglist, given enough time, eventually turns into yet another instance of the init system debate. This is unhealthy for our community and needs to stop. Well, I think a vote by the project, whatever the outcome (status quo, postpone, specific option), will be a clear message that people would stop going on about it (at least for a while :). But could see an option that essentially says (with better wording and all that): * Switch the init system to something else than sysvinit + sysv-rc. - a decision for a new init system needs to be made now, letting this undecided will keep causing frustration and project tension. - the init system chosen will be the one the project at large has a preference on, by selecting the winning option among options C-G. If something along those lines satisfies you, I'm happy to include a polished version in the GR draft. That would introduce interdependencies between votes, which has a serious risk of skewing the result (e.g., people would feel more compelled to rank one option lower, so that the chance of it winning indirectly through this option gets smaller; that would mean they wouldn't be expressing their actual opinion). I don't think that's a good idea. Actually I agree, because I just realized your preference (I think) can actually be represented with the current ballot. You could rank all options that specify a change from the current default above NOTA, and the reset below. If you (as in the generic voter), really don't care can rank all options above NOTA equally. Given this I'm not planning on adding such option. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125212413.ga31...@pulsar.hadrons.org
[Proposal] GR: Selecting the default init system for Debian
[ M-F-T and Reply-To set to debian-vote@l.d.o. ] Hi! This is the revised draft GR proposal (please see below); I'm looking for sponsors now. On Sun, 2014-01-19 at 01:01:44 +0100, Guillem Jover wrote: I think that forcing a decision through the TC at this time was very premature and inappropriate, because I don't think enough effort had been made to reach consensus (failing §6.3(6)), because the TC seems to have been trying to do design work (failing §6.3(5)), and because even if they do have the power to decide on this (likely requiring a 3:1 majority in any case if they need to override the sysvinit maintainers, per §6.1(4)), I feel it's inappropriate for a small group of individuals to forcibly decide the global direction for the entire project. Such decisions, on issues that are as much technical as strategic, political or of a subjective design nature, can have huge implications for what contributors or other Debian-based projects might have to work on, or stop working on. I feel that such decisions must belong to the project at large. Moreover, none of the proponents of alternative init system seem to have expended much energy in seeking wide deployment of their solutions within Debian (or, with the exception of upstart, even updating the policy manual) before this binding ruling was sought. If they had done so, Debian could follow its usual organic and decentralized process, allowing the best solution for the project as a whole to emerge naturally through the consensus formed from the experience of these deployments. Instead, we have seen giant flamewars seemingly based largely on speculation, which have only made the situation worse by increasing acrimony within the project, with further polarization and antagonization between the different factions. IMO, forcing this issue via a small committee will not improve this in any way. In general, I've been quite unhappy with the excessive invocation of the TC recently, with developers seeming to view this as a first, rather than absolute last, resort. I think it's pernicious for the project to instill a regime of threats and force, that will almost always alienate at least one side of a dispute. It clearly denotes a dysfunctional project. It has even crossed my mind many times now, to propose a GR for each issue concerning project direction (if not all) escalated to the TC, or even propose a constitutional change to remove the TC's powers of coercion; restricting its rulings to be strictly advisory and non-binding, though I'm not sure this option would get wide traction amongst developers, if at all. I've been sitting back and trying to see the extent to which other developers support the view that the TC should not be deciding on issues of project direction; unfortunately, canvassing support from mailing lists is difficult, and handling a GR is quite a large undertaking, requiring a lot of time and energy, that others might not want or be able to invest, but would gladly get behind. So, with much reluctance and disappointment, I've finally caved and am considering proposing the following GR draft. Unfortunately nothing has changed up to this point; the TC is not backing off. I think the draft text should cover most of the options people seem to have expressed support for up to now. Note that it's not entirely clear how a _pending_ resolution by the TC would interact with a GR on the same, so I'd like input from the secretary before seeking support from sponsors, although to be honest I don't expect any problems here. As mentioned in the thread, if there's any issue with the above, the secretary can point it out during the discussion period if this gets support from enough sponsors. The two main changes are the addition of the explicit TC option, and the rewording of option B to not mention a GR explicitly, and to just postpone revisiting that decision to a later time. I chose that time to let some breathing after the jessie release, and because it's (usually) 1/3 of the non-frozen release time, so it would give enough room to deploy any possible changes before jessie+1. Attached is a diff against the original GR draft, for your convenience. ,--- DRAFT GR TEXT --- A General Resolution to select the default init system for Debian. Option A * Reinforce sysvinit and sysv-rc as the default init system. - the level of support for other init systems would remain unchanged; as with non-release architectures, they would be supported to the extent that their backers would be willing to expend their energy. Option B * Changing the default init system is ultimately desirable, but premature at this point in time. - supporters of other init systems should continue their efforts towards full adoption by Debian through guidance in the policy manual, natural formation of consensus, and wider support through Debian packages by persuading maintainers to accept patches
Re: Last minute cominbations G+D and/or G+E
On Wed, 2019-12-04 at 17:11:49 +, Ian Jackson wrote: > Thanks for this. No-one else has said anything. Having thought about > it, I think Guillem's framing would lead me to a conclusion closer to > Dmitry's E rather than my option D - but either is arguable. As I mentioned in my “Reframing” reply, I think option E can be rather problematic, as I'm not really sure what it does imply, and it seems option D while trying to be very detailed ends up potentially not being exhaustive enough and feels too rigid at times. > To make it concrete I am going to post texts of those two options. If > people come forward to say they support or or both of them I will > formally propose them tomorrow morning (in the hope that the Secretary > and/or the DPL will allow them on the ballot). If you support either > of these options enough, then please formally propose it yourself and > I will second it tomorrow. > I do not intend either of these proposals to replace E or D, nor G. Hmm, I've not checked the actual differences between the combined and the individual options, but I have the feeling they would kind of devalue G, as it would seem like it's missing something. I acknowledge some people do believe it does miss something, but placed side-by-side in this way, makes it weird. I guess I'd then need to try to articulate the guidance and details (or lack thereof) in some explicit way to append to the end on an amendment. Thanks, Guillem
Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
On Fri, 2019-12-06 at 22:50:32 +0100, Kurt Roeckx wrote: > That's 5, I'll update everything. Thanks for this Kurt! Much appreciated! Regards, Guillem
Re: Last minute cominbations G+D and/or G+E
On Thu, 2019-12-05 at 13:18:06 +0100, Guillem Jover wrote: > I already started yesterday to try to structure and organize my > thoughts on how I'd express this. I do have today packed until later > this evening, so I think it's unrealisting that I can propose anything > today. I hope to have something by tomorrow, but maybe only by late > European night time. :/ I'm still planning on sending that mail in a couple of hours, but I'm getting into a plane just right now. I tried to send it yesterday night, but it got extremely late and was too tired to finish writing it up, and needed to sleep some hours. If it does not end up making it in, I guess it will not be the end of the world, but it'd feel a bit disappointing. Thanks, Guillem
Option G update (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
Hi! Ok, so here's what I'd like (or would have liked) to get into the ballot, given the new context after the addition of the combined D+G option. But it's not very clear to me whether this will be acceptable or not to the Secretary, and what would be the actual procedure to replace the existing option G with this one (as long as enough of the original sponsors are fine with it), as I've found the way the procedure was applied/interpreted to be rather confusing or perhaps not matching my memory of previous instances. The changes to the original G are: - Addition of Principles section title. - s/tradeoffs/trade-offs/g. - Addition of Guidance section. I'm CCing all the previous sponsors explicitly, just in case. X< Title: Reaffirm our commitment to support portability and multiple implementations Principles ~~ The Debian project reaffirms its commitment to be the glue that binds and integrates different software that provides similar or equivalent functionality, with their various users, be them humans or other software, which is one of the core defining traits of a distribution. We consider portability to different hardware platforms and software stacks an important aspect of the work we do as a distribution, which makes software architecturally better, more robust and more future-proof. We acknowledge that different upstream projects have different views on software development, use cases, portability and technology in general. And that users of these projects weight trade-offs differently, and have at the same time different and valid requirements and/or needs fulfilled by these diverse views. Following our historic tradition, we will welcome the integration of these diverse technologies which might sometimes have conflicting world-views, to allow them to coexist in harmony within our distribution, by reconciling these conflicts via technical means, as long as there are people willing to put in the effort. This enables us to keep serving a wide range of usages of our distribution (some of which might be even unforeseen by us). From servers, to desktops or deeply embedded; from general purpose to very specifically tailored usages. Be those projects hardware related or software based, libraries, daemons, entire desktop environments, or other parts of the software stack. Guidance In the same way Debian maintainers are somewhat constrained by the decisions and direction emerging from their respective upstreams, the Debian distribution is also somewhat constrained by its volunteer based nature, which has as another of its core defining traits, not willing to impose work obligations to its members, while at the same time being limited by its members bounded interests, motivation, energy and time. Because of these previous constraints, trying to provide guidance in a very detailed way to apply the aforementioned principles, is never going to be satisfactory, as it will end up being inexorably a rigid and non-exhaustive list of directives that cannot possibly ever cover most scenarios, which can perpetuate possible current tensions. These will always keep involving case by case trade-offs between what changes or requests upstreams might or might not accept, or the upkeep on the imposed deltas or implementations the Debian members might need to carry on. Which can never be quantified and listed in a generic and universal way. We will also keep in mind that what might be considered important for someone, might at the same time be considered niche or an uninteresting diversion of time for someone else, but that we might end up being on either side of the fence when sending or receiving these requests. We will be guided, as we have been in many other Debian contexts in the past, by taking all the above into account, and discussing and evaluating each situation, and respecting and valuing that we all have different interests and motivations. That is in our general interest to try to work things out with others, to compromise, to reach solutions or find alternatives that might be satisfactory enough for the various parties involved, to create an environment where we will collectively try to reciprocate. And in the end and in most cases it's perhaps a matter of just being willing to try. X< Thanks, Guillem
Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
[ Sorry, resending signed this time around. :/ ] Hi! Ok, so here's what I'd like (or would have liked) to get into the ballot, given the new context after the addition of the combined D+G option. But it's not very clear to me whether this will be acceptable or not to the Secretary, and what would be the actual procedure to replace the existing option G with this one (as long as enough of the original sponsors are fine with it), as I've found the way the procedure was applied/interpreted to be rather confusing or perhaps not matching my memory of previous instances. The changes to the original G are: - Addition of Principles section title. - s/tradeoffs/trade-offs/g. - Addition of Guidance section. I'm CCing all the previous sponsors explicitly, just in case. X< Title: Reaffirm our commitment to support portability and multiple implementations Principles ~~ The Debian project reaffirms its commitment to be the glue that binds and integrates different software that provides similar or equivalent functionality, with their various users, be them humans or other software, which is one of the core defining traits of a distribution. We consider portability to different hardware platforms and software stacks an important aspect of the work we do as a distribution, which makes software architecturally better, more robust and more future-proof. We acknowledge that different upstream projects have different views on software development, use cases, portability and technology in general. And that users of these projects weight trade-offs differently, and have at the same time different and valid requirements and/or needs fulfilled by these diverse views. Following our historic tradition, we will welcome the integration of these diverse technologies which might sometimes have conflicting world-views, to allow them to coexist in harmony within our distribution, by reconciling these conflicts via technical means, as long as there are people willing to put in the effort. This enables us to keep serving a wide range of usages of our distribution (some of which might be even unforeseen by us). From servers, to desktops or deeply embedded; from general purpose to very specifically tailored usages. Be those projects hardware related or software based, libraries, daemons, entire desktop environments, or other parts of the software stack. Guidance In the same way Debian maintainers are somewhat constrained by the decisions and direction emerging from their respective upstreams, the Debian distribution is also somewhat constrained by its volunteer based nature, which has as another of its core defining traits, not willing to impose work obligations to its members, while at the same time being limited by its members bounded interests, motivation, energy and time. Because of these previous constraints, trying to provide guidance in a very detailed way to apply the aforementioned principles, is never going to be satisfactory, as it will end up being inexorably a rigid and non-exhaustive list of directives that cannot possibly ever cover most scenarios, which can perpetuate possible current tensions. These will always keep involving case by case trade-offs between what changes or requests upstreams might or might not accept, or the upkeep on the imposed deltas or implementations the Debian members might need to carry on. Which can never be quantified and listed in a generic and universal way. We will also keep in mind that what might be considered important for someone, might at the same time be considered niche or an uninteresting diversion of time for someone else, but that we might end up being on either side of the fence when sending or receiving these requests. We will be guided, as we have been in many other Debian contexts in the past, by taking all the above into account, and discussing and evaluating each situation, and respecting and valuing that we all have different interests and motivations. That is in our general interest to try to work things out with others, to compromise, to reach solutions or find alternatives that might be satisfactory enough for the various parties involved, to create an environment where we will collectively try to reciprocate. And in the end and in most cases it's perhaps a matter of just being willing to try. X< Thanks, Guillem signature.asc Description: PGP signature
Re: Last minute cominbations G+D and/or G+E
On Thu, 2019-12-05 at 10:53:33 +, Ian Jackson wrote:
> Guillem Jover writes ("Re: Last minute cominbations G+D and/or G+E"):
> > On Wed, 2019-12-04 at 17:11:49 +, Ian Jackson wrote:
> > > I do not intend either of these proposals to replace E or D, nor G.
> >
> > Hmm, I've not checked the actual differences between the combined and
> > the individual options, but I have the feeling they would kind of
> > devalue G, as it would seem like it's missing something.
>
> That is an unfortunate effect, yes. I mean, my opinion is (as you
> know) that G _is_ missing something. But it would be much better if
> you as the proposer of the original G could explain in it why you
> think more guidance is not appropriate.
Just to clarify, and to avoid any possible reading of subtext
implying I'm unhappy with the combination in the new proposal:
With the new proposed options, this seems to set a different context
where I consider the omission in option G to be a bug, yes. Before I
guess it could have perhaps be understood relative to the other options,
even if probably having made it explicit (which I actually considered,
but was not sure how to do) would have made it easier to understand too.
> > I acknowledge
> > some people do believe it does miss something, but placed side-by-side
> > in this way, makes it weird. I guess I'd then need to try to articulate
> > the guidance and details (or lack thereof) in some explicit way to
> > append to the end on an amendment.
>
> Yes. I have no idea how long you have to do this.
I already started yesterday to try to structure and organize my
thoughts on how I'd express this. I do have today packed until later
this evening, so I think it's unrealisting that I can propose anything
today. I hope to have something by tomorrow, but maybe only by late
European night time. :/
Thanks,
Guillem
Proposal: Reaffirm our commitment to support portability and multiple implementations
Hi! I think the current GR is incorrectly framing the problem at hand, as if it was just an init system selection. It seems to me, that an init system is in principle just one of the many technologies we ship and integrate. But at least when it comes to systemd, choosing that in detriment to anything else, has a cascading effect of deciding on and closing doors on a wide range of technologies which have been declared incompatible by systemd upstream or by those other technologies. For example the claims on "cross-distribution standards and cooperation", are pretty much restricted to GNU/Linux (glibc-based), not even say musl-based systems, or many other variations. systemd provides many nice features, but at the same time, as with any software, not all of them fit or are sufficient for all use cases or requirements, and people do want or have to use alternatives for many valid reasons. I'm thus proposing the following: X< Title: Reaffirm our commitment to support portability and multiple implementations The Debian project reaffirms its commitment to be the glue that binds and integrates different software that provides similar or equivalent functionality, with their various users, be them humans or other software, which is one of the core defining traits of a distribution. We consider portability to different hardware platforms and software stacks an important aspect of the work we do as a distribution, which makes software architecturally better, more robust and more future-proof. We acknowledge that different upstream projects have different views on software development, use cases, portability and technology in general. And that users of these projects weight tradeoffs differently, and have at the same time different and valid requirements and/or needs fulfilled by these diverse views. Following our historic tradition, we will welcome the integration of these diverse technologies which might sometimes have conflicting world-views, to allow them to coexist in harmony within our distribution, by reconciling these conflicts via technical means, as long as there are people willing to put in the effort. This enables us to keep serving a wide range of usages of our distribution (some of which might be even unforeseen by us). From servers, to desktops or deeply embedded; from general purpose to very specifically tailored usages. Be those projects hardware related or software based, libraries, daemons, entire desktop environments, or other parts of the software stack. X< Thanks, Guillem signature.asc Description: PGP signature
Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
Hi! I've been busy late yesterday and today, and not been able to reply to some of the questions presented. I've got an early flight in a few hours, so I'm unable to finish the draft reply I've started but which I plan to send tomorrow (Monday). Sorry about this, but the rushed timeline is not very convenient. :( Thanks, Guillem
Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
Hi! [ I'm sorry this has gotten a bit long, but I assume I'm going to run out of time for any discussion, due to the imposed timeline, so I'm trying to put it all upfront. ] On Sat, 2019-11-30 at 11:54:09 -0700, Bdale Garbee wrote: > Guillem Jover writes: > > I think the current GR is incorrectly framing the problem at hand, > > as if it was just an init system selection. > > This resonates with me, but... > > > I'm thus proposing the following: > > I find this really appealing as a higher-level statement of values and > intent, but unfortunately, I don't think the text does anything to help > resolve the problems that Sam set out to try and tackle with this GR. > > I therefore find myself unwilling to second it, even though on some > level I would really like to. I've to say, that while I think I understand where your and other similar reactions to this proposal are coming from, I also found them a bit perplexing. :) Other options - I'm actually not sure how the other options can be seen as resolving the root issue at hand. I see what they are trying to do, but I don't think they are framing it correctly. They are all approaching the problem from the symptoms, by either trying to go into details on how to integrate specific stuff, or on how to behave. This all feels like they assume that people would not respect the spirit of a decision, and to combat bad faith they need to be very specific on details? But if we'd assume people are going to be acting in bad faith, then no amount of details and specifics would fix this, and IMO it can make it worse, as it gives a list of things to be looking loop holes into and questioning legalities all over. I think this is a recipe for disaster, and I also find that type of framing a bit depressing. The options that favor focusing on systemd still seem to leave the door open in appearance to alternatives, but in some kind of false sense of hope way, due to either the proposed vague hopes or all the conditionals which depend on maintainer discretion to apply based on the (naturally insufficient) details provided on those options. It seems like a death by a thousand cuts, which sets the stage for more frustration and conflict. The options that favor init alternatives go into specific details (are these truly exhaustive enough though?). But they still seem to not be asking the right question. Let's skim over the other options: * Option F - The "cross-distro and standardization efforts" mention feels a bit misleading to me, as this is really restricted to an ecosystem based on Linux + glibc + systemd. (To clarify, I think this is obviously a valid stance to take, I mostly take issue in the way it is presented.) - Provides a false sense of hope (see above): + "patches _can_ be submitted". How is this going to prevent the same situations that triggered this GR? * Option B - Provides a false sense of hope (see above): + _Should_ include unit and init scripts. + Developers and user _can_ explore and develop alternatives. + Developers need to provide the work, but that does not imply others will integrate it. + Reviewing and discussing patches but obviously not necessarily agreeing to them. How are any of these going to prevent the same situations that triggered this GR? * Option A - Provides a false sense of hope (see above): + Focuses on sysvinit specifics like init script, but does not mention other potentially ancillary features upstream might use that are not core functionality to the project at hand. + The NMU reference looks like a distraction, as it does not fix any possible deadlock or blocking, as one can always reject an NMU, or revert it. + In Debian, policy (in most cases) follows practice, so whether policy accepts something does not say much about what maintainers will be accepting. How are any of these going to prevent the same situations that triggered this GR? * Option D - Goes into much detail about possible conflicting scenarios, but does it cover them all? This seems inherently non-exhaustive. - This encodes very concrete package names and implementation details, which seem off for a GR. + What if the sysvinit maintainers and users agree they want to switch to something else on top of sysvinit that does not use traditional init scripts? - Isn't option D.7 potentially very counterproductive? Mixing regressions in support with new support seems murky. Also what kind of patch are we talking about? A 10 liner, or 1 MiB of delta which upstream is not willing to take, so the burden falls on the Debian maintainers? * Option E - What does the "MUST" and "work" in here really imply? Does this mean every package must fully support natively all currently availa
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On Sun, 2022-02-13 at 14:28:44 -0700, Sam Hartman wrote: > This starts informal discussion of a proposed general resolution to > amend the constitution. I am not seeking sponsors at this time. > Comments including support or alternatives are welcome. I think this is > mature enough to seek review from the secretary. Since the idea of general secret votes has started floating around I've felt a sense of uneasiness, but I've not been able to clearly put my finger on why. After some of the replies here, I think it's starting to become clear. I think the current secrecy for the DPL votes makes absolute sense, and I think there's no contention about that one, because these are about voting "for/against" people, which have clear and understood social dynamics when it applies to colleagues/friends or people we do work with etc. I think, thus, extending secrecy to any vote related to "people" would also be equally uncontroversial. Then, there's the secrecy for technical votes, which I think is where the push back might be coming from. There's been mentions of mailing lists being way more revealing than a vote in GR, and counters to that mentioning that you do not need to participate in mailing lists. Both true. The problem I think, is that to participate in Debian in any technical role, you most definitely need to eventually make your opinion on technical matters public, because we operate on the open. Be that on bug reports, on changelogs, on VCS commits, or even on mailing lists. It also feels like closing up technical votes would go counter to the general tenets of the project and how we operate. And then, there's the secrecy for "political" votes. I think this might also be problematic, depending on the subject at hand. Because as mentioned in the thread, it might make public positions that people otherwise would not need to make so on their daily routines in Debian. I think the RMS vote, was a mix of personal + political, which is what made people uncomfortable with. The problem I see is that this is now being lumped into a general direction to close everything up, which seems excessive, TBH. I also think the DPL votes are different to any other votes, because the DPL has limited power, and even though a DPL can certainly disrupt or damage the project, in the end it's bound by a time limit. Compared to a GR where the consequences might live long, and where once settled people do not tend to try to overturn these every subsequent year. I've also got concerns about batching up unrelated changes, with potentially controversial ones. And even if minor I'd prefer to see those debundled, even at the cost of additional GRs. Thanks, Guillem
