First, Don, I’d like to thank you for keeping the discussion civil. I have made a serious accusation, and I don’t want it to be an excuse for a mudfight.
Le lundi 17 novembre 2014 à 11:15 -0800, Don Armstrong a écrit : > §6.3.6 does not prevent the CTTE from being presented an issue early. It > stops the CTTE from deciding an issue before a consensus approach has > been attempted. In this particular case, I felt that a consensus > approach had been attempted when this issue came up for a vote. This > particular bug has been open since May, and was discussed at length. There have been discussions, specifically on the debian-ctte mailing lists, about upgrading to systemd only if the system is not at risk of breaking sysadmin changes (inittab, custom init scripts). It strikes me that this possibility has not even been included in the call for votes for this bug. > In retrospect, the CTTE may not be working consensus hard enough, and > for that, I'm sorry. Working to achieve consensus is very difficult, > time consuming, and fraught. It takes a huge time commitment, and even > after spending the time, the CTTE may still have to make a decision. I don’t think it is wrong to want to have a decision at some point, if the attempts at consensus have failed. Keeping issues in the open for months, even years, is not going to magically solve them. It’s not because the resolution is wrong, either. Of course, my opinion is that it is wrong, and that it is going to rain fire on us when upgraded systems do not behave like freshly installed ones. But the point of making decisions is that sometimes they are wrong, and we should be able to deal with whatever fixing is required later. The problem here is that the CTTE gives the feeling of having been played. The same person escalated the problem to the CTTE, framed it into a fake dichotomy, proposed a resolution that ignored the ongoing discussions and alternative proposals, and rushed a vote. Maybe this feeling is unfounded. Maybe all members of the CTTE genuinely believe that there were no other acceptable proposal, after carefully examining the issue and the consequences of all scenarios. If this is the case, we might have a serious communication problem. Because either way, we have a problem of trust that #746578 is not going to improve. > I had naïvely assumed that making what I thought were technically > defensible decisions was good enough. Clearly, enough people in the > project disagree, and want the CTTE to work harder on consensus first > before deciding. I don’t think it has to be the CTTE’s role to build consensus from nothing. But when genuine attempts are being made, constitution §6.3.6 should be honored. > I'm already working to rectify that in the case of #766708, and I'm > certain we could use more help finding consensus with #750135, and maybe > even #741573. If this is something you (or anyone else in the project) > feels strongly about, please, work with the CTTE to help find consensus > on these issues, so we don't actually have to decide. #741573 is a clear-cut case where consensus has been achieved and a single maintainer is deliberately acting against it. After that, what should have been an obvious CTTE decision has been derailed into a lengthy debate on the philosophy of menu systems. When a trivial request takes so much time to decide on, and a complex one is rushed into a hasty resolution, well, maybe that explains the trust issue I was talking about. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416255656.6444.34.ca...@kagura.malsain.org
