Hi Enrico! On Sun, 2014-01-19 at 14:56:27 +0100, Enrico Zini wrote: > On Sun, Jan 19, 2014 at 12:04:17PM +0000, 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