Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution

[Ansgar Burchardt]

Didier 'OdyX' Raboud writes:
> Le vendredi, 22 juillet 2016, 12.28:38 h CEST Jakub Wilk a écrit :
>> Luckily there's an awesome non-gendered and non-furnitured alternative:
>>
>> President
>
> Point is, the TC  is constitutionally only about half-surrogating
> MIA DPLs and breaking ties. The non-constitutional part of the duty is much
> more about making meetings happen, running the administrativia, etc. In short,
> it's much more of a 'Secretary' role, rather than a 'President' role.

That sounds like what a president does when there is no dedicated
secretary role (which we don't have for the ctte)?

But there are also the choices of moderator, facilitator, and convenor
left from [1].  Though "moderator" is also a thing in certain contexts
("neutron moderator") and the Wikipedia article on "facilitator"[2]
mentions a neutral position which doesn't quite fit with tie-breaking.

  [1] 
  [2] 

All non-Chair choices also avoid confusion with a possible future Chair
of the Technical Committee that might be used as part of an inauguration
ceremony ;)

Ansgar

Re: General Resolution: Fix Minor Bugs in Constitution

[Ansgar Burchardt]

Kurt Roeckx  writes:
> The following ballot is for voting on updating the standard resolution
> procedure.
[...]
> Also, note that you can get a fresh ballot any time before the end of
> the vote by sending a signed mail to
>bal...@vote.debian.org
> with the subject "gr_srp".
[...]
> The dedicated email address this ballot should be sent to is:
>
>   gr_cttet...@vote.debian.org

Shouldn't this be "gr_srp@vote.d.o"?

Ansgar

Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]

[Ansgar Burchardt]

Hi Andrey,

Andrey Rahmatullin  writes:
> On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote:
>> What's the procedure for removing someone from the technical committee?
> Option 1: Agreement of DPL and an 1:1 majority in TC (6.2.5).
> Option 2: GR with a 2:1 majority to act with TC powers (4.1.4).
> Option 3: GR with an 1:1 majority to act with DAM powers (4.1.3) to expel
> the person from the project altogether.

I think you forget the option that (I think) is the least personal
damaging one:

  Option 0: Ask the member to consider stepping back himself.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d28v4f7k@deep-thought.43-1.org

Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]

[Ansgar Burchardt]

Hi Bas,

Bas Wijnen  writes:
> On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote:
>> 17:34:12  Diziet: I don't think that stating that we
>> don't want to swap on upgrades is something we can agree on
>> 17:34:25  Diziet: at least, not while the GR is
>> happening which seems to directly address this part of the question
>> 
>> 17:34:28  dondelelcaro: That's not the question.  The
>> question is whether it's something that would pass a TC vote.
[...]
> Fair enough, this is a part where the level of civility is lower.  But
> Ian doesn't make an unreasonable point.  If those who oppose him are
> forcing their side with an overruling vote, why should he refrain from
> doing the same?  Consensus is great, but if we can't get there, we do
> want a decision.  And majority is better than nothing.

I find it at least very disrespectful to propose a technical committee
resolution that seems to contradict a GR currently in the voting phase.

> The only problematic part I see is that he gets carried away at times.
> That's a very minor issue, and I forgive him, as long as he isn't
> insulting people.  In fact, I not only forgive him; I applaud him for
> it; it shows that he cares.

I don't think it's a minor issue if a member of a committee that exists
to arbitrate on a basis of technical arguments starts to repeatedly
assert one side acts not only out of bad faith, but out of malice.
You might want to investigate why someone wrote [1].

Do you expect people who are told they act out of malice to trust that
this is still a fair decision process? I do not, and I think it's a
good reason to ask somebody to consider to step back.

Ansgar

  [1] 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9y74fao@deep-thought.43-1.org

Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)

[Ansgar Burchardt]

Hi,

