Building a steady release cycle

Building a steady release cycle

[Jerone Young]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 4201 bytes --]

Re: Building a steady release cycle

[Jerone Young]

[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]

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 <jerone@gmail.com> 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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 5573 bytes --]

Re: Building a steady release cycle

[Robert Millan]

On Sun, Jan 04, 2009 at 09:55:13PM -0600, Jerone Young wrote:
> 
> Also Robert Millan has done a great job keeping things going (just had to
> say that).

Thank you!  But I never have as much time as I'd like to :-/

> >         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

Note that we have a document to keep track of these things (was it NEWS?).
If stuff is missing you could update it there.

Re: doing releases, currently only Marco or Okuji have permissions for that,
and in practice I think only Okuji has done it.  You'd have to speak with
them if you want to be added.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Building a steady release cycle

[Vesa Jääskeläinen]

Jerone Young 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.

I think it would be best to organize a release team which would then
plan and explode release to tasks so people could grab one and develop
them. Of course there should be some "backup" people that features
really do get developed.

Perhaps bi-weekly status checks would be a good idea to keep up with
status of every feature.

I can volunteer to be part of such team if decided to be started.

Also this work should be visible so it would be easy for others to tag
alone and help to develop missing features and to submit patches.

Re: Building a steady release cycle

[shirish]

Hi all,
 I would be glad to just know when there are releases being made, an
announce list or something would be good enough.

I use ubuntu and right now the only way I, as a user comes to know is
when debian makes a grub2 release in the experimental repository.

If such a release team is in place, it would (perhaps) be a bit more
visible to people who are not involved in the process as to what's
happening (people like me) .

-- 
          Regards,
          Shirish Agarwal
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17