GRUB release schedule?

GRUB release schedule?

[Bruce Dubbs]

Is there a release schedule for the next stable version of GRUB?  It 
would help for planning purposes.

   -- Bruce
      LFS

Re: GRUB release schedule?

[Daniel Kiper]

Hi Bruce,

On Sun, Oct 25, 2020 at 11:59:07AM -0500, Bruce Dubbs wrote:
> Is there a release schedule for the next stable version of GRUB?  It would
> help for planning purposes.

I am working on it now. I hope to cut rc1 in the following weeks and
then release 2.06 in December.

Daniel

GRUB release schedule?

[Peter Jones]

Hi everyone,
Is there a plan for when upcoming GNU GRUB releases will happen?

As far as I can tell, the last official release on
ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
committed since that beta 18 months ago.

In the mean time, nearly every Linux distro is shipping a package
derived from the 2.02~beta2 release plus some number of patches,
some from the upstream repo and some not, and it's cumbersome to rectify
which ones aren't upstream vs which ones have been fixed upstream with
/nearly/ the same patch, etc., with all the noise of so many patches
since the release.

I suspect this would be better for a lot of GRUB users if releases
happened on a regular schedule, or if, relatively often (say once or
twice per year), a release schedule that spans several weeks and
organized some kind of alpha->beta->release progression were decided
upon and followed.

So, can we make a release process that happens according to some regular
cadence?  What needs to be done to make regular releases happen?  Going
for years with the patch volume GRUB sees without doing a release is
really not good for anybody.

-- 
        Peter

Re: GRUB release schedule?

[Vladimir 'phcoder' Serbinenko]

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

I'll do next beta tomorrow and will assess current open bugs to see how far
we're from release
Le 20 juil. 2015 20:23, "Peter Jones" <pjones@redhat.com> a écrit :

> Hi everyone,
> Is there a plan for when upcoming GNU GRUB releases will happen?
>
> As far as I can tell, the last official release on
> ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> committed since that beta 18 months ago.
>
> In the mean time, nearly every Linux distro is shipping a package
> derived from the 2.02~beta2 release plus some number of patches,
> some from the upstream repo and some not, and it's cumbersome to rectify
> which ones aren't upstream vs which ones have been fixed upstream with
> /nearly/ the same patch, etc., with all the noise of so many patches
> since the release.
>
> I suspect this would be better for a lot of GRUB users if releases
> happened on a regular schedule, or if, relatively often (say once or
> twice per year), a release schedule that spans several weeks and
> organized some kind of alpha->beta->release progression were decided
> upon and followed.
>
> So, can we make a release process that happens according to some regular
> cadence?  What needs to be done to make regular releases happen?  Going
> for years with the patch volume GRUB sees without doing a release is
> really not good for anybody.
>
> --
>         Peter
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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

Re: GRUB release schedule?

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 20.07.2015 21:25, Vladimir 'phcoder' Serbinenko wrote:
> I'll do next beta tomorrow and will assess current open bugs to see how
> far we're from release
> 
Fixing tests takes longer than expected. I'll continue tomorrow.
> Le 20 juil. 2015 20:23, "Peter Jones" <pjones@redhat.com
> <mailto:pjones@redhat.com>> a écrit :
> 
>     Hi everyone,
>     Is there a plan for when upcoming GNU GRUB releases will happen?
> 
>     As far as I can tell, the last official release on
>     ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
>     on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
>     2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
>     committed since that beta 18 months ago.
> 
>     In the mean time, nearly every Linux distro is shipping a package
>     derived from the 2.02~beta2 release plus some number of patches,
>     some from the upstream repo and some not, and it's cumbersome to rectify
>     which ones aren't upstream vs which ones have been fixed upstream with
>     /nearly/ the same patch, etc., with all the noise of so many patches
>     since the release.
> 
>     I suspect this would be better for a lot of GRUB users if releases
>     happened on a regular schedule, or if, relatively often (say once or
>     twice per year), a release schedule that spans several weeks and
>     organized some kind of alpha->beta->release progression were decided
>     upon and followed.
> 
>     So, can we make a release process that happens according to some regular
>     cadence?  What needs to be done to make regular releases happen?  Going
>     for years with the patch volume GRUB sees without doing a release is
>     really not good for anybody.
> 
>     --
>             Peter
> 
>     _______________________________________________
>     Grub-devel mailing list
>     Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>
>     https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: GRUB release schedule?

[Bruce Dubbs]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 20.07.2015 21:25, Vladimir 'phcoder' Serbinenko wrote:
>> I'll do next beta tomorrow and will assess current open bugs to see how
>> far we're from release
>>
> Fixing tests takes longer than expected. I'll continue tomorrow.

