On 19/01/14 03:25, Ben Hutchings wrote: > >> 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. > [...] > > Constitutionally, a GR is the last resort in that it can overrule every > other decision. A GR can settle a decision finally but does *not* > create consensus. So if you honestly think that more time should be > allowed for a consensus to arise, perhaps you should propose a GR that > says this issue is not ripe for the TC to decide on and sets some > minimum delay before it can be brought to the TC again.
It is not about the TC at all (unless they volunteer to do the work to implement any decision they make) Ultimately, whatever decision making process is used (GR, TC, etc) there needs to be some suggestion about who will actually do what and who presumably won't do anything or what will stop working E.g. if we choose systemd, who will implement all the things that need to be changed outside the Gnome related packages? What will immediately fail if not adapted to systemd? If we choose Upstart, it is not quite ready to do everything systemd would do and we have to trust the developers to follow through on their commitments to fill those gaps. I personally believe their intentions are good but promises are never the same as releases. If we decide to give them our trust and for any reason they can't deliver on time, what would we fall back on, is it enough to say we would just keep sysvinit for another 2 years, or would we defer the release and wait for them? Every option - and every fall back option - needs to be explained and accompanied by some details about who will do what if that option is chosen, if it hits a snag, etc. Only then do we have a list of choices for a GR -- 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/52db97ff.8070...@pocock.com.au
