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-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

Re: Fwd: RE: GRUB release schedule?

[Bruce Dubbs]

Any progress on this?


Vladimir 'phcoder' Serbinenko wrote:

-- Message transféré --
De : "Vladimir 'phcoder' Serbinenko" <phco...@gmail.com>
Date : 4 janv. 2016 10:40 PM
Objet : RE: GRUB release schedule?
À : "Elliott, Robert (Persistent Memory)" <elli...@hpe.com>
Cc :

I'm currently running tests in order to make next beta. I see quite some
failures and try to sort them out



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

Fwd: RE: GRUB release schedule?

[Vladimir 'phcoder' Serbinenko]

-- Message transféré --
De : "Vladimir 'phcoder' Serbinenko" <phco...@gmail.com>
Date : 4 janv. 2016 10:40 PM
Objet : RE: GRUB release schedule?
À : "Elliott, Robert (Persistent Memory)" <elli...@hpe.com>
Cc :

I'm currently running tests in order to make next beta. I see quite some
failures and try to sort them out
Le 4 janv. 2016 10:38 PM, "Elliott, Robert (Persistent Memory)" <
elli...@hpe.com> a écrit :

> Any thoughts on this request (and my requests for a 4.3 tag to
> signify that NVDIMM fixes are in place)?
>
>
>
> -Original Message-
> From: grub-devel-bounces+elliott=hp@gnu.org [mailto:
> grub-devel-bounces+elliott=hp@gnu.org] On Behalf Of Josef Bacik
> Sent: Tuesday, December 08, 2015 3:34 PM
> To: The development of GNU GRUB <grub-devel@gnu.org>
> Subject: Re: GRUB release schedule?
>
> 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
>
>
> ___
> 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

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

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

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

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

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.

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

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.


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

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

___
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

___
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


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

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.

___
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


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

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

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

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

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

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

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

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 pjo...@redhat.com
mailto:pjo...@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

Re: GRUB release schedule?

[Vladimir 'phcoder' Serbinenko]

i386-ieee1275 and some other ports still fail the tests
Le 29 juil. 2015 9:09 PM, Bruce Dubbs bruce.du...@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 pjo...@redhat.com
 mailto:pjo...@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

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

Re: GRUB release schedule?

[Vladimir 'phcoder' Serbinenko]

Le 24 juil. 2015 06:20, Andrei Borzenkov arvidj...@gmail.com a écrit :

 В Mon, 20 Jul 2015 14:22:45 -0400
 Peter Jones pjo...@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
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Andrei Borzenkov]

On Fri, Jul 24, 2015 at 11:03 AM, Vladimir 'phcoder' Serbinenko
phco...@gmail.com wrote:

 Le 24 juil. 2015 06:20, Andrei Borzenkov arvidj...@gmail.com a écrit :

 В Mon, 20 Jul 2015 14:22:45 -0400
 Peter Jones pjo...@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?

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

Re: GRUB release schedule?

[Andrei Borzenkov]

В Mon, 20 Jul 2015 14:22:45 -0400
Peter Jones pjo...@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.
 


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

Re: GRUB release schedule?

[Vladimir 'φ-coder/phcoder' Serbinenko]

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 pjo...@redhat.com
 mailto:pjo...@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
 




signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

Re: GRUB release schedule?

[Vladimir 'phcoder' Serbinenko]

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 pjo...@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