Any more on this?

>> Le 20 juil. 2015 20:23, "Peter Jones" <pjones@redhat.com
>> <mailto:pjones@redhat.com>> a écrit :
>>
>>      Hi everyone,
>>      Is there a plan for when upcoming GNU GRUB releases will happen?
>>
>>      As far as I can tell, the last official release on
>>      ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
>>      on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
>>      2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
>>      committed since that beta 18 months ago.
>>
>>      In the mean time, nearly every Linux distro is shipping a package
>>      derived from the 2.02~beta2 release plus some number of patches,
>>      some from the upstream repo and some not, and it's cumbersome to rectify
>>      which ones aren't upstream vs which ones have been fixed upstream with
>>      /nearly/ the same patch, etc., with all the noise of so many patches
>>      since the release.
>>
>>      I suspect this would be better for a lot of GRUB users if releases
>>      happened on a regular schedule, or if, relatively often (say once or
>>      twice per year), a release schedule that spans several weeks and
>>      organized some kind of alpha->beta->release progression were decided
>>      upon and followed.

I agree.

   -- Bruce Dubbs
      linuxfromscratch.org

Re: GRUB release schedule?

[Vladimir 'phcoder' Serbinenko]

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

i386-ieee1275 and some other ports still fail the tests
Le 29 juil. 2015 9:09 PM, "Bruce Dubbs" <bruce.dubbs@gmail.com> a écrit :

> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> On 20.07.2015 21:25, Vladimir 'phcoder' Serbinenko wrote:
>>
>>> I'll do next beta tomorrow and will assess current open bugs to see how
>>> far we're from release
>>>
>>>  Fixing tests takes longer than expected. I'll continue tomorrow.
>>
>
> Any more on this?
>
>  Le 20 juil. 2015 20:23, "Peter Jones" <pjones@redhat.com
>>> <mailto:pjones@redhat.com>> a écrit :
>>>
>>>      Hi everyone,
>>>      Is there a plan for when upcoming GNU GRUB releases will happen?
>>>
>>>      As far as I can tell, the last official release on
>>>      ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last
>>> beta
>>>      on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
>>>      2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
>>>      committed since that beta 18 months ago.
>>>
>>>      In the mean time, nearly every Linux distro is shipping a package
>>>      derived from the 2.02~beta2 release plus some number of patches,
>>>      some from the upstream repo and some not, and it's cumbersome to
>>> rectify
>>>      which ones aren't upstream vs which ones have been fixed upstream
>>> with
>>>      /nearly/ the same patch, etc., with all the noise of so many patches
>>>      since the release.
>>>
>>>      I suspect this would be better for a lot of GRUB users if releases
>>>      happened on a regular schedule, or if, relatively often (say once or
>>>      twice per year), a release schedule that spans several weeks and
>>>      organized some kind of alpha->beta->release progression were decided
>>>      upon and followed.
>>>
>>
> I agree.
>
>   -- Bruce Dubbs
>      linuxfromscratch.org
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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

Re: GRUB release schedule?

[Peter Jones]

On Mon, Jul 20, 2015 at 09:25:56PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> I'll do next beta tomorrow and will assess current open bugs to see how far
> we're from release

Did this ever happen?  It doesn't appear as though it did.

So I'm back with my original question: What's the path to regular
releases?  I don't honestly believe we have to fix everything about
source control, patch contribution, and test suites to do that, though
those are all important things.  Plenty of projects do releases with the
same tools this one has, with great success.  But this is one more case
where the search for perfection is stopping us from having any releases
*at all*.

"Fix everything in the code *and* the infrastructure and then do a
release" is not workable.  We need to have regular releases, and we need
to make improvements to the project's infrastructure and processes be a
part of those releases.  Waiting for a flag day with each thing to be
improved just means delaying indefinitely, especially if the wish list
includes things nobody is actively working on.

So that means we need two things: 1) decide on a schedule for one release,
2) decide when the ones after it will be.

Here's a suggestion: Schedule a release at the end of January, and work
towards that.  It doesn't have to be perfect; everybody is shipping
something based on the current tree already anyway.  Then plan on
another release at the end of July, and follow that plan indefinitely.
It's okay if there are reasons to adjust it sometimes, but let's start
with a plan.

Thoughts?


