Re: Releasing bullseye on 14 August 2021 [Was Re: Finding a tentative bullseye release date]

[Laura Arjona Reina]

 Hi all
I'm also available, adding myself below:

El 22 de julio de 2021 21:18:43 CEST, Paul Gevers  escribió:
>Hi all,
>
>Thanks to the reply from Ansgar, we now have a release date for
>bullseye: 14 August. For the avoidance of doubt, this is *not* a
>tentative date anymore. I'll do a proper announcement later today or
>tomorrow evening.
>
>14 August (day before DebCamp)
>   RT: Adam
>   Image: Steve, Andy
Press: Donald, Laura
>   FTP: Ansgar
>
>Paul
>
Thanks everybody!
Kind regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Re: Releasing bullseye on 14 August 2021 [Was Re: Finding a tentative bullseye release date]

[Jonathan Carter]

On 2021/07/22 21:18, Paul Gevers wrote:
> Thanks to the reply from Ansgar, we now have a release date for
> bullseye: 14 August. For the avoidance of doubt, this is *not* a
> tentative date anymore. I'll do a proper announcement later today or
> tomorrow evening.
> 
> 14 August (day before DebCamp)
>   RT: Adam
>   Image: Steve, Andy
>   Press: Donald
>   FTP: Ansgar

Thank you so much to each and every person (I know not all are listed
above) for making this release date even possible!

-Jonathan

Releasing bullseye on 14 August 2021 [Was Re: Finding a tentative bullseye release date]

[Paul Gevers]

Hi all,

Thanks to the reply from Ansgar, we now have a release date for
bullseye: 14 August. For the avoidance of doubt, this is *not* a
tentative date anymore. I'll do a proper announcement later today or
tomorrow evening.

14 August (day before DebCamp)
RT: Adam
Image: Steve, Andy
Press: Donald
FTP: Ansgar

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Ansgar]

Hi,

On Tue, 2021-07-20 at 22:35 +0200, Paul Gevers wrote:
> We currently don't have any day yet with all involved
> teams comfortably present, the one coming closest is 4 September.
> Somebody from ftp available on 14 august?

That should be doable.

Ansgar

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all,

Current overview to check if I got things right and to hopefully trigger
more replies. We currently don't have any day yet with all involved
teams comfortably present, the one coming closest is 4 September.
Somebody from ftp available on 14 august?

14 August (day before DebCamp)
RT: Adam
Image: Steve, Andy
Press: Donald
FTP:
21 August (last day of DebCamp)
RT: Adam, elbrus
Image:
Press: 1/2 (not ideal)
FTP:
28 August (DebConf)
RT: elbrus
Image:
Press:
FTP: Joerg
4 September
RT: Adam, elbrus
Image: Steve, Andy
Press:
FTP: Joerg
11 September:
RT: Adam, elbrus, Sebastian
Image: Andy
Press:
FTP: Joerg
18 September:
RT: Adam, elbrus
Image: Andy
Press: Donald
FTP:

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Sebastian Ramacher]

On 2021-07-17 22:25:17, Paul Gevers wrote:
> Hi all,
> 
> On 11-07-2021 21:11, Paul Gevers wrote:
> > With less than three weeks to go until the tentative release date, I
> > would love to confirm the date by now, but there is a serious issue with
> > crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what
> > it means for solving the debian-installer blocking issues in time), I'm
> > not aware of other blocking issues, so let's hope the teams involved can
> > recover in time.
> 
> Albeit there is some progress, we think it better for the people
> involved to now say that we will *not* release on July 31.
> 
> Unfortunately, that means that we have to start looking for a new date
> again. Assuming what we'll learn in the upcoming week or two is good, I
> propose to already start the list below with two weeks after the
> previous date. Upcoming time is around DebConf, I can imagine it could
> even be an advantage, especially as that's on-line, let's see.
> 
> 14 August (day before DebCamp)
> 21 August (last day of DebCamp)
>   RT: elbrus
> 28 August (DebConf)
>   RT: elbrus
> 4 September
>   RT: elbrus
> 11 September:
>   RT: elbrus

11 September works for me. I am going to be on VAC on 28 August and 4
September. On the other dates I can try to be around, but cannot commit.

Cheers
-- 
Sebastian Ramacher

Re: Finding a tentative bullseye release date

[Joerg Jaspert]

On 16197 March 1977, Paul Gevers wrote:


Albeit there is some progress, we think it better for the people
involved to now say that we will *not* release on July 31.



Unfortunately, that means that we have to start looking for a new date
again. Assuming what we'll learn in the upcoming week or two is good, 
I

propose to already start the list below with two weeks after the
previous date. Upcoming time is around DebConf, I can imagine it could
even be an advantage, especially as that's on-line, let's see.


I am away from 7th to 21st August (including both), at a place with very
bad internet, so those are out for me.


14 August (day before DebCamp)
21 August (last day of DebCamp)
RT: elbrus


Not me.


28 August (DebConf)
RT: elbrus
4 September
RT: elbrus
11 September:
RT: elbrus


Can do all three.

--
bye, Joerg


signature.asc
Description: PGP signature

Re: Finding a tentative bullseye release date

[Adam D. Barratt]

On Sat, 2021-07-17 at 22:25 +0200, Paul Gevers wrote:
> 14 August (day before DebCamp)
> 21 August (last day of DebCamp)
>   RT: elbrus

These both look OK.

> 28 August (DebConf)
>   RT: elbrus

That's a holiday weekend in the UK; I'll be visiting family and then
the Debian UK BBQ.

> 4 September
>   RT: elbrus
> 11 September:
>   RT: elbrus

Either of these work for me. The 18th also does if need be (I will then
be away from Monday morning (the 20th) for a few days).

Regards,

Adam

Re: Finding a tentative bullseye release date

[Andy Simpkins]

On 18/07/2021 00:24, Donald Norwood wrote:

Hi!

On 7/17/21 4:58 PM, Steve McIntyre wrote:

On Sat, Jul 17, 2021 at 10:25:17PM +0200, Paul Gevers wrote:

Hi all,

On 11-07-2021 21:11, Paul Gevers wrote:

With less than three weeks to go until the tentative release date, I
would love to confirm the date by now, but there is a serious issue with
crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what
it means for solving the debian-installer blocking issues in time), I'm
not aware of other blocking issues, so let's hope the teams involved can
recover in time.

Albeit there is some progress, we think it better for the people
involved to now say that we will *not* release on July 31.

Unfortunately, that means that we have to start looking for a new date
again. Assuming what we'll learn in the upcoming week or two is good, I
propose to already start the list below with two weeks after the
previous date. Upcoming time is around DebConf, I can imagine it could
even be an advantage, especially as that's on-line, let's see.

14 August (day before DebCamp)

Doable.

Works for me

Works for me for images team


21 August (last day of DebCamp)
RT: elbrus

Awkward - wife has plans for us that evening.

Half of the press team is available this day so it is not ideal.

Sorry - away

28 August (DebConf)
RT: elbrus

Debian UK BBQ, argh

away at ^^



4 September
RT: elbrus

Labor day weekend in the U.S. Not a good weekend.

Works fine for me

doable - Isy and I will be unavailable before 1300hrs UTC

11 September:
RT: elbrus

That's the week of my wedding anniversary, I'll be on VAC.

Happy Anniversary!

Works for me


Could we put forth September 18th? We are good for that day without any
issues.

Works for me

Re: Finding a tentative bullseye release date

[Donald Norwood]

Hi!

On 7/17/21 4:58 PM, Steve McIntyre wrote:
> On Sat, Jul 17, 2021 at 10:25:17PM +0200, Paul Gevers wrote:
>> Hi all,
>>
>> On 11-07-2021 21:11, Paul Gevers wrote:
>>> With less than three weeks to go until the tentative release date, I
>>> would love to confirm the date by now, but there is a serious issue with
>>> crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what
>>> it means for solving the debian-installer blocking issues in time), I'm
>>> not aware of other blocking issues, so let's hope the teams involved can
>>> recover in time.
>>
>> Albeit there is some progress, we think it better for the people
>> involved to now say that we will *not* release on July 31.
>>
>> Unfortunately, that means that we have to start looking for a new date
>> again. Assuming what we'll learn in the upcoming week or two is good, I
>> propose to already start the list below with two weeks after the
>> previous date. Upcoming time is around DebConf, I can imagine it could
>> even be an advantage, especially as that's on-line, let's see.
>>
>> 14 August (day before DebCamp)
Doable.
> 
> Works for me for images team
> 
>> 21 August (last day of DebCamp)
>>  RT: elbrus
> 
> Awkward - wife has plans for us that evening.
Half of the press team is available this day so it is not ideal.
> 
>> 28 August (DebConf)
>>  RT: elbrus
> 
> Debian UK BBQ, argh
> 
>> 4 September
>>  RT: elbrus
Labor day weekend in the U.S. Not a good weekend.
> 
> Works fine for me
> 
>> 11 September:
>>  RT: elbrus
> 
> That's the week of my wedding anniversary, I'll be on VAC.
Happy Anniversary!

Could we put forth September 18th? We are good for that day without any
issues.
> 

-- 
--
-
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05

