TC GR proposals
Dear all, during today's face-to-face meeting at DebConf (with Steve, Andreas, Bdale and myself), we reviewed all currently open issues [0] and discussed informally how we felt about what the next steps should be for each of them, and spread action items between us. Expect moves on various bugs "soon". We also discussed the actual "TC proposing GRs" issue. For the context, during the initial #636783 discussions, Ian proposed various options to facilitate the acceptance of uncontroversial amendments by the TC, in the context of GRs proposed by the TC. His initial idea, was to let the TC delegate this power to one of its members, but this was considered unconstitutional by the secretary. He then came up with the following "promise" that was supposed to come after each GR proposals, it is attached to this mail. During the discussion, we understood this as an attempt at reaching the same effect than the delegation to an individual TC member, only delegating to all of them, through using unusual constitutional gymnastics, with which we didn't really feel comfortable. The crux of the issue is really that the §4.2.1 procedure allowing the TC to automatically trigger GRs is hardly practical for the next parts of the GR procedure (amendments, etc), given §A.1 "discussion and amendments". But the discussion revealed a quite easy way out of this, that doesn't require the complicated "TC promise mechanism": §4.2.1 : "A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers". Given that K is maximum 5 (and will stay 5 as long as there are more than 100 Developers), this means that an GR proposal uncontroversial within the TC can easily be introduced if 6 TC members agree with it (one proposer, 5 sponsors). We therefore concluded that this would be a good way to move forward on these issues: any TC member should propose these and the others (feeling so) would sponsor the GR. The process would then follow as usual. Given how much clearer this process looks like, I'll act boldly and reformat the GR proposals in the repository accordingly. Cheers, OdyX 2. It is not practical for the TC to vote to accept/reject individual amendments to the GR proposal. The TC would wish to delegate its power to accept amendments, to avoid needing the collection of sponsors for uncontroversial changes. However the Secretary has advised that this is not constitutionally acceptable. Therefore, to achieve roughly the same effect, the TC makes the following promise. If any TC member gives notice that the TC accepts an amendment, then at least one of the following will happen: (a) the TC will use its own power under A.1(1) to arrange that the amendment appears on the GR ballot as an option; (b) the TC will use its power under A.1(1) to propose and its power under A.1(2) to accept the amendment, so that the amendment is incorporated in the version voted on; or (c) A member of the TC will publicly notify the amendment's proposer that the amendment will not be accepted after all. In this case TC will wait at least 7 more days before calling for a vote, to give time for the amendment's proposer to collect sponsors. = TC RESOLUTION ENDS =
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
Le mardi, 18 août 2015, 14.01:27 Don Armstrong a écrit : > On Mon, 17 Aug 2015, Sam Hartman wrote: > > > "Don" == Don Armstrong writes: > > Don> On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote: > > >> What about "just" adding Keith's proposal to the ballot, and > > >> let > > >> the Condorcet magic act? > > > > Don> This has sort of been my plan; I just have not had enough > > spare > > Don> cycles in the past few weeks (grant deadlines) to have the > > time > > Don> necessary to work through Keith's plan and shift it into a > > Don> specific patch to policy. > > > > If you add Keith's proposal as well as an explanation of our > > technical objection to what debian-policy came up with it, I might > > even vote for it. > > This is my plan. The proposal needs to be written up as a specific > patch to policy, with a separate rationale, and then we can actually > vote on it as a separate option in the ballot. I'm not convinced: I see Keith's proposal as "TC setting technical policy without actually phrasing the detailed patch for the Debian Policy document" as a fine course of action for us to take. Actually, I'm afraid that crafting the detailed Policy patch would put the concerned sections of Policy under some sort of "TC dome", which I don't see as a desirable outcome. Formulated differently, I prefer deciding on a technical _choice_ rather than a detailed Policy patch. ABC options are to be seen differently, as they are pre-existing Debian Policy patches. Finally, I really have a hard time seeing how crafting a Debian Policy patch ourselves doesn't fall under §6.3.5 "no detailed design work - The TC does not engage in design of new (…) policies", whereas Keith's proposal is more clearly §6.1.1 "decide of any matter of technical policy". Cheers, OdyX
Bug#686235: marked as done (Committee list of decisions on webpage is incomplete)
Your message dated Tue, 18 Aug 2015 20:16:44 +0200
with message-id <20150818181644.gc2...@mails.so.argh.org>
and subject line Webpage extended
has caused the Debian Bug report #686235,
regarding Committee list of decisions on webpage is incomplete
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
686235: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686235
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Stefano Zacchiroli writes ("Re: tech-ctte webpage cleanup"):
> On Wed, Aug 29, 2012 at 03:31:09PM +0100, Ian Jackson wrote:
> > While I was there I noticed some infelicities, so I have:
>
> Thanks Ian. Prodded by this, I've documented the current team formation
> in /intro/organization, which was out of date after recent changes. The
> change will be live at the next website update pulse.
Thanks. (Do you know how often that happens?)
> It seems to me that the history section of appointments in the tech-ctte
> page is out of date: Manoj should be thanked there, AFAICT. Also, Colin
> is not mentioned in the "Formal nontechnical and procedural decisions"
> section. All in all, I'm not sure if it's worth the effort of keeping up
> to date that part...
I think we should do so. Someone (I volunteer) should go through the
list archives and look for anything else we're missing. grepping for
"vote" might do it.
It's a relatively small amount of work to do this when we make a final
decision, compared to the effort of discussing, voting, etc. If it
gets too tedious we can probably automate it a bit more.
Ian.
--- End Message ---
--- Begin Message ---
Hi,
I added more decisions to the web page, so that it should now be
complete. For this reasons I close this bug report now, if anything
else is missing please inform me.
Andi--- End Message ---
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
On Mon, 17 Aug 2015, Sam Hartman wrote: > > "Don" == Don Armstrong writes: > > Don> On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote: > >> What about "just" adding Keith's proposal to the ballot, and let > >> the Condorcet magic act? > > Don> This has sort of been my plan; I just have not had enough spare > Don> cycles in the past few weeks (grant deadlines) to have the time > Don> necessary to work through Keith's plan and shift it into a > Don> specific patch to policy. > > If you add Keith's proposal as well as an explanation of our technical > objection to what debian-policy came up with it, I might even vote for > it. This is my plan. The proposal needs to be written up as a specific patch to policy, with a separate rationale, and then we can actually vote on it as a separate option in the ballot. I'm trying to find some spare cycles to work on this in the next two weeks, but if someone beats me to it, excellent. > If you were to add a recommendation to ballot option B that under > 6.1.5 we ask debian-policy to consider Keith's proposal, I'd prefer > that to the current text. If no one gets around to handling the above, that might be what we have to do. [...] > While we're not overturning anything in the sense of an override here, > I think we owe an explanation for our actions, and I feel really > strongly about that. Ideally the patch and its rationale should stand alone without the need for a separate text. But that said, if you disagree that the rationale is not sufficient once it exists, I'll either try to modify it or draft a separate text. -- Don Armstrong http://www.donarmstrong.com I don't care how poor and inefficient a little country is; they like to run their own business. I know men that would make my wife a better husband than I am; but, darn it, I'm not going to give her to 'em. -- The Best of Will Rogers
Bug#636783: Bug#795855: #636783 - New bugs for individual issues
On Tue, Aug 18, 2015 at 11:12:08AM -0700, Josh Triplett wrote: > On Mon, 17 Aug 2015 15:39:06 +0200 Didier 'OdyX' Raboud > wrote: > > - #795855 > > Introduction of formal cloture vote for the TC > > - #795857 > > TC chair appointment > Given context, I think these originally shotgunned proposals (especially > these two) need careful re-evaluation, to figure out how much actual > point they have and how much they're just a reflection of a past spite. > The "cloture" proposal honestly seems like a needless pile of additional > process. Anyone can call for a vote at any time, and I don't think > that's a bug; if people agree that a vote is warranted, they can vote, > and if they don't, they can vote "further discussion". If even a simple > majority is opposed to holding a vote, they can all vote "Further > Discussion". Anyone else can *also* call for a vote at any time, if > they feel there's another issue to discuss. > So, I would suggest that the "cloture" proposal should be consigned to a > historical note along with the fit of pique it came from. This was no fit of pique. I consider the fact that any single member of the TC can cut short discussion by calling a vote to be a serious bug in a process that is otherwise designed to favor consensus instead of mere majority rule. It is precisely at those times that the TC has not found consensus that the process should be proofed against procedural abuses (which I still consider the call for votes on the init system to have been, regardless of whether there was any malicious intent). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
Bug#795855: #636783 - New bugs for individual issues
On Mon, 17 Aug 2015 15:39:06 +0200 Didier 'OdyX' Raboud wrote: > - #795855 > Introduction of formal cloture vote for the TC > > - #795857 > TC chair appointment Given context, I think these originally shotgunned proposals (especially these two) need careful re-evaluation, to figure out how much actual point they have and how much they're just a reflection of a past spite. The "cloture" proposal honestly seems like a needless pile of additional process. Anyone can call for a vote at any time, and I don't think that's a bug; if people agree that a vote is warranted, they can vote, and if they don't, they can vote "further discussion". If even a simple majority is opposed to holding a vote, they can all vote "Further Discussion". Anyone else can *also* call for a vote at any time, if they feel there's another issue to discuss. So, I would suggest that the "cloture" proposal should be consigned to a historical note along with the fit of pique it came from. For 795857, the TC chair process, there is indeed a lack of documented process for how and when the TC chair is determined; I think the suggestion Bdale referenced makes sense, to re-evaluate this in light of the new term limits: On Tue, 18 Aug 2015 14:36:28 +0200 Bdale Garbee wrote: > The suggestion someone made somewhere during this discussion that I > liked the best was quite simple. Every time there is a change in the > membership of the TC, we should have a vote on who should serve as > chair. Given the term limits now in place, that would guarantee a > fairly regular need to vote on the TC chair. - Josh Triplett
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
Le Mon, Aug 17, 2015 at 06:14:45PM +0200, Didier 'OdyX' Raboud a écrit : > Hi Charles, and thanks for your feedback, Thanks as well for your prompt answer :) Here are a few point-to-point comments. Altogether, I would happily support option D if it were further amended. > the last sentence of D1, put in force > using §6.1.1 (decide on any matter of technical policy): "Applications > providing a .desktop file should not provide a Debian menu file." This > will allow maintainers that _do_ provide .desktop files to stop > providing .menu files as well. Indeed, I have overlooked that important part. Sorry for this. > With D1 in place, I expect .menu files to > start disappearing from the archive at a good pace; it will become > somewhat urgent for those relying on the menu system to work towards > having this .desktop-to-menu translation infrastructure in place. An alternative would be to develop support for the FreeDesktop menu on those platforms that only have the Debian menu at the moment. Since option D is calling for volunteer work, which may be quite unusual for the TC, I think that it would be important that it either provides alternatives like the one above, or explain briefly why they were not retained in the final resolution. > > https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries > > I think it is quite reasonable to assume that Keith's proposal is a > derivative of that proposal. Thanks. I would appreciate if it would be acknowledged, I am a bit academic by training... > The TC is currently trying to decide whether to decide on the conflict > (AB vs C) or to decide on the 'menu' matter of technical policy (D). In my impression, it is not a good thing to conflate two different kind of decisions in the same vote. This said, the current portfolio of options is a good ground for focusing on the technical aspects. C: Status quo reaffirming the wording of the Policy and the importance of the Debian Menu (needed even for the Python interpreter, etc). Z: Status quo by inaction. AB: Softening the requirement of the Debian Menu. D: Migration to the FreeDesktop format, and therefore disparition of the Debian Menu if nobody works on this migration. (By the way, I am not sure how to interpret the difference between A and B.) I have invested a lot of time on AB as I was looking for a compromise that would satisfy broady, but as I wrote more recently, I also do not mind a more radical outcome. I would support option D it if we resolve the the point below. > From what I understand of your opposition, you're afraid that further > discussions around softening the "all packages that provide applications > that need not be passed any special command line arguments for normal > operation should provide a FreeDesktop .desktop file entry for those > application" part would be met with unresolvable opposition from Bill, > right? What about the following formulation then (not yet entirely > convinced, but I hope that's a step forward)? > > > 1. The Technical Committee resolves that applications providing a > > .desktop file should not provide a Debian menu file. This is the first half of solving the problem. The second would be to add that the "should" requirement of the Policy's section 9.6, paragraph 2, is changed to "may". Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan
Bug#795857: simple solution?
The suggestion someone made somewhere during this discussion that I liked the best was quite simple. Every time there is a change in the membership of the TC, we should have a vote on who should serve as chair. Given the term limits now in place, that would guarantee a fairly regular need to vote on the TC chair. It would also allow any existing member who felt strongly enough about it to force a vote by retiring from the TC. Bdale signature.asc Description: PGP signature
Re: Meeting today @ DebConf ?
Le mardi, 18 août 2015, 09.35:36 Didier 'OdyX' Raboud a écrit : > as far as I know, Bdale, Steve, Adam and myself are now present at -- Sorry for that. My memory starts failing me apparently… :/ Cheers, OdyX
Re: Meeting today @ DebConf ?
Didier 'OdyX' Raboud writes: > What about meeting in the foyer at 11h30 [0]? I can do that. Bdale signature.asc Description: PGP signature
Meeting today @ DebConf ?
Dear TC, as far as I know, Bdale, Steve, Adam and myself are now present at DebConf, but that's only going to last until tonight. Anyway, I'm proposing to have a meeting sometime today, to go over our list of issues, discuss how we want to proceed with the warmest of them, etc. What about meeting in the foyer at 11h30 [0]? Cheers, OdyX [0] Afternoon coffee break doesn't work because group photo, and I'm replacing Nicolas for the GSoC talk scheduled 14h-15h45. signature.asc Description: This is a digitally signed message part.