> Le 20 juil. 2015 20:23, "Peter Jones" <pjones@redhat.com> a écrit :
> 
> > Hi everyone,
> > Is there a plan for when upcoming GNU GRUB releases will happen?
> >
> > As far as I can tell, the last official release on
> > ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> > on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> > 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> > committed since that beta 18 months ago.
> >
> > In the mean time, nearly every Linux distro is shipping a package
> > derived from the 2.02~beta2 release plus some number of patches,
> > some from the upstream repo and some not, and it's cumbersome to rectify
> > which ones aren't upstream vs which ones have been fixed upstream with
> > /nearly/ the same patch, etc., with all the noise of so many patches
> > since the release.
> >
> > I suspect this would be better for a lot of GRUB users if releases
> > happened on a regular schedule, or if, relatively often (say once or
> > twice per year), a release schedule that spans several weeks and
> > organized some kind of alpha->beta->release progression were decided
> > upon and followed.
> >
> > So, can we make a release process that happens according to some regular
> > cadence?  What needs to be done to make regular releases happen?  Going
> > for years with the patch volume GRUB sees without doing a release is
> > really not good for anybody.
> >
> > --
> >         Peter
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >

> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
        Peter

Re: GRUB release schedule?

[Josef Bacik]

On 12/08/2015 03:55 PM, Peter Jones wrote:
> On Mon, Jul 20, 2015 at 09:25:56PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> I'll do next beta tomorrow and will assess current open bugs to see how far
>> we're from release
>
> Did this ever happen?  It doesn't appear as though it did.
>
> So I'm back with my original question: What's the path to regular
> releases?  I don't honestly believe we have to fix everything about
> source control, patch contribution, and test suites to do that, though
> those are all important things.  Plenty of projects do releases with the
> same tools this one has, with great success.  But this is one more case
> where the search for perfection is stopping us from having any releases
> *at all*.
>
> "Fix everything in the code *and* the infrastructure and then do a
> release" is not workable.  We need to have regular releases, and we need
> to make improvements to the project's infrastructure and processes be a
> part of those releases.  Waiting for a flag day with each thing to be
> improved just means delaying indefinitely, especially if the wish list
> includes things nobody is actively working on.
>
> So that means we need two things: 1) decide on a schedule for one release,
> 2) decide when the ones after it will be.
>
> Here's a suggestion: Schedule a release at the end of January, and work
> towards that.  It doesn't have to be perfect; everybody is shipping
> something based on the current tree already anyway.  Then plan on
> another release at the end of July, and follow that plan indefinitely.
> It's okay if there are reasons to adjust it sometimes, but let's start
> with a plan.
>
> Thoughts?
>

I'd like to second this.  ATM we're just running whatever is in my 
github copy of grub2, which I rebase whenever somebody tells me to.  If 
we have consistent releases then it'll make it easier for me to run 
automated tests internally as well as have clear indicators when I need 
to rebase and figure out what outstanding patches I still have pending. 
  Thanks,

Josef

Re: GRUB release schedule?

[Andrei Borzenkov]

В Mon, 20 Jul 2015 14:22:45 -0400
Peter Jones <pjones@redhat.com> пишет:

> Hi everyone,
> Is there a plan for when upcoming GNU GRUB releases will happen?
> 
> As far as I can tell, the last official release on
> ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> committed since that beta 18 months ago.
> 
> In the mean time, nearly every Linux distro is shipping a package
> derived from the 2.02~beta2 release plus some number of patches,
> some from the upstream repo and some not, and it's cumbersome to rectify
> which ones aren't upstream vs which ones have been fixed upstream with
> /nearly/ the same patch, etc., with all the noise of so many patches
> since the release.
> 
> I suspect this would be better for a lot of GRUB users if releases
> happened on a regular schedule, or if, relatively often (say once or
> twice per year), a release schedule that spans several weeks and
> organized some kind of alpha->beta->release progression were decided
> upon and followed.
> 
> So, can we make a release process that happens according to some regular
> cadence?  What needs to be done to make regular releases happen?

Apart from having more active contributors? :) Automating build and
regression tests would definitely help it.

>                                                                 Going
> for years with the patch volume GRUB sees without doing a release is
> really not good for anybody.
> 

Re: GRUB release schedule?

[Vladimir 'phcoder' Serbinenko]

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

