Re: GRUB release schedule?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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