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
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.
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 w
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 manag
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
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.
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
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
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
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
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
s
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
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
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
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 respons
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
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 f
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 directl
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 power
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 dedica
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-co
21 matches
Mail list logo