Le 24 juil. 2015 06:20, "Andrei Borzenkov" <arvidjaar@gmail.com> a écrit :
>
> В Mon, 20 Jul 2015 14:22:45 -0400
> Peter Jones <pjones@redhat.com> пишет:
>
> > Hi everyone,
> > Is there a plan for when upcoming GNU GRUB releases will happen?
> >
> > As far as I can tell, the last official release on
> > ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> > on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> > 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> > committed since that beta 18 months ago.
> >
> > In the mean time, nearly every Linux distro is shipping a package
> > derived from the 2.02~beta2 release plus some number of patches,
> > some from the upstream repo and some not, and it's cumbersome to rectify
> > which ones aren't upstream vs which ones have been fixed upstream with
> > /nearly/ the same patch, etc., with all the noise of so many patches
> > since the release.
> >
> > I suspect this would be better for a lot of GRUB users if releases
> > happened on a regular schedule, or if, relatively often (say once or
> > twice per year), a release schedule that spans several weeks and
> > organized some kind of alpha->beta->release progression were decided
> > upon and followed.
> >
> > So, can we make a release process that happens according to some regular
> > cadence?  What needs to be done to make regular releases happen?
>
> Apart from having more active contributors? :) Automating build and
> regression tests would definitely help it.
>
Actually there is something more useful: code review system like gerrit.
Does Savannah have one?
> >                                                                 Going
> > for years with the patch volume GRUB sees without doing a release is
> > really not good for anybody.
> >
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

Re: GRUB release schedule?

[Andrei Borzenkov]

On Fri, Jul 24, 2015 at 11:03 AM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
> Le 24 juil. 2015 06:20, "Andrei Borzenkov" <arvidjaar@gmail.com> a écrit :
>>
>> В Mon, 20 Jul 2015 14:22:45 -0400
>> Peter Jones <pjones@redhat.com> пишет:
>>
>> > Hi everyone,
>> > Is there a plan for when upcoming GNU GRUB releases will happen?
>> >
>> > As far as I can tell, the last official release on
>> > ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
>> > on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
>> > 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
>> > committed since that beta 18 months ago.
>> >
>> > In the mean time, nearly every Linux distro is shipping a package
>> > derived from the 2.02~beta2 release plus some number of patches,
>> > some from the upstream repo and some not, and it's cumbersome to rectify
>> > which ones aren't upstream vs which ones have been fixed upstream with
>> > /nearly/ the same patch, etc., with all the noise of so many patches
>> > since the release.
>> >
>> > I suspect this would be better for a lot of GRUB users if releases
>> > happened on a regular schedule, or if, relatively often (say once or
>> > twice per year), a release schedule that spans several weeks and
>> > organized some kind of alpha->beta->release progression were decided
>> > upon and followed.
>> >
>> > So, can we make a release process that happens according to some regular
>> > cadence?  What needs to be done to make regular releases happen?
>>
>> Apart from having more active contributors? :) Automating build and
>> regression tests would definitely help it.
>>
> Actually there is something more useful: code review system like gerrit.
> Does Savannah have one?

It does not look so. Wikipedia says "yes" but author probably confused
initial project code review with normal collaboration.

Savannah seems to offer build farm for GNU projects; according to it

Currently it can build software on GNU/Linux (i686 and x86_64) as well
as FreeBSD, Darwin, Solaris, and Cygwin, and can cross-build for
GNU/Hurd, GNU/Linux on other architectures, and MinGW.


Is github mirror together with gerrithub an option?

Re: GRUB release schedule?

[Josef Bacik]

On 07/20/2015 11:22 AM, Peter Jones wrote:
> Hi everyone,
> Is there a plan for when upcoming GNU GRUB releases will happen?
>
> As far as I can tell, the last official release on
> ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> committed since that beta 18 months ago.
>
> In the mean time, nearly every Linux distro is shipping a package
> derived from the 2.02~beta2 release plus some number of patches,
> some from the upstream repo and some not, and it's cumbersome to rectify
> which ones aren't upstream vs which ones have been fixed upstream with
> /nearly/ the same patch, etc., with all the noise of so many patches
> since the release.
>
> I suspect this would be better for a lot of GRUB users if releases
> happened on a regular schedule, or if, relatively often (say once or
> twice per year), a release schedule that spans several weeks and
> organized some kind of alpha->beta->release progression were decided
> upon and followed.
>
> So, can we make a release process that happens according to some regular
> cadence?  What needs to be done to make regular releases happen?  Going
> for years with the patch volume GRUB sees without doing a release is
> really not good for anybody.
>

I'd like to +1 this.  I think the tests are important for sure, but 
there's no reason we can't set a release cadence and at least cut an 
-rc1 and spend some time fixing up the test failures.  Facebook is going 
to be using grub2 in our provisioning environment, we would like to have 
official builds rather than running from git.  Thanks,

Josef

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
> On 07/20/2015 11:22 AM, Peter Jones wrote:
> >Hi everyone,
> >Is there a plan for when upcoming GNU GRUB releases will happen?
> >
> >As far as I can tell, the last official release on
> >ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> >on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> >2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> >committed since that beta 18 months ago.
> >
> >In the mean time, nearly every Linux distro is shipping a package
> >derived from the 2.02~beta2 release plus some number of patches,
> >some from the upstream repo and some not, and it's cumbersome to rectify
> >which ones aren't upstream vs which ones have been fixed upstream with
> >/nearly/ the same patch, etc., with all the noise of so many patches
> >since the release.
> >
> >I suspect this would be better for a lot of GRUB users if releases
> >happened on a regular schedule, or if, relatively often (say once or
> >twice per year), a release schedule that spans several weeks and
> >organized some kind of alpha->beta->release progression were decided
> >upon and followed.
> >
> >So, can we make a release process that happens according to some regular
> >cadence?  What needs to be done to make regular releases happen?  Going
> >for years with the patch volume GRUB sees without doing a release is
> >really not good for anybody.
> >
> 
> I'd like to +1 this.  I think the tests are important for sure, but there's
> no reason we can't set a release cadence and at least cut an -rc1 and spend
> some time fixing up the test failures.  Facebook is going to be using grub2
> in our provisioning environment, we would like to have official builds
> rather than running from git.  Thanks,

What is the tests that are needed? Surely as different distros we could
pool some hardware together to make this work?

What do GRUB maintainers think are the top tests that are needed and
on what architectures? And do you have any ideas on how to automate it?
> 
> Josef
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Josef Bacik]

On 08/21/2015 10:11 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
>> On 07/20/2015 11:22 AM, Peter Jones wrote:
>>> Hi everyone,
>>> Is there a plan for when upcoming GNU GRUB releases will happen?
>>>
>>> As far as I can tell, the last official release on
>>> ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
>>> on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
>>> 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
>>> committed since that beta 18 months ago.
>>>
>>> In the mean time, nearly every Linux distro is shipping a package
>>> derived from the 2.02~beta2 release plus some number of patches,
>>> some from the upstream repo and some not, and it's cumbersome to rectify
>>> which ones aren't upstream vs which ones have been fixed upstream with
>>> /nearly/ the same patch, etc., with all the noise of so many patches
>>> since the release.
>>>
>>> I suspect this would be better for a lot of GRUB users if releases
>>> happened on a regular schedule, or if, relatively often (say once or
>>> twice per year), a release schedule that spans several weeks and
>>> organized some kind of alpha->beta->release progression were decided
>>> upon and followed.
>>>
>>> So, can we make a release process that happens according to some regular
>>> cadence?  What needs to be done to make regular releases happen?  Going
>>> for years with the patch volume GRUB sees without doing a release is
>>> really not good for anybody.
>>>
>>
>> I'd like to +1 this.  I think the tests are important for sure, but there's
>> no reason we can't set a release cadence and at least cut an -rc1 and spend
>> some time fixing up the test failures.  Facebook is going to be using grub2
>> in our provisioning environment, we would like to have official builds
>> rather than running from git.  Thanks,
>
> What is the tests that are needed? Surely as different distros we could
> pool some hardware together to make this work?
>

There was just some mention of tests failing earlier in the thread, 
that's what I was talking about.

> What do GRUB maintainers think are the top tests that are needed and
> on what architectures? And do you have any ideas on how to automate it?

We're automating testing internally by provisioning the different types 
of boxes we have with grub2.  Once I have the ipv6 and tcp window 
scaling stuff in I plan to have continuous testing on grub2 to make sure 
our use case doesn't get broken by somebody.  Thanks,

Josef

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Fri, Aug 21, 2015 at 10:18:08AM -0700, Josef Bacik wrote:
> On 08/21/2015 10:11 AM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
> >>On 07/20/2015 11:22 AM, Peter Jones wrote:
> >>>Hi everyone,
> >>>Is there a plan for when upcoming GNU GRUB releases will happen?
> >>>
> >>>As far as I can tell, the last official release on
> >>>ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> >>>on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> >>>2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> >>>committed since that beta 18 months ago.
> >>>
> >>>In the mean time, nearly every Linux distro is shipping a package
> >>>derived from the 2.02~beta2 release plus some number of patches,
> >>>some from the upstream repo and some not, and it's cumbersome to rectify
> >>>which ones aren't upstream vs which ones have been fixed upstream with
> >>>/nearly/ the same patch, etc., with all the noise of so many patches
> >>>since the release.
> >>>
> >>>I suspect this would be better for a lot of GRUB users if releases
> >>>happened on a regular schedule, or if, relatively often (say once or
> >>>twice per year), a release schedule that spans several weeks and
> >>>organized some kind of alpha->beta->release progression were decided
> >>>upon and followed.
> >>>
> >>>So, can we make a release process that happens according to some regular
> >>>cadence?  What needs to be done to make regular releases happen?  Going
> >>>for years with the patch volume GRUB sees without doing a release is
> >>>really not good for anybody.
> >>>
> >>
> >>I'd like to +1 this.  I think the tests are important for sure, but there's
> >>no reason we can't set a release cadence and at least cut an -rc1 and spend
> >>some time fixing up the test failures.  Facebook is going to be using grub2
> >>in our provisioning environment, we would like to have official builds
> >>rather than running from git.  Thanks,
> >
> >What is the tests that are needed? Surely as different distros we could
> >pool some hardware together to make this work?
> >
> 
> There was just some mention of tests failing earlier in the thread, that's
> what I was talking about.

