On Mon, Feb 06, 2017 at 06:04:18PM +, Ian Jackson wrote:
> > ...
> > to Ubuntu). We could do a pretty good service to this type of user to
> > make Debian "easy to install". This installation topic comes up in
> > every talk I have given (see [1] at 35:20) and since 14 years I can not
> > giv
Andreas Tille writes ("About the internal and external view of Blends (Was:
Bug#846002: blends-tasks must be priority:standard and not make a mess out of
tasksel menu)"):
> May be this is the right time to clarify the role of Blends inside
> Debian and I'd like to adju
Hi,
On Sun, Feb 05, 2017 at 12:38:59AM +0100, Tollef Fog Heen wrote:
> > Would it be a sensible compromise to reassign this bug to d-i tagging it
> > RC for buster to make sure a Blends menu will exist in the buster
> > installer.
>
> While I think it's important to get it fixed for buster, I don
On Sat, Feb 04, 2017 at 12:16:01PM +0100, Andreas Tille wrote:
> Would it be a sensible compromise to reassign this bug to d-i tagging it
> RC for buster to make sure a Blends menu will exist in the buster
> installer.
besides what Tollef already said about the severity I think a fresh new bug is
]] Andreas Tille
> On Fri, Feb 03, 2017 at 02:10:43PM +0100, Cyril Brulebois wrote:
> > >
> > > I do have time now, so perhaps while we're reverting those changes
> > > Cyril will be open to persuasion that we could also patch the blends
> > > back in, and make the menu clearer overall using my
On Fri, Feb 03, 2017 at 02:10:43PM +0100, Cyril Brulebois wrote:
> >
> > I do have time now, so perhaps while we're reverting those changes
> > Cyril will be open to persuasion that we could also patch the blends
> > back in, and make the menu clearer overall using my early suggestion
> > of prefi
Hi, first, you've made the point that you were hoping the TC would help
the blends team and the d-i team work together.
I think that Phil's suggestions for a technical approach are quite good,
and I hope that will move forward in the buster cycle.
With regard to stretch, I honestly don't think th
Since I've been asked in an IRC query whether I might be willing to
consider this suggestion:
Philip Hands (2017-02-03):
> I think this is in part a symptom of mixing up multiple questions in
> one request.
>
> There seems to be a consensus that the priority change was misguided,
> and that's th
Ole Streicher writes:
...
>>> The TC has the power to decide here, and you were asked to do so. If you
>>> think that d-i took the right decision, you should decide so (and then
>>> you don't need to use your power), but not just let them decide.
>>
>> That's what the current ballot effectively
Hi Tollef,
On 02.02.2017 21:29, Tollef Fog Heen wrote:
> ]] Ole Streicher
Am 31.01.2017 um 16:26 schrieb Sam Hartman:
> If they don't want to do that for stretch, that's a decision within
> their pervue that we clearly don't have the votes to override.
>> I have read Sams "vote to ov
]] Ole Streicher
Hi
> >> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
[...]
> >>> If they don't want to do that for stretch, that's a decision within
> >>> their pervue that we clearly don't have the votes to override.
[...]
> This makes it a case where one can ask the TC for a decision, if a
Hi Tollef
On 02.02.2017 19:47, Tollef Fog Heen wrote:
> ]] Ole Streicher
>
>> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
>>> If you go back one meeting further, my interpretation is that the consensus
>>> of
>>> the committee seems to be that ultimately this decision belongs to the
>>> install
]] Ole Streicher
> Am 31.01.2017 um 16:26 schrieb Sam Hartman:
> > If you go back one meeting further, my interpretation is that the consensus
> > of
> > the committee seems to be that ultimately this decision belongs to the
> > installer team.
> > That is, in this case, a number of members on t
Sam Hartman writes ("Bug#846002: blends-tasks must be priority:standard and not
make a mess out of tasksel menu"):
> My reading of that is that the consensus of the TC is that the D-I team
> should make this decision.
I can see why Ole is frustrated. I don't think this i
> "Ole" == Ole Streicher writes:
Georg commented that if we're going to delegate to D-I, we should hurry
up and do so unless this turn into another TC failure.
I personally think we've taken long enough this is already a TC failure
and have expressed regret for my actions that contributed to
Hi Sam,
Am 31.01.2017 um 21:45 schrieb Sam Hartman:
> Ole> Hmm, IMO there are two things here: First, in our constitution,
> Ole> the installer team has no specific granted rights, apart from
> Ole> being maintainers of the relevant packages. This makes the Ole>
> conflict primarily a conflict b
Am 2017-02-01 04:45, schrieb Sam Hartman:
What I think several of us did is look at the technical details and
decide we believe that the installer team was the right set of people
to
make this technical decision.
So, I think the TC will make its decisions on a technical foundation a
lot les
> "Ole" == Ole Streicher writes:
Ole> Hi Sam, Am 31.01.2017 um 16:26 schrieb Sam Hartman:
>> If you go back one meeting further, my interpretation is that the
>> consensus of the committee seems to be that ultimately this
>> decision belongs to the installer team. That is, in
Hi Sam,
Am 31.01.2017 um 16:26 schrieb Sam Hartman:
> If you go back one meeting further, my interpretation is that the consensus of
> the committee seems to be that ultimately this decision belongs to the
> installer team.
> That is, in this case, a number of members on the TC seem to believe
> t
> "Ole" == Ole Streicher writes:
Hi.
If you go back one meeting further, my interpretation is that the consensus of
the committee seems to be that ultimately this decision belongs to the
installer team.
That is, in this case, a number of members on the TC seem to believe
that the installer t
Dear Technical Committee,
after reading the CTTE meeting log from 2017-01-26 [1], I feel a bit
disappointed. As far as I understand (I am not a long-term DD yet),
the Technical Committee has the task to decide items, where a
consensus could not be reached. Here, this is obviously the case, as
one
21 matches
Mail list logo