Re: Finding a tentative bullseye release date

[Steve McIntyre]

On Sat, Jul 17, 2021 at 10:25:17PM +0200, Paul Gevers wrote:
>Hi all,
>
>On 11-07-2021 21:11, Paul Gevers wrote:
>> With less than three weeks to go until the tentative release date, I
>> would love to confirm the date by now, but there is a serious issue with
>> crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what
>> it means for solving the debian-installer blocking issues in time), I'm
>> not aware of other blocking issues, so let's hope the teams involved can
>> recover in time.
>
>Albeit there is some progress, we think it better for the people
>involved to now say that we will *not* release on July 31.
>
>Unfortunately, that means that we have to start looking for a new date
>again. Assuming what we'll learn in the upcoming week or two is good, I
>propose to already start the list below with two weeks after the
>previous date. Upcoming time is around DebConf, I can imagine it could
>even be an advantage, especially as that's on-line, let's see.
>
>14 August (day before DebCamp)

Works for me for images team

>21 August (last day of DebCamp)
>   RT: elbrus

Awkward - wife has plans for us that evening.

>28 August (DebConf)
>   RT: elbrus

Debian UK BBQ, argh

>4 September
>   RT: elbrus

Works fine for me

>11 September:
>   RT: elbrus

That's the week of my wedding anniversary, I'll be on VAC.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all,

On 11-07-2021 21:11, Paul Gevers wrote:
> With less than three weeks to go until the tentative release date, I
> would love to confirm the date by now, but there is a serious issue with
> crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what
> it means for solving the debian-installer blocking issues in time), I'm
> not aware of other blocking issues, so let's hope the teams involved can
> recover in time.

Albeit there is some progress, we think it better for the people
involved to now say that we will *not* release on July 31.

Unfortunately, that means that we have to start looking for a new date
again. Assuming what we'll learn in the upcoming week or two is good, I
propose to already start the list below with two weeks after the
previous date. Upcoming time is around DebConf, I can imagine it could
even be an advantage, especially as that's on-line, let's see.

14 August (day before DebCamp)
21 August (last day of DebCamp)
RT: elbrus
28 August (DebConf)
RT: elbrus
4 September
RT: elbrus
11 September:
RT: elbrus

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all,

On 08-06-2021 21:30, Steve McIntyre wrote:
> On Tue, Jun 08, 2021 at 08:50:55PM +0200, Paul Gevers wrote:
>> 31 July: ** tentative ** release date
> 
> Cool, works for me. Pencilled into my calendar now. :-)

With less than three weeks to go until the tentative release date, I
would love to confirm the date by now, but there is a serious issue with
crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what
it means for solving the debian-installer blocking issues in time), I'm
not aware of other blocking issues, so let's hope the teams involved can
recover in time.

We'll keep you posted as we learn more.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Steve McIntyre]

On Tue, Jun 08, 2021 at 08:50:55PM +0200, Paul Gevers wrote:
>
>So, if I did all the booking right (including updates from IRC) we now have:
>
>26 June
>  [Ansgar (ftp), Sebastian (release), Adam (release)]
>3 July
>  [Ansgar (ftp), Paul (release), Adam (release)]
>10 July
>  [Steve + Andy (CD), Paul (release), Adam (release), Graham (release)]
>17 July
>  [Steve (CD), press, Ansgar (ftp), Paul (release)]
>24 July
>  [Steve (CD), press, Ansgar (ftp), Sebastian (release),
>   Graham (release)]
>31 July
>  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
>7 August
>  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
>14 August
>  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
>
>The first available date is 31 July, so let's shift all my dates another
>week.
>17 July: Hard Freeze & confirmation of the release date
>31 July: ** tentative ** release date

Cool, works for me. Pencilled into my calendar now. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all again,

On 07-06-2021 23:08, Adam D. Barratt wrote:
> On Mon, 2021-06-07 at 20:38 +0200, Paul Gevers wrote:
>> Nevermind 10 July. Steve, you can stop contemplating about it. We'll
>> go for 24 July as the *tentative* release date.
> 
> Unfortunately I've just discovered that I was given the wrong date for
> a family event, so I'm actually going to be AFK for most of the 24th.
> :-(
> 
> Apologies for sticking a slight spanner in the works at this stage.

Those things happen. It's the price we pay for our bus factors (which we
should fix/are fixing).

So, if I did all the booking right (including updates from IRC) we now have:

26 June
  [Ansgar (ftp), Sebastian (release), Adam (release)]
3 July
  [Ansgar (ftp), Paul (release), Adam (release)]
10 July
  [Steve + Andy (CD), Paul (release), Adam (release), Graham (release)]
17 July
  [Steve (CD), press, Ansgar (ftp), Paul (release)]
24 July
  [Steve (CD), press, Ansgar (ftp), Sebastian (release),
   Graham (release)]
31 July
  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
7 August
  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
14 August
  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]

The first available date is 31 July, so let's shift all my dates another
week.
17 July: Hard Freeze & confirmation of the release date
31 July: ** tentative ** release date

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Adam D. Barratt]

On Mon, 2021-06-07 at 20:38 +0200, Paul Gevers wrote:
> Hi all,
> 
> On 06-06-2021 20:03, Paul Gevers wrote:
> > With the availability of Adam now known (and some off-list info),
> > we have:
> > 
[...]
> > So, what to pick? We still believe that shorter freezes are better
> > for
> > the Debian community as a whole, so Steve can you look at turning
> > your
> > maybe on 10 July into a "lets go for this"? If the answer is no,
> > than
> > lets pick 24 July as the *tentative* release date.
> 
> Nevermind 10 July. Steve, you can stop contemplating about it. We'll
> go for 24 July as the *tentative* release date.

Unfortunately I've just discovered that I was given the wrong date for
a family event, so I'm actually going to be AFK for most of the 24th.
:-(

Apologies for sticking a slight spanner in the works at this stage.

Adam

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all,

On 06-06-2021 20:03, Paul Gevers wrote:
> With the availability of Adam now known (and some off-list info), we have:
> 
> 26 June
>   [Ansgar (ftp), Sebastian (release), Adam (release)]
> 3 July
>   [Ansgar (ftp), Paul (release), Adam (release)]
> 10 July
>   [Steve (CD) MAYBE , Ansgar (ftp), Paul (release), Adam (release),
>Graham (release)]
> 17 July
>   [Steve (CD), press, Ansgar (ftp), Paul (release)]
> 24 July
>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release),
>Graham (release)]
> 31 July
>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
> 7 August
>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
> 14 August
>   [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
> 
> So, what to pick? We still believe that shorter freezes are better for
> the Debian community as a whole, so Steve can you look at turning your
> maybe on 10 July into a "lets go for this"? If the answer is no, than
> lets pick 24 July as the *tentative* release date.

Nevermind 10 July. Steve, you can stop contemplating about it. We'll go
for 24 July as the *tentative* release date.

> Regardless of which of the two we pick, I propose we decide two weeks
> before if it's going to be final.

So, we'll decide around 10 July.

> And, relevant for every maintainer of non-key packages without passing
> autopkgtests, the full freeze will start two weeks before the
> *tentative* release. The means that, with traditionally the last week
> being totally frozen, the last week that packages can migrate *all*
> packages need manual unblocks by the release team.

And the Full Freeze will start on 10 July too.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all,

On 04-06-2021 06:49, Paul Gevers wrote:
> 26 June   [Ansgar (ftp)]
> 3 July[Ansgar (ftp), Sebastian (release), Paul (release)]
> 10 July   [Steve (CD) MAYBE , Ansgar (ftp), Paul (release)]
> 17 July   [Steve (CD), press, Ansgar (ftp), Paul (release)]
> 24 July   [Steve (CD), press, Ansgar (ftp), Sebastian (release)]
> 31 July   [Steve (CD), press, Ansgar (ftp), Sebastian (release)]
> 7 August  [Steve (CD), press, Ansgar (ftp), Sebastian (release)]
> 14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)]

With the availability of Adam now known (and some off-list info), we have:

26 June
  [Ansgar (ftp), Sebastian (release), Adam (release)]
3 July
  [Ansgar (ftp), Paul (release), Adam (release)]
10 July
  [Steve (CD) MAYBE , Ansgar (ftp), Paul (release), Adam (release),
   Graham (release)]
17 July
  [Steve (CD), press, Ansgar (ftp), Paul (release)]
24 July
  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release),
   Graham (release)]
31 July
  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
7 August
  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]
14 August
  [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)]

So, what to pick? We still believe that shorter freezes are better for
the Debian community as a whole, so Steve can you look at turning your
maybe on 10 July into a "lets go for this"? If the answer is no, than
lets pick 24 July as the *tentative* release date.

Regardless of which of the two we pick, I propose we decide two weeks
before if it's going to be final.

And, relevant for every maintainer of non-key packages without passing
autopkgtests, the full freeze will start two weeks before the
*tentative* release. The means that, with traditionally the last week
being totally frozen, the last week that packages can migrate *all*
packages need manual unblocks by the release team.

Paul




OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Adam D. Barratt]

