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 <k...@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 <henr...@iijmio-mail.jp> -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140824212301.c2157a83df4cdb1064853...@iijmio-mail.jp