Ian Jackson  writes:
> Ian Jackson writes ("Amendment (Re: Re-Proposal - preserve freedom of choice 
> of init systems)"):
>> For the avoidance of any doubt, I currently intend to not accept any
>> further amendments.  That means that the minimum discussion period
>> will not be extended any further (unless the DPL intervenes).  I
>> currently intend to call for a vote when the minimum discussion period
>> elapses, 2 weeks from now.
>
> That was at `Date: Sun, 19 Oct 2014 14:59:16 +0100'.
>   $ date -d 'Sun, 19 Oct 2014 14:59:16 +0100 +14 days'
>   Sun Nov  2 13:59:16 GMT 2014
>   $
>
> So by my calculations the minimum discussion period (which has not
> been varied by the Project Leader) expired about half an hour ago.

There was a later change to an amendment[1]. As this was done under
A.1.5 and not under A.1.6 this does reset the discussion period as far
as I understand.

The earliest Call for Votes would thus be possible on
  Wed, 22 Oct 2014 07:45:39 +0900 + 2 weeks,
that is in about two more days.

Ansgar

  [1] 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oaspfm7b@deep-thought.43-1.org

Re: Tentative summary of the amendments

[Ansgar Burchardt]

Hi,

On 10/24/2014 02:02 PM, Josselin Mouette wrote:
> Aigars Mahinovs  wrote: 
> On 24 October 2014 12:35, Ansgar Burchardt  wrote:
> > In fact, they want to require that if P supports only A (and not 
> A|B)
> > that the maintainers of P have to patch P to make it support B. In 
> the
> > good old days[tm] it would be the responsibility of the people 
> wanting
> > to use B to submit patches to make P work with B (but here I suspect
> > many people demanding support for B do not even use P[1]...).
> 
> And this is exactly why this GR is moot: it contradicts the
> constitution. Even if it passes, you couldn’t force maintainers of A
> (systemd) or P (GNOME, KDE, Xfce) to maintain B (systemd-shim) or fix
> bugs in B.

I don't think it contradicts the constitution: we do require certain
work to accept packages in Debian, like removing non-free stuff,
document copyright holders and licenses, making the package build on
buildds, ...

However there needs to be a fairly broad consensus about these
requirements and, if you change the requirements, people willing to
actually do the work. Otherwise we end with this:

> Eventually, bugs in B would result in RC bugs in P that the release team
> would have to ignore because P is too useful.

Which is why I think this GR is a bad idea...

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544a449a.3080...@debian.org

Re: Tentative summary of the amendments

[Ansgar Burchardt]

Hi,

Aigars Mahinovs  writes:
> On 24 October 2014 12:35, Ansgar Burchardt  wrote:
>> In fact, they want to require that if P supports only A (and not A|B)
>> that the maintainers of P have to patch P to make it support B. In the
>> good old days[tm] it would be the responsibility of the people wanting
>> to use B to submit patches to make P work with B (but here I suspect
>> many people demanding support for B do not even use P[1]...).
>>
>>   [1] In particular I heard somebody asked if anybody wanted to help
>>   with this work and from my understanding the response was not
>>   very enthusiastic... Why patch something you don't use after all?
>
> The root of the problem is coming from upstream not caring about
> alternative init systems. To take the logind case as an example - each
> of the dependencies from GDM to systemd make perfect sense in
> isolation. However, the end result (was) that GDM only worked with
> systemd almost by accident. No developer in that chain was compelled
> to run this under other init systems.

Nobody stops people from submitting patches... But nobody seems to be
willing to do so -- presumably because nobody using the software is
interested enough to do so.

> However these choices heavily impact our users who (for whatever
> reasons) want or need to use another init system. Such users are used
> to having to write an odd init script for some service - that is an
> acceptable extra work for using a non-default init system. However it
> is a much harder task to have to implement a new API introduced by
> systemd or creating something like systemd-shim. We should not be
> pushing such burdens to our users.

But instead we should take away packages that depend on a features only
provided by a specific init system (for whatever reason)? Do you think
we serve users better by taking away options from them?

So, if P has a hard dependency on systemd-as-pid1, why do you want to
take P away from me? Because people not liking systemd are more
important than people not caring about it or even being okay with it?

I don't like some software too, but am sometimes required to use it
without an alternative. Can I demand that I can use packages without
said software? Like demanding libraries having to provide language
bindings for at least two languages so I don't have to use PHP[1]? :)

Ansgar

  [1] Please don't take offense for this example.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877fzpn4ea@deep-thought.43-1.org

Re: Tentative summary of the amendments

[Ansgar Burchardt]

Hi,

Aigars Mahinovs  writes:
> This is the same requirement as with regular dependencies. If you want
> into next release, then all your dependencies must be there.

No, it's not. In the past your package P could depend on A|B and
everything was fine if either A or B was there. If B was broken and
only A remained, then the people wishing to use B over A had to fix B.

Now some people propose to push the task of maintaining B to the people
maintaining P or A.

In fact, they want to require that if P supports only A (and not A|B)
that the maintainers of P have to patch P to make it support B. In the
good old days[tm] it would be the responsibility of the people wanting
to use B to submit patches to make P work with B (but here I suspect
many people demanding support for B do not even use P[1]...).

Ansgar

  [1] In particular I heard somebody asked if anybody wanted to help
  with this work and from my understanding the response was not
  very enthusiastic... Why patch something you don't use after all?


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnp1olmv@deep-thought.43-1.org

Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain

[Ansgar Burchardt]

Luca Falavigna  writes:
> ** Begin Alternative Proposal **
>
>   0. Rationale
>
>   Debian has decided (via the Technical Committee) to change its
>   default init system for the next release. The Technical Committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR reaffirms the Debian Social Contract #4, in such a way
>   that Debian acknowledges the choices made by both the software
>   developers (also known as upstream developers) and the Debian
>   package maintainers to provide the best free software to our users.
>
>   Upstream developers considering specific free software (including,
>   but not limited to, a particular init system executed as PID 1)
>   fundamental to deliver the best software releases, are fully entitled
>   to require, link, or depend on that software, or portions of it.
>
>   Debian maintainers' work is aiming to respect the Debian Social
>   Contract, in such a way to provide our users the best free software
>   available.
>
>   Debian maintainers are fully entitled to provide modifications to
>   the free software packages they maintain as per DFSG #3, if they
>   judge this necessary to provide the best software releases.
>   On the other hand, Debian maintainers are fully entitled to adhere
>   to upstream's decisions to require, link, or depend on specific free
>   software (including, but no limited to, particular init system executed
>   as PID 1), if they consider it necessary to prevent delivering broken,
>   buggy, or otherwise incomplete software packages.
>
> The Debian Project states that:
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Specific init systems as PID 1
>
>   Debian packages may require a specific init system to be executed
>   as PID 1 if their maintainers consider this a requisite for its proper
>   operation by clearly mark this in package descriptions and/or
>   by adding dependencies in order to enforce this; and no patches
>   or other derived works exist in order to support other init systems
>   in such a way to render software usable to the same extent.
>
> 3. Evidence of defects (bugs)
>
>   We strongly reaffirm Debian maintainers are not deliberately hiding
>   problems (Social Contract #3). No technical decisions shall be
>   overruled if no proper evidence of defects, issued in the Debian Bug
>   Tracking system, is found. Fear, uncertainty, and doubt are not
>   considered as evidence of defects.
>
> This resolution is a Position Statement about Issues of the Day
> (Constitution 4.1.5), triggering the General Resolution override clause
> in the TC's resolution of the 11th of February.
>
> The TC's decision on the default init system for Linux in jessie stands
> undisturbed.
>
> However, the TC resolution is altered to add the additional text above
> in sections #1, #2 and #3.
>
> ** End Proposal **

Seconded.

Ansgar


pgp4YHep0PFIt.pgp
Description: PGP signature

Your behavior on Debian mailing lists

[Ansgar Burchardt]

Hi Craig,

Craig Sanders  writes:
> dishonest "debating" like this (i.e. petty ego-wankers like you
> point-scoring by malicious twisting of words and selective misquoting),
> is why i haven't bothered for years. i should have remembered that i
> have better things to do with my time.

If you just come back from doing nothing to start insulting people who
actually *do* a lot of work, please consider using your time for
something more useful. Maybe you should also just consider to just leave
offically...

Please also at least read [1].

Ansgar

  [1] 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbnhc23o@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Hi Ian,

Ian Jackson writes:
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:

Could you change the formulation here?

Several people seem to understand this as "must work with *all* init
systems"; however as far as I understood from earlier discussions you
only want to forbid depending on *one* specific init system, that is
dependencies like init-A | init-B would still be allowed.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnpawhml@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Simon Richter  writes:
> On 17.10.2014 16:54, Daniel Kahn Gillmor wrote:
>>> If the fix is not easy then we have three options: the release team
>>> mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is
>>> removed from jessie.
>
>> The implication here appears to be troubling for any upstream who wants
>> to rely on specific features of a given initsystem.
>
> The implication of not making sure packages get along with each other
> may be that system administrators need to decide which of the mutually
> exclusive desktop systems they can offer their users.

That's however not what the proposal forbids: A can depend on
init-A|init-B, B can depend on init-B|init-C and C can depend on
init-C|init-A. There's no way to install both A, B and C.

> No, but I think we should reject packages that are mutually exclusive
> with unrelated packages because they require incompatible choices of
> packages they depend on.

Again, this does seem to be a different issue than what the GR proposes.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4sezb8o@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Hi,

Simon Richter  writes:
> On 17.10.2014 11:52, Marco d'Itri wrote:
>>> for 30 years so why are some people pushing _so hard_ to replace it NOW and 
>>> by something
>>> as controversal as the systemd stuff.
>
>> A vocal minority and a lot of trolls do not make something
>> controversial.
>
> No, the majority disregarding the needs of the minority makes it
> controversial.
>
> Debian has always aimed to be the "universal" operating system and be
> inclusive of desktop users, system administrators and system builders at
> the same time.
>
> Debian "jessie" fails to work in several instances on my embedded
> systems where "wheezy" used to work. I'd call that a severe regression,
> however for some reason that no longer counts because the majority has
> no such issues.

Bugs happen with every release...

I note that it was *not* possible to switch init systems in Wheezy in a
supported way (in particular sysvinit is essential and various things
get very unhappy if it gets uninstalled), but you seem to treat Jessie
as more problematic even though it allows switching init systems? How
come?

And is "you cannot switch init systems (at all)" to "you cannot
switch init systems if you want to run " a regression that takes away
choice?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbni3152@deep-thought.43-1.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ansgar Burchardt]

Hi,

Joey Hess  writes:
> Lucas Nussbaum wrote:
>> I am therefore bringing forward an alternative proposal, deeply inspired
>> from the "Advice: sysvinit compatibility in jessie and multiple init
>> support" option of the TC resolution on init system coupling[1], which
>> was originally written by Russ Allbery[2] and was then amended by many
>> participants to the discussion in February 2014.
>
> I am very uncomfortable with GRs being used to set technical policy. 
> We have never before has a GR that did so. It can lock us into technical
> decisions which we then need a whole other GR process to get us out of.
> And mass voting on technical minutia is no way to run a distribution.

The GR about DMs[1] did set technical policy in so far as it prescribed
technical details of the initial implementation, including for example
the "DM-Upload-Allowed: yes" field.

However it implicitly allowed changing the details later without a GR by
just setting "inital policy".

Maybe something similar could be done here?

Ansgar

  [1] 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94uedqk@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Aigars Mahinovs  writes:
> We have all kinds of policies about what is fine in a package and what
> is a Release Critical bug. That is a big part of what makes a
> distribution. This simply adds - "must be able to work with any init
> system running at PID 1" to those requirements.

No, it does not mean packages have to work with *any* init system. It's
specifically aimed against a specific init replacement, see [1].

Ansgar

  [1] 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjcvrfnu@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Steve Langasek  writes:
> On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote:
>> Hurray, what a great idea to delay everything *now*.
>
>> And all because some people believe in conspiracy theories about Red
>> Hat...
>
> This response is uncalled for.  The /existence/ of conspiracy nuts is no
> reason to insult the members of the Debian community who are unhappy with
> the increasingly monolithic approach to system design that is being
> advocated in some quarters.

Fine, conspiracy theories might be a bit too much. Let's call it
strategic alliances that are a very real threat to Debian that are
mediated by shared employment and might also involve corporate
alliances.

Ansgar
 - still slightly irritated by endless threads on -user@ -


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppdrvog8@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Ian Jackson  writes:
> I think that if necessary we might have to delay the release.  That
> would be a matter for the release team.  I would be very unhappy if we
> ditched the ability of people to choose a different init system simply
> to maintain our release schedule.

Hurray, what a great idea to delay everything *now*.

And all because some people believe in conspiracy theories about Red
Hat...

Anyone around for the alternative choice of just one init system? In the
same spirit of just one libc? (Yeah, choice of course does not include
the C library or the kernel if it's just anti-evil-Red-Hat...)

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738anyipe@deep-thought.43-1.org

Re: Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Hi,

On 03/01/2014 00:45, Matthew Vernon wrote:
> 2. Loose coupling of init systems
> 
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
> 
>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
>  systems
> 
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
> 
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
> 
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.

So if someone packages a new init system that is not compatible with
existing init scripts (e.g. if it does not support /etc/init.d/* as a
fallback), then it won't be able to start any service.

Being not able to start a service with a given init system is probably
not a tolerable bug.

So by providing a new init system, one can make all packages providing
daemon startup files for other init systems instantly buggy? I doubt
this is the intention, but the current wording seems to say so.

In addition I would find it nice if the full text of the effective
changes would be included somewhere in the resolution, for example in a
seperate section at the end. Having only a diff makes things more
confusing, especially when one references the GR text at a later time.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5316000...@debian.org

Re: Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Hi Ian,

Ian Jackson  writes:
> It answers this question: Suppose the work is not done.  Ultimately
> then we would have to drop either (a) GNOME or (b) non-systemd init
> systems, and non-Linux kernels.  What choice should we make ?

You might be interested in the discussion in #727708. There it was
pointed out several times that these are not the only options.

> For me the answer is: We should preserve diversity and freedom of
> choice, at the cost of functionality.  Making that statement now,
> very clearly, will make that doomsday scenario less likely.

I think it's sad to see iptables, several drivers and their reverse
dependencies go just because it has no support for FreeBSD and thus
limits diversity and choice, but if you think this is the way
forward...

Could you please also look into the problem of lock-in into specific
version control systems? There the risks are even higher: the data is
stored in non-standard formats that other VCS systems might not be able
to read! I think it's important not to force users into this slavery and
forbid dependencies on specific VCS systems. We need to drop packages
enforcing such dependencies sooner rather than later!

Ansgar


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ob1nfkj2@eisei.43-1.org

Re: [Proposal] GR: Selecting the default init system for Debian

[Ansgar Burchardt]

Hi,

Guillem Jover  writes:
> ,--- DRAFT GR TEXT ---
>
> A General Resolution to select the default init system for Debian.
>
> Option A
[...]
> Option H

If people want to have a GR on the init system, could we please not
entangle two issues in a single vote:

1. Default init system for jessie.
2. Init support in jessie+1.

Also option C "Defer the decision to the Technical Committee" will be
reduntant with another option once the TC makes a decision. I therefore
suggest to wait until they made at least a decision on the default init
on Linux[1].

Ansgar

  [1] Provided they don't explode before that.


-- 
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/8761p5urjx@deep-thought.43-1.org

Gergely Nagy: enough packaging manpower?

[Ansgar Burchardt]

Hi,

while reading algernon's platform I stumbled over the two sentences
"More packages, more packagers? A solved problem" and "Not raw,
packaging manpower - with hundreds of people, we have that covered".

How do you think about the current state of reviewing uploads for
maintainers without upload privileges (for both new packages and updates
to existing packages)?

Regards,
Ansgar


-- 
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/4f5e0c5c.1030...@43-1.org