On Sun, 2021-05-30 at 09:09 +0200, Paul Gevers wrote:
> 26 June
> 3 July
> 10 July
> 17 July [Steve (CD), press]
> 24 July [Steve (CD), press]
> 31 July
> 7 August
> 14 August

July 17th doesn't work well for me unfortunately*.

The others currently all look OK, although I'd prefer not to do two
releases in a row, so with 10.10 being on the 19th the 26th isn't
great.

Regards,

Adam


* it _could_, but I have a prior appointment around lunchtime on the
Saturday and don't know whether I'd be able to continue after that
(including on Sunday), so it wouldn't be fair to any of us to risk it

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all,

On 30-05-2021 09:09, Paul Gevers wrote:
> 26 June
> 3 July
> 10 July
> 17 July [Steve (CD), press]
> 24 July [Steve (CD), press]
> 31 July
> 7 August
> 14 August

This can now be updated to:

26 June   [Ansgar (ftp)]
3 July[Ansgar (ftp), Sebastian (release), Paul (release)]
10 July   [Steve (CD) MAYBE , Ansgar (ftp), Paul (release)]
17 July   [Steve (CD), press, Ansgar (ftp), Paul (release)]
24 July   [Steve (CD), press, Ansgar (ftp), Sebastian (release)]
31 July   [Steve (CD), press, Ansgar (ftp), Sebastian (release)]
7 August  [Steve (CD), press, Ansgar (ftp), Sebastian (release)]
14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)]

For those following along on IRC, we still have to figure out who from
the release team that has access to the keys can join (if only for the
signing). I hope we can update you on that shortly.

On 30-05-2021 18:48, Steve McIntyre wrote:
> We've been slowly working up to getting other people able to do image
> releases, but I don't think we're *quite* there yet. Maybe on the next
> point release Andy could do it all without me watching and helping,
> but we want to work that out and I'm not sure a new major release is
> the right time to try this!

Again, without wanting to push, as we now have a point release before
any of the mentioned dates, would any of the earlier dates be still a
possibility from CD point of view? Andy, are you available? Donald, did
you look at the earlier days and is press not available, or didn't you
bother because of Steve's availability?

Paul

PS: I'm starting to realize I may feel uncomfortably direct for some
people/cultures. The Dutch are known for it (some call it rude).
Probably because I was raised like that, I don't want to read peoples
mind, I rather hear what they mean.



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Sebastian Ramacher]

On 2021-05-30 09:09:28 +0200, Paul Gevers wrote:
> [Press]
> > Press can do both the 17th and the 24th. Perhaps we add an additional 3
> > dates?
> 
> Yes, let's do that, so the list becomes:
> 
> 26 June
> 3 July
> 10 July
> 17 July [Steve (CD), press]
> 24 July [Steve (CD), press]
> 31 July
> 7 August
> 14 August

I can be around on

3 July
24 July
31 July
7 August
14 august

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Re: Finding a tentative bullseye release date

[Ansgar]

On Sun, 2021-05-30 at 09:09 +0200, Paul Gevers wrote:
> 26 June
> 3 July
> 10 July
> 17 July [Steve (CD), press]
> 24 July [Steve (CD), press]
> 31 July
> 7 August
> 14 August

Currently all of these are fine for me.

Ansgar

Re: Finding a tentative bullseye release date

[Steve McIntyre]

On Sun, May 30, 2021 at 09:09:28AM +0200, Paul Gevers wrote:
>On 30-05-2021 06:35, Donald Norwood wrote:
>> On 5/29/21 9:12 AM, Steve McIntyre wrote:
>>> On Fri, May 28, 2021 at 10:17:55PM +0200, Paul Gevers wrote:
 Assuming all goes well
 with RC2 and RC3, we'd be looking at the following candidate release dates:

 26 June
 3 July
 10 July
 17 July
 24 July

 Can you let us know which date work for you and which don't?
>
>[Steve]
>>> I can do the
>>> 17th and 24th of July just fine.
>
>Asking a question I think most people know the answer to, but CD without
>Steve is no option? Don't get me wrong, I don't want to push otherwise,
>but I just want to understand the options. So much in Debian is based on
>"rituals", it's not always clear what's needed and what is just (nearly)
>always done in a certain way.

We've been slowly working up to getting other people able to do image
releases, but I don't think we're *quite* there yet. Maybe on the next
point release Andy could do it all without me watching and helping,
but we want to work that out and I'm not sure a new major release is
the right time to try this!

Thinking about things some more, the 10th July is more of a "maybe"
than a "no" - I'll be driving home from a vacation that day and
available later in the day. We could possibly fit things in around
that.

>[Press]
>> Press can do both the 17th and the 24th. Perhaps we add an additional 3
>> dates?
>
>Yes, let's do that, so the list becomes:
>
>26 June
>3 July
>10 July
>17 July [Steve (CD), press]
>24 July [Steve (CD), press]
>31 July [Steve (CD)]
>7 August [Steve (CD)]
>14 August [Steve (CD)]

I'm available for the later 3, no problems.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi,

On 30-05-2021 06:35, Donald Norwood wrote:
> On 5/29/21 9:12 AM, Steve McIntyre wrote:
>> On Fri, May 28, 2021 at 10:17:55PM +0200, Paul Gevers wrote:
>>> Assuming all goes well
>>> with RC2 and RC3, we'd be looking at the following candidate release dates:
>>>
>>> 26 June
>>> 3 July
>>> 10 July
>>> 17 July
>>> 24 July
>>>
>>> Can you let us know which date work for you and which don't?

[Steve]
>> I can do the
>> 17th and 24th of July just fine.

Asking a question I think most people know the answer to, but CD without
Steve is no option? Don't get me wrong, I don't want to push otherwise,
but I just want to understand the options. So much in Debian is based on
"rituals", it's not always clear what's needed and what is just (nearly)
always done in a certain way.

[Press]
> Press can do both the 17th and the 24th. Perhaps we add an additional 3
> dates?

Yes, let's do that, so the list becomes:

26 June
3 July
10 July
17 July [Steve (CD), press]
24 July [Steve (CD), press]
31 July
7 August
14 August

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Steve McIntyre]

Hey Paul!

On Fri, May 28, 2021 at 10:17:55PM +0200, Paul Gevers wrote:
>
>On 24-04-2021 00:41, Donald Norwood wrote:
>> Indeed, from this and the last few posts in the discussion it reads that
>> perhaps June is the better option for the 'timed' ready when ready
>> release date.
>
>The progress of fixing the blocking issues in the debian-installer is
>good enough to start thinking again about a tentative bullseye release
>date (see for more details in the quote below). Assuming all goes well
>with RC2 and RC3, we'd be looking at the following candidate release dates:
>
>26 June
>3 July
>10 July
>17 July
>24 July
>
>Can you let us know which date work for you and which don't?

Apologies - I'm unavailable for the first three of those. I can do the
17th and 24th of July just fine.

>> I think it would allow for extra care to be given in the areas needed
>> and would as Paul suggested allow the larger community to pull
>> together to help resolve some of the issues.
>
>The installer team needs everybody's help to test the d-i release
>candidates, to see if the issues that are being solved now are handled
>correctly across as many different machines as possible. If anybody has
>better ideas than the wiki page that kibi suggested in his e-mail below,
>then let us know. Otherwise I'll probably see if I can set up something
>like that shortly.
>
>Paul

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi all,

On 24-04-2021 00:41, Donald Norwood wrote:
> Indeed, from this and the last few posts in the discussion it reads that
> perhaps June is the better option for the 'timed' ready when ready
> release date.

The progress of fixing the blocking issues in the debian-installer is
good enough to start thinking again about a tentative bullseye release
date (see for more details in the quote below). Assuming all goes well
with RC2 and RC3, we'd be looking at the following candidate release dates:

26 June
3 July
10 July
17 July
24 July

Can you let us know which date work for you and which don't?

> I think it would allow for extra care to be given in the areas needed
> and would as Paul suggested allow the larger community to pull
> together to help resolve some of the issues.

The installer team needs everybody's help to test the d-i release
candidates, to see if the issues that are being solved now are handled
correctly across as many different machines as possible. If anybody has
better ideas than the wiki page that kibi suggested in his e-mail below,
then let us know. Otherwise I'll probably see if I can set up something
like that shortly.

Paul

 Forwarded Message 
Date: Fri, 28 May 2021 02:10:14 +0200
From: Cyril Brulebois 

[...]

Right, I think I have a better grasp on where we stand. I haven't dug
into each and every mail from debian-boot@, but it feels like people are
generally happy with the installer in RC1 *provided* they don't run into
the graphical installer hangs or issues at reboot time (due to firmware
stuff).

I have a few other topics that we may want to fix (serial console on
s390x, problems on PowerPC, support for HTTPS, etc.) but that could be
fixed in 11.1 or 11.n…

Hangs in the graphical installer should be under control, even if it
took quite some time and iterations and testing to figure that out for
real. Firmware stuff is the next big item on my list.

I've floated the idea of an RC2 in the next few days so that people
could test the installer without fearing the hangs (and hopefully
without finding new ones) but was waiting on linux to migrate, but some
security issues came up and Salvatore would like to get 5.10.40 into
testing instead, so it might be ready by next week-end (June 5-6)?

I should be able to work on firmware stuff while waiting on the kernel
to be ready. I'm mainly worried about the many hardware setups out there
and having something that works for some machines locally might not be
representative of what users are going to face.

Provided I get a PoC ready in the right timing, and debian-cd people
are available, we might be able to have something like the following:
 - RC2: June 5-6 (fixing hangs in graphical installer in particular)
 - RC3: June 12-13 (firmware PoC)

The RC2 announcement (and maybe some help from publicity team) could be
the right place to let people know we expect problems with firmware, and
ask them to keep an eye on the RC3 that should feature an attempt at
fixing it. Maybe setting up some wikipage where people could register
their hardware and what they experience with the “stock” RC2, and where
they could follow up with their experience with the “patched” RC3. There
might be better tools for that, but I'm more used to pinging a submitter
(or two or three) on a bug report than to collecting info from lots of
people…

If feedback from RC3 is good enough, we might call that RC sufficient to
be the installer for 11.0, and think about a release by the end of June.
We could refine it further still, e.g. by merging translation updates as
what I have in mind would involve presenting users some information,
which would require translation, but that's just a matter of uploading
the right package with new/updated po files (the hard part is getting
the actual translations, but we could think of merging those again in
11.1, 11.2, etc.).

All that is rather optimistic (which I can try to be sometimes…), 
and I
fear we might need to iterate a little, and I'm not sure how quickly
we would get actionable feedback from users… If we were to hit real
difficulties, maybe shift that “end of June” a few weeks, 
and call that
“mid-July”?

[...]





OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date follow up and possible confirmation

[Holger Levsen]

hi,

On Thu, May 06, 2021 at 02:23:07AM +0200, jorkanof...@tutanota.com wrote:
> As stated in a previous email, there was a tentative release date for
> Bullseye scheduled on May 22 2021, as stated in this mailing list post:
> https://lists.debian.org/debian-release/2021/04/msg00552.html. It is
> likely for Debian to be released on May 22 2021, in late May or in
> June 2021 aka end of Q2 2021?

we don't know yet.

> Can you confirm whether the tentative release would be on May 22 or not?

no.

> If not could you propose another day for a proposed release date?

no.
 

-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not the lockdown which is unbearable, but the virus.


signature.asc
Description: PGP signature

Finding a tentative bullseye release date follow up and possible confirmation

[jorkanofaln]

Hello, 

As stated in a previous email, there was a tentative release date for Bullseye 
scheduled on May 22 2021, as stated in this mailing list post: 
https://lists.debian.org/debian-release/2021/04/msg00552.html. It is likely for 
Debian to be released on May 22 2021, in late May or in June 2021 aka end of Q2 
2021? Can you confirm whether the tentative release would be on May 22 or not? 
If not could you propose another day for a proposed release date?

Looking forward to your answers

Regards

Jorkano 

Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)

[Lucas Nussbaum]

On 25/04/21 at 11:04 +0200, Cyril Brulebois wrote:
> > B) In the installer, detect that firmware-amd-graphics or
> > firmware-misc-nonfree should be installed, and either install it (?),
> > or redirect the user to the unofficial installer that includes them.
> 
> That could be achieved for an installer that has non-free enabled,
> provided the proposal by Ben gets implemented, then consumed on the d-i
> side.

For reference, I think Ben's proposal is:
https://lists.debian.org/debian-boot/2021/03/msg00088.html

Lucas

Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)

[Cyril Brulebois]

[ cc+=-x@ ]

Hi Lucas,

Thanks for your summary, I'm not sure about every single detail, but it
seems to be a good basis for discussion. I might point to it from our
errata page (I didn't have a specific bug report when I wrote the most
recent entries):
  https://www.debian.org/devel/debian-installer/errata

Lucas Nussbaum  (2021-04-24):
> Disclaimer: I read the "[AMD/ATI graphics] Missing firmware not declared
> / kernel modules not included in initrd" thread. While my understanding
> of the issue is not complete, I'm trying to summarize what I undertood
> so far in the hope that others can jump in and fill in the blanks or
> correct me.
> 
> 
> There are graphic cards whose in-kernel drivers require non-free
> firmwares. Typically AMD/ATI cards that require firmware-amd-graphics[1]
> to work with the radeon, amdgpu and r128 drivers; or NVIDIA cards that
> require firmware-misc-nonfree to work with the nouveau driver.
> 
> [1] https://packages.debian.org/unstable/firmware-amd-graphics
> 
> 
> With Debian 10, the behaviour was that the installation succeeded
> without installing firmware-* packages, and then, and the first boot, X
> would start in a "degraded" mode (using, for example, the vesa driver).
> The user would generally then install the firmware package (or, in the
> case of NVidia, switch to the proprietary drivers).
> 
> With Debian 11, the installation also succeeds, but then at first boot,
> X fails to work correctly. What happens here is unclear: reports vary
> between "black screen" (but does the system works if the user switches to
> console mode?), "garbled screen", "system crash" (but maybe the user did
> not notice that the system works in console mode).

What I briefly alluded to on IRC (#debian-boot) was something that would
be an A)+B) approach. C) doesn't seem reasonable to me.

> It looks like the three open paths for resolution are:
> 
> A) understand and restore the behaviour from Debian 10, that is, get X
> to work in a degraded mode after installation. How it worked with Debian
> 10 (and why it doesn't with Debian 11) is unknown.

Without checking with X people beforehand, what I imagined we could do
when running an installer that doesn't have non-free enabled could be
adding some X conf snippet to force a generic driver (a while ago, that
would have been fbdev/vesa, not sure about the current state, depending
on whether modesetting kicked in, etc.), to ensure one isn't left with a
black screen. This might involve setting kernel parameters instead or in
addition to that…

It could be accompanied by an information note in the installer (to make
sure the user knows about this degraded mode, and about ways to improve
the situation post-installation) and/or in the installation guide and/or
in the wiki.

https://xorg-team.pages.debian.net/xorg/ doesn't seem like it has had
many updates lately, but it might not be the worst place to have a “how
to undo the snippet things and get the real deal once firmwares are
installed”, or maybe “how to deal with firmwares” in general… that d-i
and the installation guide could point to.

(x.debian.net still exists and redirects there, so that's not a
complicated URL to remember/type if it gets displayed in a note.)

That being said, if an information note gets added in d-i, its content
needs to be checked with the X team, reviewed by the team whose name
has escaped me, and then translated into as many languages as possible.
It could be possible to cheat the translation status to alleviate this
requirement, and contemplate updating the relevant package in 11.1, but
I'm not sure we've ever done that.

On the other hand, docs on x.debian.net aren't translated, so maybe the
installation guide would be a better place in the end…

> B) In the installer, detect that firmware-amd-graphics or
> firmware-misc-nonfree should be installed, and either install it (?),
> or redirect the user to the unofficial installer that includes them.

That could be achieved for an installer that has non-free enabled,
provided the proposal by Ben gets implemented, then consumed on the d-i
side.

> C) Do nothing and document this in the release notes

As said above, I strongly recommend against this.

> The main blocking factor for progress seems to be that not enough
> people have both hardware that is not supported (laptops/desktops with
> AMD or NVidia graphic cards), and the knowledge and time to
> investigate this.

For the avoidance of doubt: I'm fine with working on these topics (and
getting my hands on relevant hardware is in progress), along with other
issues that seem to be potential blockers for the release. I just don't
expect everyone to agree on a (possibly dual) solution immediately, and
the relevant contributions (code, doc, translations) to be available in
the very next few days. Hence my reaction to a very close “tentative
release date” (fewer than 4 weeks).

For completeness, we also have this now:
  https://bugs.debian.org/987441


Cheers,
-- 
Cyril Bruleb

Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)

[Holger Wansing]

Hi,

Lucas Nussbaum  wrote (Sat, 24 Apr 2021 11:30:03 +0200):
> With Debian 10, the behaviour was that the installation succeeded
> without installing firmware-* packages, and then, and the first boot, X
> would start in a "degraded" mode (using, for example, the vesa driver).
> The user would generally then install the firmware package (or, in the
> case of NVidia, switch to the proprietary drivers).
> 
> With Debian 11, the installation also succeeds, but then at first boot,
> X fails to work correctly. What happens here is unclear: reports vary
> between "black screen" (but does the system works if the user switches to
> console mode?), "garbled screen", "system crash" (but maybe the user did
> not notice that the system works in console mode).


Please note that YunQiang Su  has stated in another mail:
For us (mips port), it is a long history of problem.
The problem is that:
the older version of GNOME, or Mate, can work with vesa driver,
while current GNOME cannot.

Without amd/ati non-free firmware, radeon/amdgpu cannot work at all.
So on mips platform with AMDGPU (aka, Loongson-3),
it has nothing on display at all, even console.
The reason is that there are no vesa driver on MIPS.



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)

[Lucas Nussbaum]

On 24/04/21 at 09:25 +0200, Holger Wansing wrote:
> Hi,
> 
> Cyril Brulebois  wrote (Fri, 23 Apr 2021 15:13:15 +0200):
> > D-I Bullseye RC 1 was published a few hours ago. And at the risk of
> > sounding like a broken record: I have *absolutely no guarantee* to
> > have a fix or workaround for the amdgpu issue in less than a month,
> > that would be tested somewhat.
> > 
> > Can we please *not* release with black screens for AMD users?
> 
> Moreover, it's not just an AMD issue.
> We got a confirmation just now on debian-boot, that also NVIDIA users can
> get affected by this:
> https://lists.debian.org/debian-boot/2021/04/msg00225.html
> Some months ago, I have confirmed with that user, that missing firmware
> is indeed the issue there!

Hi,

Disclaimer: I read the "[AMD/ATI graphics] Missing firmware not declared
/ kernel modules not included in initrd" thread. While my understanding
of the issue is not complete, I'm trying to summarize what I undertood
so far in the hope that others can jump in and fill in the blanks or
correct me.


There are graphic cards whose in-kernel drivers require non-free
firmwares. Typically AMD/ATI cards that require firmware-amd-graphics[1]
to work with the radeon, amdgpu and r128 drivers; or NVIDIA cards that
require firmware-misc-nonfree to work with the nouveau driver.

[1] https://packages.debian.org/unstable/firmware-amd-graphics


With Debian 10, the behaviour was that the installation succeeded
without installing firmware-* packages, and then, and the first boot, X
would start in a "degraded" mode (using, for example, the vesa driver).
The user would generally then install the firmware package (or, in the
case of NVidia, switch to the proprietary drivers).

With Debian 11, the installation also succeeds, but then at first boot,
X fails to work correctly. What happens here is unclear: reports vary
between "black screen" (but does the system works if the user switches to
console mode?), "garbled screen", "system crash" (but maybe the user did
not notice that the system works in console mode).


It looks like the three open paths for resolution are:

A) understand and restore the behaviour from Debian 10, that is, get X
to work in a degraded mode after installation. How it worked with Debian
10 (and why it doesn't with Debian 11) is unknown.

B) In the installer, detect that firmware-amd-graphics or
firmware-misc-nonfree should be installed, and either install it (?),
or redirect the user to the unofficial installer that includes them.

C) Do nothing and document this in the release notes

The main blocking factor for progress seems to be that not enough people
have both hardware that is not supported (laptops/desktops with AMD or
NVidia graphic cards), and the knowledge and time to investigate this.

Lucas

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Fri, 23 Apr 2021 15:13:15 +0200):
> D-I Bullseye RC 1 was published a few hours ago. And at the risk of
> sounding like a broken record: I have *absolutely no guarantee* to
> have a fix or workaround for the amdgpu issue in less than a month,
> that would be tested somewhat.
> 
> Can we please *not* release with black screens for AMD users?

Moreover, it's not just an AMD issue.
We got a confirmation just now on debian-boot, that also NVIDIA users can
get affected by this:
https://lists.debian.org/debian-boot/2021/04/msg00225.html
Some months ago, I have confirmed with that user, that missing firmware
is indeed the issue there!


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Finding a tentative bullseye release date

[Donald Norwood]

On 4/23/21 5:00 PM, Jonathan Carter wrote:

> 
> I'm trusting the release team to block until d-i is ready, from what I
> understand the date that they're trying to find in May is just a
> tentative date. Would it also make sense to keep another tentative date
> for June as a back-up? (I'm thinking that it might make it easier to
> plan now than to scramble again in May, but if you feel different then
> that's fine too).

Indeed, from this and the last few posts in the discussion it reads that
perhaps June is the better option for the 'timed' ready when ready
release date.

I think it would allow for extra care to be given in the areas needed
and would as Paul suggested allow the larger community to pull together
to help resolve some of the issues.

I'd suggest to strike the May 1, 8, and 15th dates and move to:

May 22
May 29
Jun 05
Jun 12
Jun 19

Separately, if there is an area where a non-programmer-coder (NPC, haha)
can assist perhaps with a set of steps that I can reproduce on my
equipment here, please point me to it and I'll chip in.


Be well,

-Donald



-- 
--
-
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05

Re: Finding a tentative bullseye release date

[Jonathan Carter]

Hi Cyril

On 2021/04/23 22:30, Cyril Brulebois wrote:
> No, I don't have any amdgpu hardware at the moment; but yes, I have
> leader@'s checklist handy for when I can allocate some time to plan for
> this.

I suggest getting a standalone card and laptop (there are some really
cheap ones with amd GPUs available) as soon as you have a chance and get
reimbursement for it.

I'm trusting the release team to block until d-i is ready, from what I
understand the date that they're trying to find in May is just a
tentative date. Would it also make sense to keep another tentative date
for June as a back-up? (I'm thinking that it might make it easier to
plan now than to scramble again in May, but if you feel different then
that's fine too).

-Jonathan

Re: Finding a tentative bullseye release date

[Cyril Brulebois]

Hi Paul,

Paul Gevers  (2021-04-23):
> I hear you. So, I fear that we're getting into a situation where
> everything except the installer is more or less ready for the bullseye
> release. (Well assuming the shim is signed any time soon).
> 
> > D-I Bullseye RC 1 was published a few hours ago. And at the risk of
> > sounding like a broken record: I have *absolutely no guarantee* to
> > have a fix or workaround for the amdgpu issue in less than a month,
> > that would be tested somewhat.
> > 
> > Can we please *not* release with black screens for AMD users?
> 
> Indeed, let's not. But can't we get the full Debian community on board
> to search for good solution? I have the feeling there's much interest
> to release sooner rather than late, so maybe there's brains we can use
> to help the installer forward? I'm going to draft a bits shortly, is
> there a bug number or mail thread we can point at?

I've just put out a new release, and I've tried to assemble stuff into
errata, can I *please* just have some time to look at our bugs, triage
them, and see what needs be fixed before the bullseye is out?!

amdgpu is the biggest issue I could think of, for this thread, and for
errata, but we have other showstoppers apparently. We need *time* to
stabilize the installer. What really worked last times was iterating
over as many releases as needed.

I tried to convey this earlier, but seemed to have failed, so I'll just
repeat myself: Over the last few release cycles, we've had a *predictable*
timing, with no sense of urgency and due date, and I've felt trusted to
do the right thing all the way.

It's been a few weeks since I've started to feel like this is getting
taken away from me. That's not a particular joyful experience, and
that's also a pretty huge motivation killer.

> Also, I recognize that the debian-installer is largely handled by you
> alone. I estimate that it's not going to help you on the short term if
> people volunteer to help with the coding as you would be spending time
> on on-boarding them. So, how can we, the Debian Community, help you
> getting the installer in releasable shape?

I'd advise releasing the time pressure, but it seems my pleading for
exactly that over the last few weeks/months hasn't achieved anything.

> I can think of testing RC1, but what else? Do you have the right
> hardware available for the amdgpu issue? Can people try out solutions
> for you? Tell us, or tell us how to find out.

No, I don't have any amdgpu hardware at the moment; but yes, I have
leader@'s checklist handy for when I can allocate some time to plan for
this.

> That said, I still think it's good to keep May 22 in the agenda as an
> option to do the release, with the remark that we'll not release when
> we're not ready (as Debian always does).

Getting mixed signals after the initial “I hear you”…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi Cyril,

On 23-04-2021 15:13, Cyril Brulebois wrote:
>> Seems like our current best option is May 22 if you can make it.
> 
> That's definitely not what I would call “best option” from an
> installer point of view.

I hear you. So, I fear that we're getting into a situation where
everything except the installer is more or less ready for the bullseye
release. (Well assuming the shim is signed any time soon).

> D-I Bullseye RC 1 was published a few hours ago. And at the risk of
> sounding like a broken record: I have *absolutely no guarantee* to
> have a fix or workaround for the amdgpu issue in less than a month,
> that would be tested somewhat.
> 
> Can we please *not* release with black screens for AMD users?

Indeed, let's not. But can't we get the full Debian community on board
to search for good solution? I have the feeling there's much interest to
release sooner rather than late, so maybe there's brains we can use to
help the installer forward? I'm going to draft a bits shortly, is there
a bug number or mail thread we can point at?

Also, I recognize that the debian-installer is largely handled by you
alone. I estimate that it's not going to help you on the short term if
people volunteer to help with the coding as you would be spending time
on on-boarding them. So, how can we, the Debian Community, help you
getting the installer in releasable shape? I can think of testing RC1,
but what else? Do you have the right hardware available for the amdgpu
issue? Can people try out solutions for you? Tell us, or tell us how to
find out.

That said, I still think it's good to keep May 22 in the agenda as an
option to do the release, with the remark that we'll not release when
we're not ready (as Debian always does).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Cyril Brulebois]

Hi,

Paul Gevers  (2021-04-21):
> > We propose to aim for a release date in May. Would either of the
> > following work for you and do you have any preference?
> > - May  1
> > - May  8
> > - May 15
> > - May 22
> > - May 29
> 
> I've seen replies from Steve for CD, from Donald for Press and Cyril
> for d-i. Can you please let us know if/when you're available?
> May  1 CD, Press
> May  8 CD, Press
> May 15 CD
> May 22 CD, Press
> May 29 (CD)
> 
> [d-i: the later the better]

My answer wasn't quite meant to state “May is fine”…

> Seems like our current best option is May 22 if you can make it.

That's definitely not what I would call “best option” from an
installer point of view.

D-I Bullseye RC 1 was published a few hours ago. And at the risk of
sounding like a broken record: I have *absolutely no guarantee* to
have a fix or workaround for the amdgpu issue in less than a month,
that would be tested somewhat.

Can we please *not* release with black screens for AMD users?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Finding a tentative bullseye release date

[Mark Hymers]

On Wed, 21, Apr, 2021 at 09:19:17PM +0200, Paul Gevers spoke thus..
> I've seen replies from Steve for CD, from Donald for Press and Cyril for
> d-i. Can you please let us know if/when you're available?
> May  1 CD, Press
> May  8 CD, Press
> May 15 CD
> May 22 CD, Press
> May 29 (CD)
> 
> [d-i: the later the better]
> 
> Seems like our current best option is May 22 if you can make it.

I can help out with ftp-master foo on any of those.

Mark


-- 
Mark Hymers 


signature.asc
Description: PGP signature

Re: Finding a tentative bullseye release date

[Adam D. Barratt]

[I'm quite behind on list mail in general, and tend to use the BTS for
tracking / processing SRM work. Direct mail often works better than
waiting for me to notice list mail]

On Wed, 2021-04-21 at 21:19 +0200, Paul Gevers wrote:
> I've seen replies from Steve for CD, from Donald for Press and Cyril
> for d-i. Can you please let us know if/when you're available?
> May  1 CD, Press
> May  8 CD, Press
> May 15 CD
> May 22 CD, Press
> May 29 (CD)
> 
> [d-i: the later the better]
> 
> Seems like our current best option is May 22 if you can make it.

I'm likely to be away for the long weekend at the end of the May (29-
31) and can't guarantee my availability or access to useful
connectivity then. The other dates should currently work for me.

Regards,

Adam

Re: Finding a tentative bullseye release date

[Ansgar]

にゃあ！

On Wed, 2021-04-21 at 21:19 +0200, Paul Gevers wrote:
> Can you please let us know if/when you're available?
> May  1 CD, Press
> May  8 CD, Press
> May 15 CD
> May 22 CD, Press
> May 29 (CD)

All should be fine for me.  It's not like one can do much other
interesting things currently.

Ansgar

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi ftpmasters, Adam,

On 09-04-2021 20:47, Paul Gevers wrote:
> Dear release team, ftpmasters, press team, cd team, d-i team,

[...]

> We propose to aim for a release date in May. Would either of the
> following work for you and do you have any preference?
> - May  1
> - May  8
> - May 15
> - May 22
> - May 29

I've seen replies from Steve for CD, from Donald for Press and Cyril for
d-i. Can you please let us know if/when you're available?
May  1 CD, Press
May  8 CD, Press
May 15 CD
May 22 CD, Press
May 29 (CD)

[d-i: the later the better]

Seems like our current best option is May 22 if you can make it.

Paul







OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Holger Wansing  wrote (Thu, 15 Apr 2021 23:07:43 +0200):
> Hi,
> 
> Holger Wansing  wrote (Thu, 15 Apr 2021 19:38:34 +0200):
> > > Ideally of course, you'd be able to test in unstable that
> > > the solution actually works before we accept them in testing. Is that
> > > feasible?
> > 
> > Hmm, the installer installs tasksel from testing by default AFAIK, so that 
> > would  need some special tweaking to allow for such tests ...
> > I will need to look into this.
> 
> I found how to do such test, so let's do it like that:
> upload to unstable, and then I will do some tests.
> After that, I will file an unblock request.

The changings (included in 3.66 and 3.67) work fine!

I just filed an unblock request.


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Holger Wansing  wrote (Thu, 15 Apr 2021 19:38:34 +0200):
> > Ideally of course, you'd be able to test in unstable that
> > the solution actually works before we accept them in testing. Is that
> > feasible?
> 
> Hmm, the installer installs tasksel from testing by default AFAIK, so that 
> would  need some special tweaking to allow for such tests ...
> I will need to look into this.

I found how to do such test, so let's do it like that:
upload to unstable, and then I will do some tests.
After that, I will file an unblock request.

Thanks again
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Paul Gevers  wrote (Thu, 15 Apr 2021 09:55:34 +0200):
> Hi Holger,
> 
> On 10-04-2021 18:14, Holger Wansing wrote:
> >>> 2. A problem came up during freeze regarding input methods for several 
> >>>languages:
> >>>Starting with bullseye, GNOME depends on ibus, which is not fully
> >>>compatible with the view of some language teams, who would like to
> >>>prefer fcitx. 
> >>>The best way to get this situation fixed would require some new
> >>>binary packages to be added to Bullseye (would only be tasks packages,
> >>>so no new code/functions to be added!).
> >>>A thread regarding this started at
> >>>   https://lists.debian.org/debian-boot/2021/03/msg00058.html
> >>>and the release-team was also added to the loop at some point.
> >>>Maybe release-team could look into this too, and try to make a 
> >>>decision?
> >>
> >> Did you conclude in that thread what the optimal option would be from
> >> your side? And what's the preferred option without new packages?
> > 
> > That's not just my opinion, but sort of consensus of the involved people.
> > Going through the above mentioned thread shows that.
> > There are also alternatives mentioned, but they all have their 
> > disadvantages,
> > that's why the consensus.
> 
> We had a bit of discussion on this and if you think with these addition
> (meta) packages we can fix this problem, let's have them. Please prepare
> and upload. We'll notify ftp-masters that this upload to NEW is meant
> for bullseye. 

That's great. Thanks!

> Ideally of course, you'd be able to test in unstable that
> the solution actually works before we accept them in testing. Is that
> feasible?

Hmm, the installer installs tasksel from testing by default AFAIK, so that 
would  need some special tweaking to allow for such tests ...
I will need to look into this.

> 
> Side note, on our check list [1], there's also a note on asking you if
> the install guide is up-to-date. Can you confirm that?

Yes, the version currently in Bullseye was meant for the release, and it
should be fine for it!


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi Holger,

On 10-04-2021 18:14, Holger Wansing wrote:
>>> 2. A problem came up during freeze regarding input methods for several 
>>>languages:
>>>Starting with bullseye, GNOME depends on ibus, which is not fully
>>>compatible with the view of some language teams, who would like to
>>>prefer fcitx. 
>>>The best way to get this situation fixed would require some new
>>>binary packages to be added to Bullseye (would only be tasks packages,
>>>so no new code/functions to be added!).
>>>A thread regarding this started at
>>> https://lists.debian.org/debian-boot/2021/03/msg00058.html
>>>and the release-team was also added to the loop at some point.
>>>Maybe release-team could look into this too, and try to make a 
>>>decision?
>>
>> Did you conclude in that thread what the optimal option would be from
>> your side? And what's the preferred option without new packages?
> 
> That's not just my opinion, but sort of consensus of the involved people.
> Going through the above mentioned thread shows that.
> There are also alternatives mentioned, but they all have their disadvantages,
> that's why the consensus.

We had a bit of discussion on this and if you think with these addition
(meta) packages we can fix this problem, let's have them. Please prepare
and upload. We'll notify ftp-masters that this upload to NEW is meant
for bullseye. Ideally of course, you'd be able to test in unstable that
the solution actually works before we accept them in testing. Is that
feasible?

Side note, on our check list [1], there's also a note on asking you if
the install guide is up-to-date. Can you confirm that?

Paul

[1]
https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BullseyeCheckList



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 10 Apr 2021 18:14:36 +0200):
> That's not just my opinion, but sort of consensus of the involved people.
> Going through the above mentioned thread shows that.
> There are also alternatives mentioned, but they all have their disadvantages,
> that's why the consensus.

