[Top][All Lists]

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

Re: GRUB release schedule?

From: Josef Bacik
Subject: Re: GRUB release schedule?
Date: Tue, 8 Dec 2015 16:34:19 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.


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,


reply via email to

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