Right.
> 
> >What do GRUB maintainers think are the top tests that are needed and
> >on what architectures? And do you have any ideas on how to automate it?
> 
> We're automating testing internally by provisioning the different types of
> boxes we have with grub2.  Once I have the ipv6 and tcp window scaling stuff
> in I plan to have continuous testing on grub2 to make sure our use case
> doesn't get broken by somebody.  Thanks,

Fantastic! Would there by any way to get this reflector copied on the emails
on the testing?
> 
> Josef
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Josef Bacik]

On 08/21/2015 10:30 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 21, 2015 at 10:18:08AM -0700, Josef Bacik wrote:
>> On 08/21/2015 10:11 AM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
>>>> On 07/20/2015 11:22 AM, Peter Jones wrote:
>>>>> Hi everyone,
>>>>> Is there a plan for when upcoming GNU GRUB releases will happen?
>>>>>
>>>>> As far as I can tell, the last official release on
>>>>> ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
>>>>> on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
>>>>> 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
>>>>> committed since that beta 18 months ago.
>>>>>
>>>>> In the mean time, nearly every Linux distro is shipping a package
>>>>> derived from the 2.02~beta2 release plus some number of patches,
>>>>> some from the upstream repo and some not, and it's cumbersome to rectify
>>>>> which ones aren't upstream vs which ones have been fixed upstream with
>>>>> /nearly/ the same patch, etc., with all the noise of so many patches
>>>>> since the release.
>>>>>
>>>>> I suspect this would be better for a lot of GRUB users if releases
>>>>> happened on a regular schedule, or if, relatively often (say once or
>>>>> twice per year), a release schedule that spans several weeks and
>>>>> organized some kind of alpha->beta->release progression were decided
>>>>> upon and followed.
>>>>>
>>>>> So, can we make a release process that happens according to some regular
>>>>> cadence?  What needs to be done to make regular releases happen?  Going
>>>>> for years with the patch volume GRUB sees without doing a release is
>>>>> really not good for anybody.
>>>>>
>>>>
>>>> I'd like to +1 this.  I think the tests are important for sure, but there's
>>>> no reason we can't set a release cadence and at least cut an -rc1 and spend
>>>> some time fixing up the test failures.  Facebook is going to be using grub2
>>>> in our provisioning environment, we would like to have official builds
>>>> rather than running from git.  Thanks,
>>>
>>> What is the tests that are needed? Surely as different distros we could
>>> pool some hardware together to make this work?
>>>
>>
>> There was just some mention of tests failing earlier in the thread, that's
>> what I was talking about.
>
> Right.
>>
>>> What do GRUB maintainers think are the top tests that are needed and
>>> on what architectures? And do you have any ideas on how to automate it?
>>
>> We're automating testing internally by provisioning the different types of
>> boxes we have with grub2.  Once I have the ipv6 and tcp window scaling stuff
>> in I plan to have continuous testing on grub2 to make sure our use case
>> doesn't get broken by somebody.  Thanks,
>
> Fantastic! Would there by any way to get this reflector copied on the emails
> on the testing?

Yeah, Facebook is not interested in carrying internal patches on open 
source patches for long periods of time (obviously we'll carry stuff to 
fix our problem right now while we work out getting it fixed upstream). 
  Whenever anything breaks there will be a loud screaming noise coming 
from my corner of the world followed by emails to everybody who's to 
blame.  Thanks,

Josef

Re: GRUB release schedule?

[Andrei Borzenkov]

21.08.2015 20:11, Konrad Rzeszutek Wilk пишет:
> On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
>> On 07/20/2015 11:22 AM, Peter Jones wrote:
>>> Hi everyone,
>>> Is there a plan for when upcoming GNU GRUB releases will happen?
>>>
>>> As far as I can tell, the last official release on
>>> ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
>>> on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
>>> 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
>>> committed since that beta 18 months ago.
>>>
>>> In the mean time, nearly every Linux distro is shipping a package
>>> derived from the 2.02~beta2 release plus some number of patches,
>>> some from the upstream repo and some not, and it's cumbersome to rectify
>>> which ones aren't upstream vs which ones have been fixed upstream with
>>> /nearly/ the same patch, etc., with all the noise of so many patches
>>> since the release.
>>>
>>> I suspect this would be better for a lot of GRUB users if releases
>>> happened on a regular schedule, or if, relatively often (say once or
>>> twice per year), a release schedule that spans several weeks and
>>> organized some kind of alpha->beta->release progression were decided
>>> upon and followed.
>>>
>>> So, can we make a release process that happens according to some regular
>>> cadence?  What needs to be done to make regular releases happen?  Going
>>> for years with the patch volume GRUB sees without doing a release is
>>> really not good for anybody.
>>>
>>
>> I'd like to +1 this.  I think the tests are important for sure, but there's
>> no reason we can't set a release cadence and at least cut an -rc1 and spend
>> some time fixing up the test failures.  Facebook is going to be using grub2
>> in our provisioning environment, we would like to have official builds
>> rather than running from git.  Thanks,
>
> What is the tests that are needed? Surely as different distros we could
> pool some hardware together to make this work?
>
> What do GRUB maintainers think are the top tests that are needed and
> on what architectures? And do you have any ideas on how to automate it?
>>

GRUB includes comprehensive amount of regression tests. Just run "make 
check". The practical problems are

- many tests require additional tools (filesystem tests need at least 
mkfs for respective file system, LVM etc)

- each platform must be built separately; that requires either native 
system or cross tools (which itself may not be trivial). So I e.g. am 
limited to x86

- tests are not really formalized, you get PASS/FAIL but what failed is 
up to human to understand

- some tests require server part, e.g. to run anything involving HTTP 
server must be available

- some tests are pretty heavy hit; it is better now when I have new 
hardware still I cannot dream running them continuously on my notebook ...

Of course addition to regression testing is always welcome.

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Fri, Aug 21, 2015 at 09:24:33PM +0300, Andrei Borzenkov wrote:
> 21.08.2015 20:11, Konrad Rzeszutek Wilk пишет:
> >On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
> >>On 07/20/2015 11:22 AM, Peter Jones wrote:
> >>>Hi everyone,
> >>>Is there a plan for when upcoming GNU GRUB releases will happen?
> >>>
> >>>As far as I can tell, the last official release on
> >>>ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
> >>>on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
> >>>2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
> >>>committed since that beta 18 months ago.
> >>>
> >>>In the mean time, nearly every Linux distro is shipping a package
> >>>derived from the 2.02~beta2 release plus some number of patches,
> >>>some from the upstream repo and some not, and it's cumbersome to rectify
> >>>which ones aren't upstream vs which ones have been fixed upstream with
> >>>/nearly/ the same patch, etc., with all the noise of so many patches
> >>>since the release.
> >>>
> >>>I suspect this would be better for a lot of GRUB users if releases
> >>>happened on a regular schedule, or if, relatively often (say once or
> >>>twice per year), a release schedule that spans several weeks and
> >>>organized some kind of alpha->beta->release progression were decided
> >>>upon and followed.
> >>>
> >>>So, can we make a release process that happens according to some regular
> >>>cadence?  What needs to be done to make regular releases happen?  Going
> >>>for years with the patch volume GRUB sees without doing a release is
> >>>really not good for anybody.
> >>>
> >>
> >>I'd like to +1 this.  I think the tests are important for sure, but there's
> >>no reason we can't set a release cadence and at least cut an -rc1 and spend
> >>some time fixing up the test failures.  Facebook is going to be using grub2
> >>in our provisioning environment, we would like to have official builds
> >>rather than running from git.  Thanks,
> >
> >What is the tests that are needed? Surely as different distros we could
> >pool some hardware together to make this work?
> >
> >What do GRUB maintainers think are the top tests that are needed and
> >on what architectures? And do you have any ideas on how to automate it?
> >>
> 
> GRUB includes comprehensive amount of regression tests. Just run "make
> check". The practical problems are
> 
> - many tests require additional tools (filesystem tests need at least mkfs
> for respective file system, LVM etc)
> 
> - each platform must be built separately; that requires either native system
> or cross tools (which itself may not be trivial). So I e.g. am limited to
> x86
> 
> - tests are not really formalized, you get PASS/FAIL but what failed is up
> to human to understand
> 
> - some tests require server part, e.g. to run anything involving HTTP server
> must be available
> 
> - some tests are pretty heavy hit; it is better now when I have new hardware
> still I cannot dream running them continuously on my notebook ...
> 
> Of course addition to regression testing is always welcome.