May I submit a patch for this? (attached)


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index c1598e53..257aaf1e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,36 +1,46 @@
 tasksel (3.66) UNRELEASED; urgency=medium
 
   [ Shengjing Zhu ]
   * Switch to fcitx5 for Simplified and Traditional Chinese desktop.
 Fcitx5 works for Wayland. (Closes: #983704)
 
+  [ Holger Wansing]
+  * GNOME now depends on ibus. For some languages, there are additional
+packages needed, to make ibus work. Adding them for Amharic, Simplified
+chinese, Traditional chinese, Japanese, Kannada, Malayalam and Telugu.
+This requites new task-*-gnome-desktop packages to be added for Amharic,
+Simplified chinese, Traditional chinese, and Kannada.
+Thanks to Shengjing Zhu for working out the circumstances.
+  * ibus does not have default configurations for all languages, so force
+to create one via gnome-initial-setup for all the languages using ibus.
+
  -- Holger Wansing   Sat, 20 Mar 2021 16:22:17 +0800
 
 tasksel (3.65) unstable; urgency=medium
 
   * Team upload.
 
   [ HIGUCHI Daisuke ]
   * tasksel-japanese-desktop: prefer uim-mozc over uim-anthy (Closes: #982175)
 
   [ Holger Wansing ]
   * Re-add manpages-it to task-italian task (package is again available in
 unstable/testing). Closes: #982043.
   * Add manpages translations from newly introduced manpages-l10n package
 (manpages-pt-br, manpages-nl, manpages-mk, manpages-ro, manpages-es)
 to the respective language tasks (see #982043).
   * Re-add synaptic to gnome desktop tasks. Closes: #983074
   * Remove scim-qt-immodule from task-chinese-t-kde-desktop, since it's no
 longer in the archive.
 
   [ YOSHINO Yoshihito ]
   * Let gnome-flashback-desktop task in Japanese pull
 task-japanese-gnome-desktop. Closes: #983688
 
  -- Holger Wansing   Sat, 13 Mar 2021 16:26:46 +0100
 
 tasksel (3.64) unstable; urgency=medium
 
   * Team upload.
 
   [ Holger Wansing ]
diff --git a/debian/control b/debian/control
index 30feb782..b4f39cd8 100644
--- a/debian/control
+++ b/debian/control
@@ -412,60 +412,70 @@ Architecture: all
 Description: Albanian desktop
  This task localises the desktop in Albanian.
 Depends: ${misc:Depends},
 Recommends:
 	firefox-esr-l10n-sq | firefox-l10n-sq,
 	myspell-sq,
 
 Package: task-amharic
 Architecture: all
 Description: Amharic environment
  This task installs programs, data files, fonts, and
  documentation that makes it easier for Amharic speakers
  to use Debian.
 Depends: ${misc:Depends},
 Recommends:
 	aspell-am
 
 Package: task-amharic-desktop
 Architecture: all
 Description: Amharic desktop
  This task localises the desktop in Amharic.
 Depends: ${misc:Depends}
 Recommends:
 	fonts-sil-abyssinica,
 	fcitx,
 	fcitx-table-amharic,
 	fcitx-frontend-gtk2,
 	fcitx-frontend-gtk3,
 	fcitx-config-gtk
 
+Package: task-amharic-gnome-desktop
+Architecture: all
+Description: Amharic GNOME desktop
+ This task localises the GNOME desktop in Amharic.
+Depends: ${misc:Depends}
+Recommends:
+	ibus-m17n,
+# ibus doesn't have a default config for all languages, so force creation
+	gnome-initial-setup
+
 Package: task-amharic-kde-desktop
 Architecture: all
 Description: Amharic KDE Plasma desktop
  This task localises the KDE Plasma desktop in Amharic.
 Depends: ${misc:Depends},
 Recommends:
 	fcitx-frontend-qt5,
 	kde-config-fcitx
 
 Package: task-arabic
 Architecture: all
 Description: Arabic environment
  This task installs programs, data files, fonts, and
  documentation that makes it easier for Arabic speakers
  to use Debian.
 Depends: ${misc:Depends},
 Recommends:
 	fonts-arabeyes,
 	aspell-ar,
 	aspell-ar-large,
 	itools
 
 Package: task-arabic-desktop
 Architecture: all
 Description: Arabic desktop
  This task localises the desktop in Arabic.
 Depends: ${misc:Depends},
 Recommends:
 	fonts-kacst,
 	fonts-farsiweb,
@@ -724,103 +734,123 @@ Recommends:
 	opencc,
 	zhcon,
 	manpages-zh,
 
 Package: task-chinese-s-desktop
 Architecture: all
 Description: Simplified Chinese desktop
  This task localises the desktop in Simplified Chinese.
 Depends: ${misc:Depends},
 Recommends:
 # Input method stuff
 	im-config,
 	fcitx5,
 	fcitx5-chinese-addons,
 # Fonts
 	fonts-noto,
 	fonts-noto-cjk,
 # Software help and localization
 	libreoffice-l10n-zh-cn,
 	libreoffice-help-zh-cn,
 	firefox-esr-l10n-zh-cn | firefox-l10n-zh-cn,
 # Dictionary
 	goldendict,
 # poppler-data is needed to display
 # Chinese on poppler applications.
 	poppler-data
 Suggests:
 	fonts-arphic-ukai,
 	fonts-arphic-uming
 
+Package: task-chinese-s-gnome

Re: Finding a tentative bullseye release date

[Holger Wansing]

Am 10. April 2021 20:32:50 MESZ schrieb Ivo De Decker :
>I went trough the list and unblocked all the translation updates. Let us 
>know if I missed anything.

Looks good, many thanks.

Holger


Hi,
-- 
Sent from /e/ OS on Fairphone3

Re: Finding a tentative bullseye release date

[Ivo De Decker]

Hi Holger,

On 4/10/21 5:58 PM, Holger Wansing wrote:


  1. https://d-i.debian.org/testing-summary.html



It's of course additional work to file the unblock bugreports, but I would
do that, if there are no objections.


I went trough the list and unblocked all the translation updates. Let us 
know if I missed anything.


Cheers,

Ivo

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Paul Gevers  wrote (Sat, 10 Apr 2021 16:45:52 +0200):
> Hi Holger,
> 
> On 10-04-2021 12:59, Holger Wansing wrote:
> > Maybe the release-team could look into the pending unblock issues for d-i
> > in the meantime?
> 
> Were unblock requests filed? If so, can you point me at them as I don't
> know which unblock requests you're talking about? If not, they don't
> appear magically on our radar, the best course of action is to file
> unblock reports (with the right meta info, so please use reportbug) for
> packages that need to migrate but are blocked.

No, such bugreports have not been filed yet.
Usually, so was no need to do so, since kibi cared about that directly as a 
member of the release team (as also explained by kibi in his mail).

If it is wanted to get this done by other release team members, I can of course
file the needed reports.

> > Most of them should be quite unproblematic, since they only contain 
> > translation
> > updates.
> > 
> > A bit more of an issue would be tasksel.
> > 1. Currently there is 3.65 in sid, which needs to migrate to bullseye.
> 
> This one was missing an unblock request. I have just unblocked it.

Thanks!

> > 2. A problem came up during freeze regarding input methods for several 
> >languages:
> >Starting with bullseye, GNOME depends on ibus, which is not fully
> >compatible with the view of some language teams, who would like to
> >prefer fcitx. 
> >The best way to get this situation fixed would require some new
> >binary packages to be added to Bullseye (would only be tasks packages,
> >so no new code/functions to be added!).
> >A thread regarding this started at
> > https://lists.debian.org/debian-boot/2021/03/msg00058.html
> >and the release-team was also added to the loop at some point.
> >Maybe release-team could look into this too, and try to make a 
> >decision?
> 
> Did you conclude in that thread what the optimal option would be from
> your side? And what's the preferred option without new packages?

That's not just my opinion, but sort of consensus of the involved people.
Going through the above mentioned thread shows that.
There are also alternatives mentioned, but they all have their disadvantages,
that's why the consensus.

What's the preferred option without new packages?
I guess in the current state of the freeze that would be "Leaving all as is
and write a note in the release-notes, so users are aware of the situation and
of the need to manually fix things themselves."


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Sat, 10 Apr 2021 17:07:54 +0200):
> Paul Gevers  (2021-04-10):
> > On 10-04-2021 12:59, Holger Wansing wrote:
> > > Maybe the release-team could look into the pending unblock issues
> > > for d-i in the meantime?
> > 
> > Were unblock requests filed? If so, can you point me at them as I
> > don't know which unblock requests you're talking about? If not, they
> > don't appear magically on our radar, the best course of action is to
> > file unblock reports (with the right meta info, so please use
> > reportbug) for packages that need to migrate but are blocked.
> 
> That looks like busy-work for both debian-boot and debian-release…
> 
> Walking through [1] and unblocking things that make sense (l10n-only
> and/or stuff we want in the release) is what I usually do. This will
> happen before RC1 anyway.
> 
>  1. https://d-i.debian.org/testing-summary.html

@kibi: I know you are acting like stated above, and I assumed you will do
so this time too. 
However, my idea was - and I think I made that clear in my previous mail -
to get that work done by others, so you would not need to take care of that
anymore, when you find the time to work on d-i.

It's of course additional work to file the unblock bugreports, but I would
do that, if there are no objections.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Finding a tentative bullseye release date

[Jacek Krysztofik]

Hi,

sob., 10 kwi 2021 o 13:18 Holger Wansing  napisał(a):

> Hi,
>
> Cyril Brulebois  wrote (Sat, 10 Apr 2021 11:54:59 +0200):
> > Hi,
> >
> > Paul Gevers  (2021-04-09):
> > > The Release Team believes that the state of bullseye is pretty good.
> > > Yes, there are some blocking bugs [1] and d-i and shim still need some
> > > love, but the state is much better than we remembered from the same
> > > time in buster.
> >
> > As already explained, trying to release in April/May wasn't quite
> > anticipated, and there's still ground to cover on the d-i side.
>
> Trying to minimize the work load for kibi:
> @kibi: (given there are no objections against this from you?):
>
> Maybe the release-team could look into the pending unblock issues for d-i
> in the meantime?
> Most of them should be quite unproblematic, since they only contain
> translation
> updates.
>
> A bit more of an issue would be tasksel.
> 1. Currently there is 3.65 in sid, which needs to migrate to bullseye.
> 2. A problem came up during freeze regarding input methods for several
>languages:
>Starting with bullseye, GNOME depends on ibus, which is not fully
>compatible with the view of some language teams, who would like to
>prefer fcitx.
>The best way to get this situation fixed would require some new
>binary packages to be added to Bullseye (would only be tasks packages,
>so no new code/functions to be added!).
>A thread regarding this started at
> https://lists.debian.org/debian-boot/2021/03/msg00058.html
>and the release-team was also added to the loop at some point.
>Maybe release-team could look into this too, and try to make a
>decision?
>
>
> Holger
>
> "When does the new Debian release come out?"
"When it's ready."

Re: Finding a tentative bullseye release date

[Cyril Brulebois]

Paul Gevers  (2021-04-10):
> On 10-04-2021 12:59, Holger Wansing wrote:
> > Maybe the release-team could look into the pending unblock issues
> > for d-i in the meantime?
> 
> Were unblock requests filed? If so, can you point me at them as I
> don't know which unblock requests you're talking about? If not, they
> don't appear magically on our radar, the best course of action is to
> file unblock reports (with the right meta info, so please use
> reportbug) for packages that need to migrate but are blocked.

That looks like busy-work for both debian-boot and debian-release…

Walking through [1] and unblocking things that make sense (l10n-only
and/or stuff we want in the release) is what I usually do. This will
happen before RC1 anyway.

 1. https://d-i.debian.org/testing-summary.html


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Finding a tentative bullseye release date

[Paul Gevers]

Hi Holger,

On 10-04-2021 12:59, Holger Wansing wrote:
> Maybe the release-team could look into the pending unblock issues for d-i
> in the meantime?

Were unblock requests filed? If so, can you point me at them as I don't
know which unblock requests you're talking about? If not, they don't
appear magically on our radar, the best course of action is to file
unblock reports (with the right meta info, so please use reportbug) for
packages that need to migrate but are blocked.

> Most of them should be quite unproblematic, since they only contain 
> translation
> updates.
> 
> A bit more of an issue would be tasksel.
> 1. Currently there is 3.65 in sid, which needs to migrate to bullseye.

This one was missing an unblock request. I have just unblocked it.

> 2. A problem came up during freeze regarding input methods for several 
>languages:
>Starting with bullseye, GNOME depends on ibus, which is not fully
>compatible with the view of some language teams, who would like to
>prefer fcitx. 
>The best way to get this situation fixed would require some new
>binary packages to be added to Bullseye (would only be tasks packages,
>so no new code/functions to be added!).
>A thread regarding this started at
>   https://lists.debian.org/debian-boot/2021/03/msg00058.html
>and the release-team was also added to the loop at some point.
>Maybe release-team could look into this too, and try to make a 
>decision?

Did you conclude in that thread what the optimal option would be from
your side? And what's the preferred option without new packages?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Sat, 10 Apr 2021 11:54:59 +0200):
> Hi,
> 
> Paul Gevers  (2021-04-09):
> > The Release Team believes that the state of bullseye is pretty good.
> > Yes, there are some blocking bugs [1] and d-i and shim still need some
> > love, but the state is much better than we remembered from the same
> > time in buster.
> 
> As already explained, trying to release in April/May wasn't quite
> anticipated, and there's still ground to cover on the d-i side.

Trying to minimize the work load for kibi:
@kibi: (given there are no objections against this from you?):

Maybe the release-team could look into the pending unblock issues for d-i
in the meantime?
Most of them should be quite unproblematic, since they only contain translation
updates.

A bit more of an issue would be tasksel.
1. Currently there is 3.65 in sid, which needs to migrate to bullseye.
2. A problem came up during freeze regarding input methods for several 
   languages:
   Starting with bullseye, GNOME depends on ibus, which is not fully
   compatible with the view of some language teams, who would like to
   prefer fcitx. 
   The best way to get this situation fixed would require some new
   binary packages to be added to Bullseye (would only be tasks packages,
   so no new code/functions to be added!).
   A thread regarding this started at
https://lists.debian.org/debian-boot/2021/03/msg00058.html
   and the release-team was also added to the loop at some point.
   Maybe release-team could look into this too, and try to make a 
   decision?


Holger





-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Finding a tentative bullseye release date

[Cyril Brulebois]

Hi,

Paul Gevers  (2021-04-09):
> The Release Team believes that the state of bullseye is pretty good.
> Yes, there are some blocking bugs [1] and d-i and shim still need some
> love, but the state is much better than we remembered from the same
> time in buster.

As already explained, trying to release in April/May wasn't quite
anticipated, and there's still ground to cover on the d-i side.

> Last time in the buster release cycle, it took quite a while to pick a
> release date once it was clear that buster could get released. As we
> believe that shorter freeze period are better for the spirit of
> contributors to Debian, we'd like to avoid such an unnecessary delay
> again, and we'd want to pick a tentative release date. We call it
> tentative, because it would be the date where we do the bullseye
> release assuming that the identified issues are resolved by then and
> that we don't find new blocking issues between now and two weeks
> before that proposed date. So, the date would not be the set-in-stone
> release date, but obviously it would become more solid as we get near
> it.
> 
> We propose to aim for a release date in May. Would either of the
> following work for you and do you have any preference?
> - May  1
> - May  8
> - May 15
> - May 22
> - May 29

As it stands, the later the better.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Finding a tentative bullseye release date

[Donald Norwood]

Hello, everyone


On 4/9/21 2:47 PM, Paul Gevers wrote:
> Dear release team, ftpmasters, press team, cd team, d-i team,
> 
> The Release Team believes that the state of bullseye is pretty good.
> Yes, there are some blocking bugs [1] and d-i and shim still need some
> love, but the state is much better than we remembered from the same time
> in buster.
> 

Great job all around, very exciting.

> Last time in the buster release cycle, it took quite a while to pick a
> release date once it was clear that buster could get released. As we
> believe that shorter freeze period are better for the spirit of
> contributors to Debian, we'd like to avoid such an unnecessary delay
> again, and we'd want to pick a tentative release date. We call it
> tentative, because it would be the date where we do the bullseye release
> assuming that the identified issues are resolved by then and that we
> don't find new blocking issues between now and two weeks before that
> proposed date. So, the date would not be the set-in-stone release date,
> but obviously it would become more solid as we get near it.
> 
> We propose to aim for a release date in May. Would either of the
> following work for you and do you have any preference?
> - May  1
> - May  8
> - May 15
> - May 22
> - May 29

Press can do May 1, 8, or  22.

Looking forward already!

-Donald

-- 
--
-
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05



OpenPGP_signature
Description: OpenPGP digital signature

Re: Finding a tentative bullseye release date

[Steve McIntyre]

Hey Paul and others!

On Fri, Apr 09, 2021 at 08:47:21PM +0200, Paul Gevers wrote:
>Dear release team, ftpmasters, press team, cd team, d-i team,
>
>The Release Team believes that the state of bullseye is pretty good.
>Yes, there are some blocking bugs [1] and d-i and shim still need some
>love, but the state is much better than we remembered from the same time
>in buster.
>
>Last time in the buster release cycle, it took quite a while to pick a
>release date once it was clear that buster could get released. As we
>believe that shorter freeze period are better for the spirit of
>contributors to Debian, we'd like to avoid such an unnecessary delay
>again, and we'd want to pick a tentative release date. We call it
>tentative, because it would be the date where we do the bullseye release
>assuming that the identified issues are resolved by then and that we
>don't find new blocking issues between now and two weeks before that
>proposed date. So, the date would not be the set-in-stone release date,
>but obviously it would become more solid as we get near it.
>
>We propose to aim for a release date in May. Would either of the
>following work for you and do you have any preference?
>- May  1
>- May  8
>- May 15
>- May 22
>- May 29

So far I'm available for all of those weekends, but for selfish
reasons I'd prefer not to be busy on the weekend of the 29th.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Finding a tentative bullseye release date

[Paul Gevers]

Dear release team, ftpmasters, press team, cd team, d-i team,

The Release Team believes that the state of bullseye is pretty good.
Yes, there are some blocking bugs [1] and d-i and shim still need some
love, but the state is much better than we remembered from the same time
in buster.

Last time in the buster release cycle, it took quite a while to pick a
release date once it was clear that buster could get released. As we
believe that shorter freeze period are better for the spirit of
contributors to Debian, we'd like to avoid such an unnecessary delay
again, and we'd want to pick a tentative release date. We call it
tentative, because it would be the date where we do the bullseye release
assuming that the identified issues are resolved by then and that we
don't find new blocking issues between now and two weeks before that
proposed date. So, the date would not be the set-in-stone release date,
but obviously it would become more solid as we get near it.

We propose to aim for a release date in May. Would either of the
following work for you and do you have any preference?
- May  1
- May  8
- May 15
- May 22
- May 29

Paul

[1]
https://udd.debian.org/dev/bugs.cgi?merged=ign&rc=1&format=html&release=bullseye_and_sid&done=ign&deferred=ign&rtbullseye-is-blocker=only&cpopcon=1&chints=1&ckeypackage=1&ctags=1&cdeferred=1&caffected=1&cmissingbuilds=1&clastupload=1&crttags=1&cautormtime=1&cwhykey=1&cbritney=1&sortby=last_modified&sorto=asc&#results









OpenPGP_signature
Description: OpenPGP digital signature