grub-devel
[Top][All Lists]
Advanced

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

Re: Building a steady release cycle


From: Jerone Young
Subject: Re: Building a steady release cycle
Date: Sun, 4 Jan 2009 21:55:13 -0600

Bah! Sent before I was done.

Oh I also noticed openSuse may start testing EFI support

http://en.opensuse.org/Testing:Features_11.1#Support_all_EFI_platforms_-_was:_Grub2_support_for_EFI_BIOS_.28Feature_No:_301882.29

Also Robert Millan has done a great job keeping things going (just had to say that).

I wanted to get a general consensus on how folks felt about having more of a release schedule to work things up to 2.0, and kind of get things out of the experimental realm (at least that is the general feeling toward grub 2 at the moment).

                                                    Jerone

On Sun, Jan 4, 2009 at 9:45 PM, Jerone Young <address@hidden> wrote:
Hey guys,

        I wanted to start up a discussion on building a steady release cycle. Many distros are now looking for some stability from Grub 2 as they are looking to include it in future releases. I was recently at the Ubuntu Developer Summit in December discussing the possibility of including grub 2 in future releases. One of the big concerns was that there was not a steady release policy working up to 2.0.

        The main features that seem to be on everyones mind (from what I see is):
                     - stable x86 & x86-64 support
                             - have some testing matrix for crazy old bioses that don't work and some quirk is needed
                     - ability to boot grub2 from a CD (to replace isolinux)
                     - More of a test matrix for features
                             - LVM booting work?
                             - RAID ?
                             - RAID + LVM work?
                     - EFI support

         Some other features:
                     - UUID support
                     - loop
                     - ntfs

         While other archs are still being worked. These seem to be the most import at the moment. Of course this will help stabilies things for the other architectures also.
                            
        I'll  volunteer to doing the realeases (as I know noone wants this job). But just want a general consesus of a good schedule. To start things going. I was thinking marking an unstable binary release at the end of every month. While maybe setting some time table for stable (need to look the code over). I was thinking

                                     * Mark unstable binary release for testing at the end of every month
                                     * Marking a stable release after 2 unstable binary releases (that have been tested).


        What features do you guys think are still needed to bring things closer to a 2.0 release?



I know this has been tried sooooooooooo many time in the past, but this time I'm going to try my best to get things going.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]