Lets start with a list of priorities:
 - What are the most important platforms after x86?
 - What are the most important tests that MUST PASS all the time?
 - Which ones have been FAILing for years? 

Surely if we weed out the most important cases that cover 99% that will
give the foundation for going out with a release?

> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Bruce Dubbs]

Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 21, 2015 at 09:24:33PM +0300, Andrei Borzenkov wrote:

>> GRUB includes comprehensive amount of regression tests. Just run "make
>> check". The practical problems are
>>
>> - many tests require additional tools (filesystem tests need at least mkfs
>> for respective file system, LVM etc)
>>
>> - each platform must be built separately; that requires either native system
>> or cross tools (which itself may not be trivial). So I e.g. am limited to
>> x86
>>
>> - tests are not really formalized, you get PASS/FAIL but what failed is up
>> to human to understand
>>
>> - some tests require server part, e.g. to run anything involving HTTP server
>> must be available
>>
>> - some tests are pretty heavy hit; it is better now when I have new hardware
>> still I cannot dream running them continuously on my notebook ...
>>
>> Of course addition to regression testing is always welcome.
>
> Lets start with a list of priorities:
>   - What are the most important platforms after x86?
>   - What are the most important tests that MUST PASS all the time?
>   - Which ones have been FAILing for years?
>
> Surely if we weed out the most important cases that cover 99% that will
> give the foundation for going out with a release?

Although tests are very useful, not all packages ship tests.  One prime 
example is the linux kernel, but there are many more.

Tests depend on external programs and specific setups used by the 
developers, but often are not available on builder's systems.  For 
example, in grub-2.02~beta2, I get:

============================================================================
Testsuite summary for GRUB 2.02~beta2
============================================================================
# TOTAL: 78
# PASS:  12
# SKIP:  18
# XFAIL: 0
# FAIL:  48
# XPASS: 0
# ERROR: 0

That doesn't mean that the build is bad on a x86_64 system.  It works 
quite well (although grub-mkconfig always produces an unusable 
configuration for us.)


A lot of the FAILs are due to things like:

FAIL: iso9660_test
==================

cp: cannot stat '/usr/share/dict/linux.words': No such file or directory

although I have other dictionaries.

FAIL: pata_test
===============

tar: Removing leading `/' from member names
timeout: failed to run command 'qemu-system-i386': No such file or directory

Although I have /usr/bin/qemu -> qemu-system-x86_64

This corresponds to 45 of the 48 "FAILs" above.  Creating a symlink 
qemu-system-i386 to qemu-system-x86_64 allows most ot the tests to pass, 
but hangs after test_unset.

++++++++++++

In other words, the tests are highly sensitive to the user's system.

Please do not let the tests shipped in the tarball hold up a release. 
Perfect is the enemy of good enough.

   -- Bruce Dubbs
      linuxfromscratch.org

Re: GRUB release schedule?

[Andrei Borzenkov]

21.08.2015 22:55, Bruce Dubbs пишет:
> but hangs after test_unset.
>

Yes, I noticed this as well. This smells like real bug as it just loads 
and runs several GRUB modules, there is no external dependency.

Re: GRUB release schedule?

[Andrei Borzenkov]

21.08.2015 21:41, Konrad Rzeszutek Wilk пишет:
>
> Lets start with a list of priorities:
>   - What are the most important platforms after x86?

I suppose distribution-wise they are ARM and PPC. This means 5 different 
GRUB builds. MIPS seems to be still in use, at least there are patches 
and bug reports.

>   - What are the most important tests that MUST PASS all the time?

All of them actually. There is one test that unfortunately is bound to 
fail unless built in controlled environment.

>   - Which ones have been FAILing for years?
>

Hard to know, there are no published results.

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Sat, Aug 22, 2015 at 08:16:26AM +0300, Andrei Borzenkov wrote:
> 21.08.2015 21:41, Konrad Rzeszutek Wilk пишет:
> >
> >Lets start with a list of priorities:
> >  - What are the most important platforms after x86?
> 
> I suppose distribution-wise they are ARM and PPC. This means 5 different
> GRUB builds. MIPS seems to be still in use, at least there are patches and
> bug reports.

x86-32 (BIOS)
x86-EFI
ARM-32
ARM-64
ARM-EFI ?

PPC-32
PPC-64
?

> 
> >  - What are the most important tests that MUST PASS all the time?
> 
> All of them actually. There is one test that unfortunately is bound to fail
> unless built in controlled environment.

Can the test be skipped if the environment is not controlled?

> 
> >  - Which ones have been FAILing for years?
> >
> 
> Hard to know, there are no published results.
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel