TC GR proposals

2015-08-18 Thread Didier 'OdyX' Raboud
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

2015-08-18 Thread Didier 'OdyX' Raboud
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)

2015-08-18 Thread Debian Bug Tracking System
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

2015-08-18 Thread Don Armstrong
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

2015-08-18 Thread Steve Langasek
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

2015-08-18 Thread Josh Triplett
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

2015-08-18 Thread Charles Plessy
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?

2015-08-18 Thread Bdale Garbee
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 ?

2015-08-18 Thread Didier 'OdyX' Raboud
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 ?

2015-08-18 Thread Bdale Garbee
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 ?

2015-08-18 Thread Didier 'OdyX' Raboud
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.