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

Re: Debian installer and CD BoF: my views for jessie


 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: