[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Finding a tentative bullseye release date



Hi,

Paul Gevers <elbrus@debian.org> 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 <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


Reply to: