Re: Debian installer and CD BoF: my views for jessie
Hi,
Just a question: can we provide d-i update asynchronously with
release? It means, should we put all thing with Jessie and
postpone delayed items until Jessie+1? Is there any way to provide
nice features without stable release? Does "Regular releases" mean
"until Jessie release" or "every 2/3 weeks/months"?
On Mon, 25 Aug 2014 05:55:08 +0200
Cyril Brulebois <kibi@debian.org> wrote:
> Hi,
>
> since Steve asked me whether I had some stuff to share for the upcoming
> Debian installer and CD BoF at DebConf, here are a few things dug from
> my d-i todo list (without any kind of prioritization). In brackets, the
> status/impact for jessie.
>
> Since it's almost 6am locally, I hope you won't hate me for the missing
> references to bug reports / mailing list posts for most entries.
>
> * Fix missing firmware support: I've contacted Ben about that topic and
> should be able to handle that by myself over the next few days/weeks,
> depending on how work and related meetings turn out for me.
> [ Needed ]
>
> * Graphical install by default (amd64/i386): I think nobody NACKed this
> move (quite the contrary), but that means a major overhaul of boot
> menus for some images (especially the multi-arch netinst one), which
> is being discussed. Didier proposed using some syslinux features to
> make new menus as great as possible. (Mostly: fewer, to-the-point
> entries.)
> [ Wanted ]
>
> * Switch cdebconf gtk frontend to gtk3: Over the last few months the
> gtk3 udeb situation got much better (they're installable now, last I
> checked). I had a proof of concept (and a git branch) ready a while
> ago, but it seems late to work on finishing that for jessie; doesn't
> seem like it's needed at all anyway; this would have an impact on the
> next point anyway.
> [ Postponed ]
>
> * Artwork: I poked Paul and the desktop team some days ago; work seems
> to be happening, and packages should be updated “soon” to get updated
> artwork.
> [ Needed ]
>
> * Secure boot: nothing moved for a while but it seems some folks at
> DebConf were interested in helping.
> [ To be determined. Not a blocker at first glance. ]
>
> * Architecture support: my own, limited testing made me discover how
> badly broken d-i on GNU/kFreeBSD was, and I shared my concerns some
> days ago with BSD people and the release team. I haven't seen anyone
> commit to fixing d-i there and making sure it's kept in a good shape.
> [ To be determined, needs release team input at least. ]
>
> * Architecture support (bis): I'm not sure arm64 and ppc64el will be in
> a releasable shape (distribution wide) for jessie, but since we have
> very active porters, and since large parts are re-used from arm* and
> powerpc, it's likely that d-i support won't be an issue here. Some
> backporting might be needed on the kernel side, but I expect porters
> to do that kind of work as appropriate.
> [ To be determined ]
>
> * Regular releases: I'd like to avoid piling up stuff for too long
> between two releases. I'm not entirely convinced doing something
> time-based can work since we're sometimes depending on the kernel's
> state, or on a specific bug fix/package, or even on a library
> transition. But the delay between two beta/rc releases should go down
> to something like 1-2 months at most now (provided Steve is available
> on the debian-cd side of course). If I can anticipate release dates,
> I'll try and go back to announcing them (I think I did that for
> Wheezy Betas, when we were under freeze), along with possible udeb
> freezes (which was done for Jessie Beta 1).
> [ Very much wanted ]
>
> * Incoming bug handling: since we're reaching the end of the release
> cycle, and since betas are likely to get released more or less
> regularly, it'd be nice if we could find some people happy to deal
> with incoming bug reports, especially installation reports. Swift
> replies are likely the only way to keep (some) people interested in
> getting Debian installed on their machines/fixed so that it works
> better next time. Of course, regular BTS clean-up is always
> appreciated, but new bug reports should (IMHO) take precedence.
> [ Very much wanted, volunteers needed ]
>
> * Default desktop: I've already mentioned in [1,2] why I think we
> should go back to Gnome as default. The sooner the better, so that we
> get more exposure; and so that we fix regressions on the accessibility
> side, as soon as possible. See [3] for an example.
> 1. https://lists.debian.org/debian-devel/2014/08/msg00130.html
> 2. https://lists.debian.org/debian-devel/2014/08/msg00466.html
> 3. https://lists.debian.org/debian-accessibility/2014/08/msg00080.html
> [ Needed ]
>
> * Desktop choice: to avoid having to select/think about having to
> select a non-default desktop at boot time (which really isn't the
> place!) it was mentioned a while ago we could present a list of
> available+installable desktops after “Desktop environment” has been
> selected. This might also mitigate the concerns people might have
> about the default desktop. On the other hand, that means an extra
> prompt. And possibly more i18n/l10n material. But it seems to me that
> such a compromise might appease things a lot while not being an extra
> burden on the long run. I didn't work on that yet though; and while I
> initially thought it would be nice to have at the same time as we
> switch back to Gnome, I think both things can be done individually.
> [ Wanted ]
>
> Mraw,
> KiBi.
--
Hideki Yamane <henrich@iijmio-mail.jp>
Reply to: